3 ms·

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 i

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.

latch 5y ago
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.
- timsuchanek 5y ago
  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.

latch 5y ago

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.

timsuchanek 5y ago
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.