Artjoms Iskovs

In practice, do you know if this runs into many issues? Stale caching, weird proxy behavior, CORS issues, etc.? Would be amazing to be able to leverage http caching (even etag+304 not modified) with large responses.

Visnu Pitiyanuvath

It's very experimental (we're discussing it here: https://github.com/splitgraph/seafowl/issues/20), but the whole lifecycle (miss, hit without connecting to the origin, revalidation with a 304, invalidation) seems to work with Varnish (see https://github.com/splitgraph/seafowl/issues/20#issuecomment-1195402009)

The test deployment this notebook is pointing at is running behind Cloudflare. The data on it is read-only so I can't test invalidation, but I do see Cloudflare return `CF-Cache-Status: HIT/MISS` (and sometimes `REVALIDATED` which should mean it's occasionally sending a conditional If-None-Match request to the origin).

CORS works on this notebook at least (allows any origin, and OPTIONS requests go through to the server, since Cloudflare treats them as DYNAMIC) -- though there are no Cache-Control headers on the CORS responses and so the request right now is still bottlenecked by the pre-flight.

I'll need to experiment some more with the query endpoint actually returning Cache-Control headers. I think if it returns Cache-Control: no-cache, then all intermediaries (browser, CDN) will have to send a conditional GET to revalidate the content on every query. That way we'll be able to test if cache invalidation works properly.