GraphQL: A Retrospective

This means, you can cache and you can do whatever you want with caching rules (source: We are running it in production for a long time)

2) This is largely up to you. You can have it as a thin skin or you can rely more on your server side logic.

For us, we chose to have the frontend only handle presentation logic, the rest is handled on the server side.

For example, a lot of our stuff relied heavily on ACL, the frontend needs to expect to NOT get any data on specific fields, that's the only responsible for it. The rest is on the server side.

So I've heard, which is why I chose my wording carefully. Does anyone actually do that?

1. Browser caching is replaced by the graphql library (at least in the case of Apollo which is what I've used most). Which, as far as I've seen, is a fine one to one replacement in a lot of cases because it's still an in-memory cache that doesn't hit the network. Except it's even smarter than caching based on url and Cache-Control headers and such, because it can deeply introspect the payload and is able to return a cached version sometimes even if it hasn't made the exact same request before.

You're right that you don't get caching between sessions and won't automatically get CDN caching. It hasn't been a problem for me, and to be honest I don't know that I've ever worked on an app that had a whole lot of static data payloads where caching them at this level is critical for performance. For any kind of dynamic data that's unique per user you don't really need it. Things like cdn caching of images and js and css bundles and such still work just fine obviously. But I'd be surprised if there's no way to handle the CDN case in graphql. You can probably configure the client to do queries over GET and mutations over POST, though not sure offhand that that's gonna be the best way.

One similar issue, is things like the browser network tab become a little harder to deal with. But so far I've found the GraphQL developer tools are good enough to more than offset these limitations.

2. If anything, I think it's actually easier to err in the opposite direction, i.e. have your backend be a a thin wrapper, because you can let frameworks basically auto-map your ORM to GraphQL and then write all your business logic on the frontend. But ultimately it's really just as flexible as REST, and up to you to develop your own patterns for how much logic to put in the frontend vs backend.

Basically, the downsides that I've run into so far have been surprisingly few, and in return you get strong typing of your API layer, plus depending on your client you get a lot of really cool normalizing and de-duping in your frontend store for free. That latter part is probably the biggest game changer IMO.

https://blog.apollographql.com/optimizing-your-graphql-reque...

In real-world UIs, I've found that queries rarely end up being more than a few levels deep and are relatively easily optimised as long as your internal APIs can handle batches (easy for entities, harder for pagination). Additionally, even though the only-return-IDs-for-relations pattern means you can't utilise joins effectively, the upside is that you end up with much simpler database queries that area easier to optimise at scale. My rule of thumb was that as long as the query representing an entire screen could typically return in sub 100ms in production, it was acceptable (this was without any caching at the GraphQL level, which I had planned but left the company before I could implement it).

What's less common is using the GraphQL server for service-to-service communication, though i've been aware of people using it this way for my entire 3 years with GraphQL. I'm not yet convinced it's superior to alternative solutions to this problem (like gRPC, Thrift, other API Gateway patterns like JSON-API), but it could well be. I'm still happy using GraphQL in its sweet spot (and not-coincidentally what it was designed for), which is building an API for 1st-party websites and apps.