4 ms·

Ohh this is an interesting case. You could abuse the hell out of Etags, Urls and DIFFS to get a much better long haul response. https://csvbase.com/user-name/t

Ohh this is an interesting case. You could abuse the hell out of Etags, Urls and DIFFS to get a much better long haul response. https://csvbase.com/user-name/table-name/ https://csvbase.com/user-name/table-name/ would return you an etag. The etag needs to be a hash of the file (sha256). https://csvbase.com/user-name/table-name/etag https://csvbase.com/user-name/table-name/etag could return a 204 for an unchanged document. If the two dont match then return a diff + new etag. Apply the diff as a patch, and check the etag. Yes you still have the latency, on 204's but the moment there is a change you might be getting a 200 from cache, and only a diff at that. Smaller payload and potentialy faster response. On the server side the only thing that you're adding in is the diff of the last change.... If the data is faster moving then "cache" should let you catch up. If the caches are stale then the first response will give you a patch and new etag that wont have the correct hash value and you know to grab a fresh copy as you have no path forward.

repelsteeltje 3y ago
Ultimately, the root cause of latency is the round trip time to figure out if the cache is valid. For large distance between client and source of truth there is not much you can do in terms of caching, diffs an other throughput conserving cleverness; it's the speed of light. Sometimes, however, it it possible to anticipate when content will become stale: when changes to the origin don't happen arbitrarily. For instance, with live media streaming, segment chunks are usually fixed duration (say 2s or 8s for Apple HLS) and so you know your content won't / shouldn't change until... In those cases, client (and caching proxies) can rely on expiration and do not need to revalidate which saves network traffic. But more importantly, it allows an edge server to instantly serve a cached copy to the client. The round-trip is essentially between the client device and edge server. Making that snappy might even reduce air time and save your phone battery.

repelsteeltje 3y ago

Ultimately, the root cause of latency is the round trip time to figure out if the cache is valid. For large distance between client and source of truth there is not much you can do in terms of caching, diffs an other throughput conserving cleverness; it's the speed of light. Sometimes, however, it it possible to anticipate when content will become stale: when changes to the origin don't happen arbitrarily. For instance, with live media streaming, segment chunks are usually fixed duration (say 2s or 8s for Apple HLS) and so you know your content won't / shouldn't change until... In those cases, client (and caching proxies) can rely on expiration and do not need to revalidate which saves network traffic. But more importantly, it allows an edge server to instantly serve a cached copy to the client. The round-trip is essentially between the client device and edge server. Making that snappy might even reduce air time and save your phone battery.