Cache in Backstage

[buoyant mason]

I have been working on a backstage deployment and recently came across enabling cache on backstage as described here.

What I'm missing from the documentation though is a bit more clarity on the following:

• What gets cached and why;
• For how long;
• How to invalidate cached objects;

Any further information into those topics will be very appreciated. We have been working towards making our instance production ready and understanding more about caching is essential to us as it will be for anyone else working on the same thing.

[livid hawk]

@weak pilot Can you explain this? Documentation is unclear.
I'd like also to understand how do we know we're getting cached results (perhaps an header on the response?).

[weak pilot]

The backstage framework has a couple of builtin services that are there for convenience. It's a toolbox that's all optional and free to play with for plugins. Makes it easier to get going as a plugin developer, because you have a platform to stand on. Plugins may or may not choose to use those tools, depending on their internal needs, and those needs may change over time

Take for example the database service. Some plugins use it, some don't. It's not a concern that people outside of that plugin really typically worry about

Same with the cache. There's a cache service, always, and all we promise is that there's some rough set of semantics for getting and setting things in there

Then Backstage installation owners may or may not choose to configure that cache to point at a memcache, or a redis cluster, or something else

This is not at all at the "surface" of things. There's no headers, no nothing. It's just an API that some plugin makers go, "oh cool, there's a cache thing, we could leverage that for X"

and then they go and call get and put on that thing

which is entierly an internal concern of that plugin

This is in general how things work most of the time in Backstage land. We provide common convenient surfaces for standardization and ease of use, and then plugin maintainers can use those if they like, and Backstage installation owners can choose to plug in different physical implementations into those interfaces

What I can say is, the cache service default implementation is just a dumb in-memory map. It works, but won't help you scale cache-relying plugins' performance across instances.