Hacker News Reader

Comment by latch | Hacker News Reader

> We spent months building custom caching for our GraphQL API from scratch

Could you not abandon GraphQL? Returning non-customized responses, while taking more bandwidth, is much more cache friendly for the client, proxies and particularly servers - where you can do simple yet powerful things (e.g. version-based invalidation and pre-generated payloads).

Like, I went to https://spectrum.chat/explore and clicked on "Tech. It uses GraphQL to load the communities.

Why not just hit /v1/communities?category=tech

which would loosely translate into one of:

-- if you want to serialize the object on each get

select * from communities where tags @> array['tech']

-- if you can look up the communities in a cache by id

select id from communities where tags @> array['tech']

-- if you have a high read / write and can just pre-serialize the payload and then glue together the response

select summary from communities where tags @> array['tech']

View on HN

I think it depends what you want as your cache invalidation policy. Simple TTL-based cache invalidation wouldn't necessarily need GraphCDN. However, no matter if REST, GraphQL or any other protocol - making sure, that when content changed, to invalidate it properly on the edge is not trivial.

If I understand correctly, you're suggesting to cache on a data-layer level (below the app in the stack) instead of what we do - above the app in the stack - just in front of the client.

That is also a valid approach. It'll need more custom code in your application and has the disadvantage, that your origin will still be hit on every request, while we fully cache on the edge - cached queries won't hit your server anymore and will take load off origin and have the minimum latency possible.

I'm suggesting that you can cache both at the data layer and "above the app". I was just highlighting one particularly powerful patterns available if you're having trouble scaling (like my parent said).

> making sure, that when content changed, to invalidate it properly on the edge is not trivial

The trivial way to do this is simply not to invalidate. Include a version in the cache key. When content changes, the version increases, and clients get new versions. (I think this is sometimes called lazy cache invalidation). It works well with LRU caches. It's still a hit for the top-level keys, but you avoid all the heavy data load and rendering.

Granted, that doesn't solve every case, but I'm not sure it's fair to say that it'll take more custom code when the initial approach took "months building custom caching" that never really worked. Also, I think you'll find your origin under less load due to having fewer variants.

That makes sense! I like the versioning approach - of course requires apps to have a version for their entities, but if they have, that's indeed a great way to leverage it. And yes, that also sounds like a solution that wouldn't take months to build.

Or use something like Odata that solves the same problems as GraphQL (returning complete and tailored trees of objects in one go), but uses regular GET operation to it's still compatible with normal http caching?

Many production GraphQL apps these days use persisted queries [0] via GET requests. So the HTTP caching itself is not an issue in GraphQL anymore.

[0] https://blog.codecentric.de/en/2020/05/how-to-secure-a-graph...

Reply on news.ycombinator.com