Comment by arthens | Hacker News Reader

Comment by arthens | Hacker News Reader

Parent Full thread

REST can definitely be faster than GraphQL, because as you mentioned GraphQL is doing much more.

But as you start to re-use REST APIs across multiple pages/apps, you often end up:

- over-fetching: you'll receive some data that you don't actually need, but that it's required by another page

- over-querying: the data you are over-fetching might have required extra queries (or even worse calls to an external system)

- cascading requests: if you are working with nested data you might have to call the server multiple times, often in a sequential manner

Also in my experience the performance of REST APIs tends to get worse over time, because as many developers work over the same APIs it's almost unavoidable to keep these APIs lean. Just before Christmas we had to spend some time figuring out why a fairly simple GraphQL request was taking almost 2 seconds. Turns out a developer had accidentally introduced an n+1 in the underlying REST API. The n+1 was on a field/relationship that we didn't need/use, but with REST you don't usually get to pick what you want to load so...

Solving these problems with REST is possible but not trivial, while GraphQL mostly solves them out of the box. So while REST could be faster than GraphQL, in my experience it usually ends up being slower.

I think this gets to the underlying criticisms. GraphQL is not the replacement for REST and by nature an improvement - it is an alternative to REST based on a certain set of pain points. If you’re a large org with multiple consumers and your API development is silo’ed, then GraphQL may solve a set of problems you have that a small homogeneous team may not.

Correct, but it's worth noting that GraphQL has much more to offer than just request performance. I'd argue that performance improvements is the less interesting part of GraphQL.

The main selling points for me are:

- speed of development: once you have a complete graph, you can add new pages/features at a fraction of the time, and often without touching the backend at all

- type safety: you can generate typescript/flow types for your queries, giving you type safety from db to client (assuming your backend has types)

- query co-location: you can have the query (or a fragment) inside or next the component that uses it. Need a new field in a specific component? Just update the fragment, any page that includes it will get it by automatically

and last but not least developer experience. Having worked for a few years using graphql + apollo + react + typescript (on both a personal and a reasonably famous large website) I can honestly say that it feels like living in the future. As a mostly backend developer, I have never enjoyed working in the frontend so much.

Well said. That's why my current team started using graphql. It actually had very little to do with performance or anything backend-related, and mostly because of the same reasons (FE speed of development, type checking, etc).

Would you mind sharing your email? You have a fantastic way to build a message and we are looking for devs with that kind of skills.

If you don't want to share it publicly, you can find me very easily over the internet under the same name

Thanks for that follow up!

Reply on news.ycombinator.com