Single Item and Collection entity caching

[philvarner]

The collection (/collections/{collection_id}) and item (/collections/{collections_id}/items/{item_id} endpoints should be cacheable in most cases.

I tried implementing this in my BaseCoreClient implementation using cachetools, but was unable to actually get it to hit the cache, even when using a class variable for the cache. I don't really understand the internals of fastapi or stac-fastapi, so there's likely something I'm missing.

https://github.com/long2ice/fastapi-cache look like a better option, and supports non-in-memory options.

One complexity here is the Fields Extension, so caching should only occur if the fields parameter is the same.

The cache would need to be integrated with the Transaction Extension client, so that when an item was updated or delete, the cache would be cleared of that item.

One motivating use case of this is the use of a STAC API Item resource URL (e.g., /collections/c1/items/my_item) as the input to a distributed tiler (e.g., titiler), where different instances of the tiler retrieve the same item URL repeatedly. As it is now, these each require a DB retrieval and serialization/transformation, whereas caching them would be fairly straightforward.

[geospatial-jeff]

Adding an optional caching layer at the edge of the API makes sense to me. Either as a middleware or a decorator (fastapi-cache). I think its generally preferable in production deployments to implement caching outside of the API by fronting the application with a reverse proxy but I don't think that invalidates adding a caching layer as long as it can be easily disabled.