Skip to content

🚧 Cache + Background Worker Infrastructure #13

Description

@rye

One of the things we are currently missing in this implementation is a cache, and one of the lessons we learned (or maybe just an opinion I have) about ccc-server is that having an active cache-management solution is a nice feature. Examples include frog-pond/ccc-server#50 ("cache poking") and discussions I think we have had about

For example, in frog-pond/ccc-server#638, we had to switch from a lightweight implementation to a heavier one that involved HTML parsing. It would be nice, imo, if we had automation in place to continuously fetch for new results.

Some ideas:

  • Use redis. It's nice and has built-in EXPIRE controls.
    • redis works well — it also has support for tokio which is good.
  • Add some kind of background worker infrastructure
    • Have a mechanism to invoke request handlers outside of the context of a real request
    • Use a schedule to periodically re-request website content.
    • Add some kind of early-warning exception system to dump out upstream data and notify us if things change
      • Could also be used to detect new fields?
  • Single-flighting? If 1000 clients request the same site at the same time, and the cache is missing the corresponding data, it would be better to request the upstream just once. Use a fork of some sort to prevent accidentally requesting more than once, and in that entire critical section (the time it takes to complete the request) also write into the cache so that the next batch of requests see the new cache entry.

I have some rudiments to start with; just writing up the issue so it is documented.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions