Cache the responses
The datasets generally don't change often, so it's surely worth caching the responses.

Three levels of cache are involved:

- client (browser, moon-landing): use Response headers (cache-control, ETag, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)
- application: serve the cached responses. Invalidation of the cache for a given request:
  - when the request arrives, if the TTL has finished
  - when a webhook has been received for the dataset (see below)
  - (needed?) when a dedicated background process is launched to refresh the cache (cron)
- `datasets`: the library manages [its own cache](https://huggingface.co/docs/datasets/processing.html#controlling-the-cache-behavior) to avoid unneeded downloads

Here we will implement the application cache, and provide the headers for the client cache.

- [x] cache the responses (content and status code) during a TTL
  - [x] select a cache library:
    - -> http://www.grantjenks.com/docs/diskcache/tutorial.html
    - redis (https://redis.io/topics/persistence)
    - https://github.com/florimondmanca/asgi-caches
  - [x] check the size of the cache and allocate sufficient resources. Note that every request generates a very small JSON (in the worst case, it's the dataset-info.json file, for ~3,000 datasets, else it's a JSON with at most some strings). The only problem would be if we're flooded by random requests (which generate 404 errors and are cached). Anyway, there is a limit to 1GB (the default in diskcache)
  - [x] generate a key from the request
  - [x] store and retrieve the response
  - [x] specify the TTL
  - [x] configure the TTL as an option
- [x] set the `cache-control` header so that the client (browser) doesn't retry during some time. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
  - [x] TTL: return "max-age" in the `Cache-Control` header (computed based on the server TTL to match the same date? or set `Expires` instead?)
  - [x] <strike>Manage `If-Modified-Since` header in request?</strike>: no, this header works with `Last-Modified`, not `Cache-Control`/ `max-age`
- [x] manage concurrency
  - [x] allow launching various workers. Done with `WEB_CONCURRENCY` - currently hardcoded to 1
  - [x] <strike>migrate to Redis - the cache service will be separated from the application</strike> -> moved to a dedicated issue: #31

The scope of this issue has been reduced. See the next issues:
- #32
- #31
- #34
- #36
- #37

And maybe:
- #35 
- #38
- #39
Cache the responses: The datasets generally don't change often, so it's surely worth caching the responses.

Three levels of cache are involved:

- client (browser, moon-landing): use Response headers (cache-control, ETag, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)
- application: serve the cached responses. Invalidation of the cache for a given request:
  - when the request arrives, if the TTL has finished
  - when a webhook has been received for the dataset (see below)
  - (needed?) when a dedicated background process is launched to refresh the cache (cron)
- `datasets`: the library manages [its own cache](https://huggingface.co/docs/datasets/processing.html#controlling-the-cache-behavior) to avoid unneeded downloads

Here we will implement the application cache, and provide the headers for the client cache.

- [x] cache the responses (content and status code) during a TTL
  - [x] select a cache library:
    - -> http://www.grantjenks.com/docs/diskcache/tutorial.html
    - redis (https://redis.io/topics/persistence)
    - https://github.com/florimondmanca/asgi-caches
  - [x] check the size of the cache and allocate sufficient resources. Note that every request generates a very small JSON (in the worst case, it's the dataset-info.json file, for ~3,000 datasets, else it's a JSON with at most some strings). The only problem would be if we're flooded by random requests (which generate 404 errors and are cached). Anyway, there is a limit to 1GB (the default in diskcache)
  - [x] generate a key from the request
  - [x] store and retrieve the response
  - [x] specify the TTL
  - [x] configure the TTL as an option
- [x] set the `cache-control` header so that the client (browser) doesn't retry during some time. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
  - [x] TTL: return "max-age" in the `Cache-Control` header (computed based on the server TTL to match the same date? or set `Expires` instead?)
  - [x] <strike>Manage `If-Modified-Since` header in request?</strike>: no, this header works with `Last-Modified`, not `Cache-Control`/ `max-age`
- [x] manage concurrency
  - [x] allow launching various workers. Done with `WEB_CONCURRENCY` - currently hardcoded to 1
  - [x] <strike>migrate to Redis - the cache service will be separated from the application</strike> -> moved to a dedicated issue: #31

The scope of this issue has been reduced. See the next issues:
- #32
- #31
- #34
- #36
- #37

And maybe:
- #35 
- #38
- #39