electric-sql
Use the same cache-control header for all non-live requests.
This is one suggested change partly based on the discussion in #2050.
Currently, responses to non-live requests with a -1 offset have:
cache-control: public, max-age=604800, s-maxage=3600, stale-while-revalidate=2629746
Whereas any other offset gets:
cache-control: public, max-age=60, stale-while-revalidate=300
The purpose of the lower cache duration for non -1 offsets is to enable more request-efficient data loading over time. So instead of having a long cache duration on:
insert a, b
GET offset -1 => [a, b]
insert c
GET offset 0_0 => [c]
insert d
GET offset 1234_5678 => [d]
By invalidating the cache of the second and third requests, a client coming along later will get the data in two requests:
GET offset -1 => [a, b] // still the same because cached for a longer time
GET offset 0_0 => [c, d] // compacted
This makes data loading more efficient over time for new clients. However, it also causes earlier clients to invalidate and re-fetch data that they've already synced into their private cache.
There is a solution for this and we're already using it on the -1 request: set a high max-age and / or stale-while-revalidate and a low s-maxage.
cache-control: public, max-age=604800, s-maxage=3600, stale-while-revalidate=2629746
This will allow shared (i.e.: reverse proxy / CDN) caches to revalidate and serve compacted responses after s-maxage=3600 whilst allowing private caches (browser clients) to regard the response as fresh for max-age=604800 and actually keep using whilst offline for a maximum of stale-while-revalidate=2629746.
Note lastly that this "same header for all non-live requests" is what's implemented in https://github.com/electric-sql/electric/pull/2061 for 304 responses. So this suggestion also aims to standardise the cache headers between an initial 200 and subsequent 304 responses.
Note, please wait for @KyleAMathews to comment and approve/revise/reject the approach before implementing.