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.

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.