Implement ETag-based caching

Question

Implement ETag-based caching

Closed this issue 3 years ago · 6 comments

ETag caching is the future.

I have a project which accesses this API multiple times per minute while running, but most of the time the data returned by the API will be the same. Implementing ETag-based caching could save a lot of bandwidth, especially for length requests such as /crs

Answer 1 · 2021-12-21T12:00:54.000Z

Huxley is just a proxy and considered feature-complete. It doesn't hold state and doesn't know if data is stale or not. You would probably need to build something on top of the push port to implement this feature.

Answer 2 · 2021-12-21T12:05:02.000Z

There's no need to know if data is stale or not. The response just needs to be hashed before it is sent, and if the hash is the same as supplied in the ETag request header, Huxley can respond with a 304 code.

The objective isn't to prevent unnecessary API calls from the server to NRE, but to prevent unnecessary data transfer when no data has changed so the browser can use its own cached ETagged copy.

Answer 3 · 2021-12-21T12:25:40.000Z

Thanks for clarifying. Looks like Mads has a gist for some ETag middleware so I might see if that still works.

Answer 4 · 2021-12-21T16:36:26.000Z

I've added this but it's not quite that simple. NRE add a millisecond precision "generated at" timestamp to every response so the hash will always be different and so not useful as an ETag.

Answer 5 · 2022-01-19T09:59:42.000Z

This is available in the latest release, ignoring the generated at timestamp when hashing.

Answer 6 · 2022-01-19T10:07:16.000Z

Thank you so much! :)