Caching for frequently polled requests for frequently changed state (maybe use ServeDir)

[yatesco]

Summary

Hi,

I have:

• HtmlDB (Axum process) which maps a userId to the HTML they should be seeing.
• viewCalculator (process) which reactively calculates what the HTML should be and persists it (e.g. POSTs it to HtmlDB) maybe once or twice a second or maybe it doesn't change for hours..
• UI which will frequently poll (once/twice per second - I can't use websockets/SSE unfortunately) the HtmlDB for HTML (long live htmx.org).

---
title: The world's best technical spec
---
flowchart LR
    db["htmlDB: HTML Axum store"]
    pages["viewCalculator: calculate latest HTML"]
    ui["UI: pesky users and their pesky browsers"]

   ui-- "pollMultipleTimesPerSecond(userId) /GET" -->db
   pages-- "pushOnExternalChanges(userId, html) /POST" -->db

I'd really like to get some caching going using etags or Last-Modified so I think I have two choices:

1. home grown: write our own middleware/find prior art for checking the headers. Maybe htmlDB stores everything in-memory and updates a counter per update so the Etag is simply (userId, counter).
2. ServeDir which I understand uses If-Modified-Since/Last-Modified headers based on the file-on-disk meta data.
3. a combination of both: introducing a Mutex shared by a wrapper around serveDir and the htmlDB/POST.

My question for 2. is about data races - what prevents the file being updated externally/by htmlDB/POST between ServeDir reading the file's meta data and then reading the contents? Does ServeDir allow locking the file first?

I should also say the contents of any files will be encrypted (in memory first) and writes can be fairly atomic using the "write to file/rename" idiom.

What are your thoughts?

Thanks!

axum version

HEAD

[jplatte]

I would recommend you to copy the parts of tower-http's ServeDir that make sense for your use case. It sounds like you wouldn't otherwise need to write files to disk, so it seems weird to do that only to be able to use ServeDir.

Though if you do want to write temporary files to disk, I can recommend the atomic-write-file crate as a way to achieve that, it pulls some neat and useful tricks beyond what you'd find in a home-grown write-with-temporary-name-then-rename implementation.

[yatesco]

(thanks @jplatte)