| The caching story in GraphQL sucks. Its pretty good with frontend frameworks like Apollo, but that's not a solution to the whole problem. Sure it works for your website/app (if you've got one), but it does nothing to offer caching for a generic API. Its easy to argue that the main advantage of GraphQL is to reduce overfetching fields on the data you need for your views. That's a great advantage. But how much of the performance advantage gained from this is offset by the substantially reduced backend cacheability of these requests? I would guess a ton, especially with highly complex views that require lots of database pulls. That isn't to say simple caching strategies aren't still possible (you can encode GraphQL requests into GETs and just cache that url at the CDN layer, this is part of the spec AFAIK). But when you have an open API serving many users, where you can't predict what fields they're going to ask for (or even the ORDERING of those fields in their request, which would change the request body despite the response being the same!), this has to be a problem that crops up pretty quick. There's no HTTP-level solution to this. I doubt there's any solution that would work well enough to be worth implementing. Which leads me to believe that its an intrinsic problem in GraphQL; the more freedom you give clients to request whatever they want, the harder it becomes to guarantee performance for the requests they're making. And GraphQL gives clients all the freedom in the world. Oh, and don't even get me started about the fact that because GraphQL stitches together essentially depth-unlimited data from your data graph in one request, there's no way to express different TTLs on each item returned, on the backend or the frontend. If you've got data that could TTL for 24 hours, but another piece of data that TTLs for 60 seconds, you essentially have to specify the cache-control to account for the smallest TTL. Overall, I think GraphQL is fine. But I also believe what we'll slowly discover is that "Company X" simply fucked up their REST API, then will look to GraphQL to solve all their problems. And it might solve some of them, but then they'll have an even more complex system in place with even harder problems. Facebook can solve those problems; us small shops can't. Better hope Facebook shares their solutions with the world. |
> Any API change had to be deployed simultaneously to all services using that API to avoid downtime, which often went wrong and resulted in long release cycles.
There’s an easy solution to that problem, which is a versioned API.