[Feature request] Purge sub-request cache

[scottdixon]

It would be awesome to be able to programatically bust sub-request cache. Something like:

cache.purge(['some', 'key'])

Raised by a merchant who was worried about time-based caching eating into their third party CMS' usage cap. If they set the maxAge too low, they eat into their usage cap, if they set it too high they risk stale data.

A feature like this would allow them to set a high maxAge and purge when notified of content updates from a webhook.

[jplhomer]

tl;dr - I don't think this is something we want to introduce into Hydrogen. The distributed nature of web applications is not suited for this feature, and the combined use of maxAge + staleWhileRevalidate should allow developers to return relatively fresh data within their API limits.

Modern platforms like Oxygen and Cloudflare Workers provide a caching API which is bound to a geographical collocation. This means that cache is not shared or distributed globally. This makes it impossible to globally purge a given cache entry, short of using that platform's tooling specifically for that purpose. Yes, you could send a webhook to your site — but it would only purge the entry for the closest colo that handles the request.

We recommend using staleWhileRevalidate to your advantage. When Hydrogen returns a stale sub-request, it actually creates a lock behind the scenes while it's generating a new response in the background. This prevents other requests in the same colo from triggering multiple hits against the API, which in turn should dramatically reduce the number of requests to your API.

If the above strategy does not scale for a given API, I would recommend that the developer create a separate thin proxy service backed by a consistent, persisted cache like Redis.

Another option is of course to use something like Gatsby, which is SSG by nature, or Next.js's new incremental static revalidation + SSG.

[scottdixon]

Thanks for the detailed response @jplhomer!

cc) @wizardlyhel @steve-jiang

[robinglen]

@jplhomer I'm investigating using Hydrogen as a head for our headless Shopify. We mix commerce and content at the moment we use NextJS for the ISR and SSG functionality for content and then regular on edge caching for the ecom sections.

I was wondering if SSG or ISR was something you were considering for Hydrogen and Oxygen? If you're allowed to say :)

[benjaminsehl]

Hey, @robinglen, sorry for missing this — Josh is on leave right now.

SSG/ISR aren't really part of the same paradigm as Hydrogen. Instead of SSG, we have server side caching, and instead of ISR, we have maxAge and staleWhileRevalidate.

This is pretty similar in practice though — you're caching a static copy on the server, which will last for the maxAge amount, and then when a hit comes in that is greater than that time, the server goes and revalidates the request in the background and re-caches a fresh copy if necessary. If the time between requests is greater than both the maxAge and SWR times, the user will see a fresh copy (but will have to wait a slight bit longer to see it).

To summarize — you can think of caching similar to static, SWR similar to ISR, and then when both of those are out of time similar to getServerSideProps.