It seems to just move all the flexibility of GraphQL to dev time, and makes it only useful for a private API where you control both the client and the server. This is all fine, but then I just don't see why you'd move away from a classic API where caching is free for GETs and you don't have to go through the abstraction of GraphQL schemas and resolvers etc to do your endpoint logic, you can just do it.
One thing I could possibly see is that client side libraries like Apollo etc bring huge advantages like free client caching or other things I'm not aware of - is that the case?
Apollo was really useful for managing state across the client. Tools like optimistic updates were very nice too. Unfortunately, it was somewhat buggy when we were using it, and the API kept changing, but I think it's more stable now.
It was also good to have a well-defined schema between client and backend, although you should have one anyway.
I've worked for companies in the past that had the organisational setup you describe, however, where frontend engineers didn't even have pull access to the code for api services they were talking to, where this would have been a massive advantage in terms of productivity.
I seem to end up at this conclusion in most discussions about GraphQL, usually with facebook scale being referenced, where it seems that as a technology its main advantages might actually be architectural in terms of the organisation of how massive systems are engineered, by huge numbers of people.
The temptation is always to jump in and compare the technical merits and specifics, and overlook this, but I'm coming more to the opinion that this is the answer here to when to use GraphQL over REST / RPC over http. That is, at the scale of a massive engineering organisation, it might be an abstraction whose advantages outweigh the downsides, but probably not if you're a small team.
If you're finding that your endpoints are filled with unnecessary optional fields, that they're specific to a single screen in the UI, that nearly every new feature involves work that's duplicated across front-end and backend, or that you're suffering a performance hit from the round-trip time between front-end and backend when you query nested objects, then GraphQL can be an option. These are problems that you run into when your product starts to get bigger and more unwieldy, so if your UI has five screens and doesn't reuse the same content then you might not see a lot of gain. Having said that, my former company was under ten engineers, so I don't think you need to be Facebook-scale to benefit.
Totally agree that the advantage is architectural. It's not a question of technical merits or of REST being bad. GraphQL is a layer of abstraction to separate data from presentation, and like other abstractions, you shouldn't use it unless you have a reason to.
> The solution to ad-hoc queries is to not use ad-hoc queries. Persisted queries are becoming common.
So, you either reinvent REST, or fall prey to ad-hoc queries with potentially unlimited complexity.
Also, persistent queries don't save you from unlimited complexity when those are automatically persisted, which is what Apollo offers.
> Caching is no harder in GraphQL than it is anywhere else. You define resolvers; if you want to put stuff in Redis, you're free to do so.
Putting stuff in Redis does not make it caching.
> You have complete control over what happens in a resolver, which includes authorising access and throwing an error/returning null/etc.
So, you throw an error in a deeply nested resolver in an ad-hoc query with unknown complexity, and .... this is "no harder"?
Caching is no harder in GraphQL than it is anywhere else. You define resolvers; if you want to put stuff in Redis, you're free to do so.
Auth is also no harder in GraphQL than it is anywhere else. You have complete control over what happens in a resolver, which includes authorising access and throwing an error/returning null/etc.