This discussion has been migrated from our Github Discussion #3866
Describe the topic
What this topic is about:
- Current Status of the Strapi-Hook-Redis package
- What needs to be done to get it up to a functional level within Strapi
- The usecases the redis hook could be used for
- Building a group of people who want to help build up these features
Your suggestions for this topic
After doing quite a bit of background research on Redis and how other projects and companies are using it, I’ve come to the conclusion that Strapi would benefit greatly from doing a nice refresh on the redis hook package (it was carried over from Strapi v1 and thus is legacy code).
A few ideas that come to mind as follows:
- GraphQL Subscription caching and state tracking example
- Koa-Ratelimit globally on all APIs with blacklist/whitelists (not just the admin login, and allows scaling across Strapi clusters)
- User state tracking for things like JWT-Refresh tokens and token de-auth (again for scaling)
- Low response time DB query cache for DBs such as MySQL and PostgreSQL
What I believe needs to happen:
- The redis hook package needs some fairly critical package updates mainly for supporting things such as Redis clusters and Sentinels
- Code additions need to be added so that redis is not required but is an optional feature (not everyone is using Strapi in a cluster, so in local memory, or even in the database storage is fine)
- Discuss other possible problems that allow redis to become a solution to.
My goal with this discussion is to find those interested in these features and are willing to help to build a team to work on them as the Strapi team themselves are quite busy with higher priority features and bug fixes (And at the moment they only have a single backend developer who is quite busy already).
Additional context
Excellent talk about how Box is using redis within their stack: Redis is Dead Long live Redis! - YouTube