DEV Community

Discussion on: What are the cons of GraphQL?

Collapse
 
benbot profile image
Benjamin Botwin • Edited

I don't know if I agree with this. You can have a similar cache setup as you do with a REST api as long as you, say, hash the graphql query or something and just hit the cash server side if the graphql query hashes match.

Most clients aren't sending a variable number of different graphql queries anyway. Most have a fixed set of queries that get sent from different pages.

It may not be as straightforward as REST caching, but it's not very complicated either.

Collapse
 
rhymes profile image
rhymes • Edited

I think we're talking about two different types of cache. You can definitely do server side caching with either. After all if you're on the server you own the data so you can cache it however you want.

I meant network servers, as the HTTP spec says that GETs are idempotent, network servers (proxies, cdns, edge caching services) cache data, that can't easily happen with GraphQL by default, because all queries (even read queries) are transmitted using POST:

Due to the way GraphQL operates as a query language POSTing against a single endpoint, HTTP is demoted to the role of a dumb tunnel, making network caching tools like Varnish, Squid, Fastly, etc. entirely useless.

(taken from phil.tech/api/2017/01/26/graphql-v...)

It's not the end of the world, but it might mean that you have to get creative with your data for the fact you're suddenly losing the advantage of proxies.

There are standards popping up but on one side you have a decade year old system that works (and it's widely used by clients, networks and servers) for caching and on the other side you have to control both the client and the server if you want to have caching done right.

As the author was asking about the cons, and this I think is a con :)

Thread Thread
 
benbot profile image
Benjamin Botwin

Ah okay, I see what you’re saying. I was getting the network layer and application layer mixed up.

Though, while that’s true for now, I don’t see why tools like varnish couldn’t be extended to cache GraphQL responses at the network layer. If the adoption of GraphQL keeps increasing, we’ll eventually see solutions.

Thread Thread
 
mando75 profile image
Bryan Müller

Just to add a bit to the discussion, I would encourage anyone interested in this thread to listen to this talk from GraphQL Summit on HTTP and caching in general with GraphQL. It was given by a senior platform engineer at GitHub. He goes pretty in depth comparing caching in GraphQL vs in a traditional REST API (Including HTTP caching). I think he does a good job of explaining the pros and cons with both patterns. youtube.com/watch?v=CV3puKM_G14

Thread Thread
 
rhymes profile image
rhymes

Thanks Bryan, very interesting!