Currently, I have a Firebase cloud function that utilizes express middleware to generate an authToken and passes it through the routes. This token has a 24-hour lifespan, so to avoid overloading the service with excessive requests, I am looking to cache the result for a period before regenerating it.
Two approaches have been considered:
- Investigating how to cache the axios request while generating the token.
- Utilizing Firebase Secret Manager to store the value.
During my research on axios caching, I already had Secret Manager in use, so both methods are being implemented concurrently.
Secret Manager
The current implementation involves using Secret Manager to store and update the token. Whenever I need the token for the external API, I can retrieve it from Secret Manager directly.
A scheduled job is set up to create a new token and disable all previous secret versions before adding the latest token.
The token creation process uses axios to call the authentication endpoint of the external API.
Axios Caching
Regarding implementing caching for express in cloud functions, additional complexities like CDN or Redis solutions seem necessary. I've come across intermediate cache options like cachios, which seems to leverage local memory. Would this mean that each cloud function instance in different regions has its own unique local cache? Is this a potential issue, or is it a more lightweight option compared to setting up Redis?
My Dilemma
I'm wondering if relying on Secret Manager for this purpose is a bad idea since it's typically meant for storing long-lived values that don't change frequently. Having potentially multiple versions stored daily could accumulate clutter in Secret Manager. Alternatively, would opting for a CDN or implementing an express caching layer be a more standard approach? If so, is there any straightforward guidance on setting up an express caching layer tailored for Google Firebase cloud functions?