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.
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.