Migration of REST Cache to Strapi 5, please read and give your thoughts

[derrickmehaffy]

Hello all o/

I am Derrick, a Support Engineering Manager at Strapi and also one of the co-maintainers of this plugin. With the release of Strapi 5 I will be working with @stafyniaksacha and @Boegie19 to do some heavy rewrites to this plugin to update it to Strapi 5. There almost certainly will be some breaking changes but with that will ideally bring some new features hopefully.

Below are some things I would like to tackle during the rewrite, albeit we don't know how long this rewrite is going to take. Regardless I'll detail some of my thoughts below but would also like to hear yours.

---

• Completely refactor the way we inject the caching middlewares

  • The way these were injected in the current version was more of a hack than anything and in certain situtations would completely break any custom middlewares the user added for additional security since it would bypass them
  • Ideally the goal would be to work with the Strapi team (not me lol but our engineering team proper) to have a natively supported way to do this properly
  • You can see a rough summery of this in my RFC here: [RFC-01] Changing the way cache middlewares are injected to native route mutation instead of new koa-router routes #64

• Allow for more detailed configuration on when and how the cache is busted especially for relations, components, ect

• Possibly (maybe) allow for a way to do caching for authenticated requests Moved to Feature: Support Authenticated Request Caching #113

• More advanced Admin Panel integrations possibly including a "cache view" to see what data is cached, how long it's TTL is, and when/how long til that TTL expires Moved to Feature: Admin Cache Dashboard #114

• Better debugging and maybe even a "cache bust log" (possibly saved to the database, TBD) Moved to Feature: Admin Cache Dashboard #114

• Rename this package to fit more in-line with the way we would like to see the community org go

  • strapi-plugin-rest-cache -> @strapi-community/plugin-rest-cache
  • strapi-provider-rest-cache-couchbase -> @strapi-community/provider-rest-cache-couchbase
  • strapi-provider-rest-cache-memory -> @strapi-community/provider-rest-cache-memory
  • strapi-provider-rest-cache-redis -> @strapi-community/provider-rest-cache-redis

• Add some new providers

  • elasticache
  • memcache

• Add better cache-control header configuration

• Significantly improve the documentation to make it easier to understand for novice users

• Better handling of custom routes

• Possibly allowing for caching the internal admin-api to increase Strapi performance even for back office tasks

And I think that's about all I had in mind so far but I'm open to hearing more community suggestions

[aqumus]

@derrickmehaffy I would like to help wherever I could to get this plugin v5 released, Is there any specific action item I could pick ?

[pragmago]

Thanks for your work on this plugin. Really appreciated that for v4.

Thats a pretty ambitious plan for the rewrite. Most of these suggestions look excellent. The only use case I currently use Strapi for is to serve pretty static content that allows editors to manage the content easily.

The most important missing feature in v4 is the lack of control over the injection of the middleware. The documentation was a bit unfocused but contained all relevant info in my case.

Most of the other features proposed here are nice to have, but absolutely not required. Cache busting always worked well enough in v4 and I rarely (maybe never) ran into issues where I wanted to debug the cache. I setup the cache and it 'just worked'.

So from my perspective, I would focus on improving documentation and allowing control over the order of middleware injection.

[JensUweB]

Refactoring the way the middleware gets injected & improving documentation sounds like necessary changes.

But I need to agree about the other features. They're not really necessary and most of them should be non-breaking which means you could ship them some time later.

For me the most important point is getting this plugin working with Strapi 5 fast. This plugin is the only major thing blocking us from upgrading right now.

[sehrish30]

This plugin is the main obstacle preventing our upgrade to Strapi 5. It must be compatible with the new version as soon as possible. Thank you

[derrickmehaffy]

Thank you all for your inputs. Let me chat with the other maintainers and see if we can come up with a short and long term plan.

[xuying88]

This plugin is the main obstacle preventing our upgrade to Strapi 5. It must be compatible with the new version as soon as possible. Thank you

Yes, we are facing the same problem.

[candidosales]

This plugin is the main obstacle preventing our upgrade to Strapi 5. It must be compatible with the new version as soon as possible. Thank you

+1

[menkel]

This plugin is the main obstacle preventing our upgrade to Strapi 5. It must be compatible with the new version as soon as possible. Thank you

+1

[gnodnav]

This plugin is the main obstacle preventing our upgrade to Strapi 5. It must be compatible with the new version as soon as possible. Thank you

+1

[Boegie19]

We have a working V5 version we hope to do a rc release this week or next week. note that the rc release does not have any of the new things we wanted to add.

Also since we now call the cache after all route middleware asume that the throughput of this version is worse.

[derrickmehaffy]

I'm working on doing some validation testing today so that I can hopefully push out a beta version this weekend or on Monday.

Note that this beta version SHOULD NOT be used in production