The original motivation was to reduce the number of network requests made on cellular network-connected mobile devices, both to save on power consumption and reduce latency for the user. It off-loads a lot of complexity and computation from the client to the server, and make sense if want to create as good a mobile experience as you can.
In terms of code architecture, it drastically simplifies frontend code, and overall reduces backend code and boilerplate. It's extremely elegant and nice to use over creating custom endpoints for every use-case, but the N+1 SQL query problem is a giant thorn.
Kinda, by all accounts the original motivation was to solve the proliferation of endpoints. Everyone was already writing per-screen endpoints to solve the network requests problem (which, contrary to what many believe, wasn't magically solve by http2), but they were doing it in a way which played out in several ways:
1. Having to make a new endpoint every time your frontend changes
2. Not making a new endpoint, and just augmenting the existing one for a screen. Which would cause them to accumulate dead data over time (especially if multiple app versions had to be supported concurrently -- in the case of Facebook this was ~3000 versions).
3. Being lazy and finding a similar endpoint meant for another use case and piggy-backing it for your new usage.
All of these would create maintenance and organisational problems.
GraphQL is essentially a system that lets you write endpoint specs (in the form of GraphQL query documents) that the backend knows how to support. It's not a free lunch, you still have to do a lot of work on the backend to allow it to do this efficiently and securely (nowhere near as difficult as people make it out to be though), but it does a really good job at solving the endpoint maintenance problem.
You can still design an immutable REST api to match the client's needs. Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.
I see your point about reducing network requests (graphql lets you co-mingle mutations and queries), but I don't think that feature is used often enough, b/c what if one query fails, then everyone has to fail).
> Apollo has really nice out-of-the-box caching that can be tricky to replicate with rest.
Caching is trivial to do with REST.
The "really nice caching" that Apollo does literally deserializes and deep inspects both the request and the response to try and figure out caching on specific fields. Also, POST requests are not cacheable according to HTTP spec.
With REST you set an ETag and/or Cache-Control headers and let your existing infra and client browsers handle that.
You can make a REST endpoint match a client's needs, but if you have multiple clients (for example, 1 for mobile and 1 for desktop) that all need different amounts of data (for example, the mobile client shows a simplified view with less data), then you would need to write 2 different REST endpoints to handle each clients. Multiply that by the number of pages with a difference.
> It's extremely elegant and nice to use over creating custom endpoints for every use-case, but the N+1 SQL query problem is a giant thorn.
Having not used, but only read about graphql, this was the first thing that struck me. It seems great at minimizing data transferred to the client, but it doesn't (seem to) stop that data being fetched from the DB - it just post-filters it.
I'm imagining a scenario like a dashboard, where you're getting a small amount of data from a lot of places. With REST, we'd generally do that by having a dedicated endpoint for the whole dashboard that executes a single query, letting the DB do what it's good at (efficiently retrieving required data). My naive impression is that graphql would execute a bunch of queries, trim what's not needed and join it all together. With anything non-trivial that seems like a performance nightmare.
Graphql was a cool experiment, but I’m sticking with rest/protobufs