Relationships

[PeterBowater]

Hi, a question as to whether this also invalidates cache entries for:

• Direct relationships
• Relationships within components in dynamic zones

Many thanks,

Peter.

[TupiC]

The plugin invalidates the cache afterCreate, afterUpdate and afterDelete events. This means that the cache will be invalidated whenever a new record is created, an existing record is updated or a record is deleted but only for the model/content type that is being modified. For example, if you have a Post model and a Comment model and you update a Post, the cache for the Post model will be invalidated, but not for the Comment model. Puring the cache with the provided buttons only invalidates/purges the key/content type where the button is clicked.

[PeterBowater]

Thanks for the reply! 👍

OK, so if the intention is to replace the strapi-plugin-rest-cache plugin, this is handled by this file, while you have something similar, you only target the model that is being modified, and not any content relations:

https://github.com/strapi-community/plugin-rest-cache/blob/main/packages/strapi-plugin-rest-cache/server/utils/config/getRelatedModelsUid.js

This allows you to purge the cache for the related content as well, as otherwise if you were to re-fetch the content for the related content, the cache would be stale.

For example if there was a content type 'department' with employees created as a relationship to another content type called 'employees', an update to an employee would not invalidate the cache for the department page, therefore leaving stale data there.

Is that correct?

If so then it would be great to find a way to accommodate both these direct relationships, as well as nested relationships within dynamic zones, which the other plugin (not v5 compat) did handle.

Thanks a lot,

Peter.

[TupiC]

Thank you, Peter! Ive just released an experimental version that also invalidates relations, nested relations and dynamic zones.
Could you please install and test 1.4.7-rc.2 @PeterBowater ?

[PeterBowater]

Thank you!

Yes, I will do once back at work tomorrow :)

[PeterBowater]

Hade a look @TupiC , I'm struggling to get it up and running on that particular tag, any ideas?

Nothing in the log, but the entry for strapiCache in the .client/app.js file gets removed on build. If you can give me steps to get it running properly I'll give it a go against first thing tomorrow when back at desk.

Thanks a lot!

[PeterBowater]

in --debug it shows the backend is loading, but the plugin is not loading anything in front end.

[TupiC]

Can you show me your package.json and plugins.ts/js? I will test it once I can reproduce it.

[PeterBowater]

EDIT: Ignore me, running now, will feedback later today.

Thanks for looking.

[TupiC]

Yes thanks for sharing. Can you try replacing:
"strapi-cache": "github:TupiC/strapi-cache#v1.4.7-rc.2",
with:
"strapi-cache": "1.4.7-rc.2",
in your package.json and then reinstall your packages.

[PeterBowater]

Hey @TupiC , looking into this, does it clear the cache for the whole related models, or does it target the specific piece of related content by documentId?

The log file suggests that it is the whole model but appreciate that may not be the functionality underlying it, e.g.

[2025-05-08 08:41:01.043] info: [STRAPI CACHE] Invalidated cache for /api/stories

With a lot of relations API calls get expensive, hence the need for caching, if the cache plugin invalidates all related models when you have a lot of relations then the whole cache will get cleared for almost every content edit.

I've delved a bit into the code but not had enough time this morning to explore too much, answering the above would help a lot to stop me wondering/trying to find out!

Thanks a lot,

Peter

[TupiC]

To avoid any stale data it clears all related models (direct & indirect relations, used models and dynamic zones). The API calls won't get expensive since relational lookup only happens on cache invalidation. Could you please provide a list of collections/components and how they relate to each other as well as what should get invalidated when something gets updated? I will then try to adapt the code and change it. You can also setup a simple strapi project with the strapi-cache plugin to better show/communicate what you mean.

[PeterBowater]

Thanks @TupiC ,

Apologies, I meant expensive API calls for our application, not the cache plugin. These are the calls we really want to cache as they can take more than a second due to the complex relations we have set up.

Diagramming the relations would take a fair time (they are extensive), but perhaps if we concentrate on one model for the moment, it can become clearer.

If I update an 'Artist' in Strapi I get this in the logs:

[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Related content types for api::artist.artist: api::department.department,admin::user,api::artist.artist,api::artist-landing.artist-landing,api::auction.auction,api::collectors-guide.collectors-guide,api::collectors-guide-landing.collectors-guide-landing,api::event.event,api::event-landing.event-landing,api::location.location,api::new-and-noteworthy.new-and-noteworthy,api::new-and-noteworthy-landing.new-and-noteworthy-landing,api::newsletter-landing.newsletter-landing,api::page.page,api::request-estimate.request-estimate,api::search.search,api::service.service,api::specialist.specialist,api::story.story,api::story-landing.story-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/departments
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/users
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/artists
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/artist-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/auctions
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/collectors-guides
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/collectors-guide-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/events
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/event-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/locations
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/new-and-noteworthies
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/new-and-noteworthy-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/newsletter-landing
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/pages
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/request-estimate
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/search
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/services
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/specialists
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/stories
[2025-05-08 09:03:27.065] info: [STRAPI CACHE] Invalidated cache for /api/story-landing

That's essentially all our other models being entirely invalidated -and appears to be correct in that all the relations that are in the model and dynamic zones etc are included.

Ideally what would happen is that the documentIds that form the relation in the Artist piece of content would also be passed in to the invalidateCache function.

This means we only invalidate what we need to, rather than the whole model.

So for example:

• An artist 'banksy' is related to:
• Department, with a documentId of '12345abcde'
• When publishing the Artist 'banksy' the banksy document is parsed to get:
• • relations
• • related documentIds for each relation
• Relations and documentIds are passed to InvalidateCache() which invalidates only the related documents, and not the whole model.

Doing it this way would make the invalidation operation much lighter weight, and reduce further the strain on Strapi for expensive API calls as there would be fewer cache entries that need to repopulated after a publish.

I'm pretty certain this is how the 'community' plugin I cited in an earlier comment works.

Does that help? And do you think it is possible?

I can put something more comprehensive together if needed.

Thanks a lot,

Peter

[TupiC]

Thanks for making it more clear @PeterBowater

Let's say these entries are stored in my cache (they may not be the same as the ones in your cache). The artist banksy has the id 123:

[
    "/api/artists/filters[name][$eq]=banksy",
    "/api/artists",
    "/api/departments/12345abcde",  
    "/api/departments/filters[artist][$eq]=banksy", 
    "/api/events", 
    "/api/locations",
]

All of them return data where the artist banksy is present/related to. Currently all would get invalidated. Which of these entries will/should be invalidated if I update the artist banksy?

[PeterBowater]

I would expect, I think, some sort of regex matching against existing cache entries based on collection type and id, do you think that may work?