I think lots of people here are fixed on GraphQL from a backend perspective and are missing that GraphQL has a fantastic front end development experience using libraries like Apollo.
I honestly think the backend benefits are relatively marginal, but on the client being able to 1) mock your entire backend before it even exists, 2) have built in automatic caching on every query and entity for free, 3) use a fully declarative, easily testable and mockable React hook API built with out-of-the-box exposed support for loading and error states, is so valuable. Components written against Apollo feel so clean and simple. That's not to say anything about the benefits you get from being able to introspect the entire backend API or test queries against it with Apollo's extensions or how you can easily retain the entire entity cache across reloads with simple plugins to Apollo.
Can you do all that with REST? Sure. But writing queries against REST APIs is a pain in the butt compared to what you get for free by using Apollo.
> But even then there's still some value in letting the client specify the shape of the the data it needs and having client SDKs
It may not exactly "shine" in those cases, but it reduces round trips and makes it easy for fronted engineers to make views that revolve around use cases instead of the resources in the database.
Is that really a big deal with HTTP2 and pipelining?
I can also imagine situations where it results in a better UX to make multiple small calls, rather than one big one, as you'll have something to render faster.
If you are round tripping because of data, you’re having to traverse the network to the origin and likely composing your queries with dependent data, so http2 is little benefit. For example, if you are loading a book detail page, and want to also show the author name, but you need to retrieve the detail record to get the author ID first so you can call the author detail endpoint. Graphql solves for this by being able to fetch the book detail and the joined author name with one round trip.
Sure, I didn't mean multiple requests would always be a net benefit, only that I often come across cases where there is a need to load independent data simultaneously, in which case multiple requests can sometimes provide a better UX.
> Graphql solves for this by being able to fetch the book detail and the joined author name with one round trip
I don't see why we need GraphQL to solve this though - a REST backend could have an endpoint that returns the exact same data.
I can see how GraphQL might be somewhat nice for front end developers when the data to be displayed hasn't been nailed down yet - maybe we decide to show the book's ISBN number, and we can do that without changing the backend. Maybe this justifies the extra complexity for some teams, but I'd personally much prefer the simplicity of a REST API, to which you can always add OData on top if you really want.
The real benefit of this, is that you can have all this data available, and now the mobile team and the web team can share a query, maybe the webteam wants everything, ithe ISBN the Author, etc. The mobile team only wants the author and title (and will show the rest when you click in, doing the same query or slightly different but with all the fields).
It's the power of the frontend teams to create a rest endpoint out of a schema.
When you combine it with typescript/JVM/Swift, you get AUTO typing for the graphql queries, you know exactly the data model you get back based on your query. It's quite lovely.
The other aspect is that on the apollo/graphql server you can utilize dataloader and streamline a nested request into as few calls to each service as possible.
And the last benefit over a rest service. If you had to make multiple calls, you're doing round trips from the CLIENT to the backend services. The graphql server is _already_ in your backend service network, so all the data combining is on the orders of <10ms versus <100ms (or much worse for mobile).
GraphQL has a major advantage over rest in that you can't just change the schema without the clients breaking, so you know that your API isn't going to magically just screw you. (Most places use versioning for this, but not always). You can get some of this with RPCs but it's not as robust as the graphql schema.
I always find it sad when developers waste time on developing over-engineered methods to reduce the amount of API calls while having 10 advertising/analytics SDKs in the background sending countless amounts of requests (which can still saturate the data link and make the main API requests stall even if it's a single one).
There are automagic GraphQL layers that sort-of make sense to me, since at least they remove the biggest pain points. But AFAIK they're all single-database.
Actually stitching together multiple services or DBs with it manually seems like it'd be a hellish experience that'd end in a massive data breech or repeated accidental dataloss + restore-from-backup. Or else valid GraphQL going to such a system would be so restricted that the benefit over just using REST (or whatever) is zero.
