Use per-bundle entity list cache tags to potentially increase caching and performance in jsonapi

This is a good idea @mstef, the blocker is #2145751: Introduce ENTITY_TYPE_list:BUNDLE cache tag and add it to single bundle listing (see esp. comment #70).

WOOT! #2145751: Introduce ENTITY_TYPE_list:BUNDLE cache tag and add it to single bundle listing finally landed!

Great! Looking forward to your patch, @wouter.adem, and thanks for stepping up! 🥳🙏

With the patch in #7, the node_list tag is indeed removed from /jsonapi/node/<bundle>. However, it still appears in /jsonapi/node/<bundle>?filter[status]=1. Not sure why or what other parameters cause this.

Logistically how do we prevent stale relationship data with this? I think that would be especially relevant to ?include queries where potentially data from other bundles is included on the parent bundle response.

I'd love to see this implemented but I'm having trouble wrapping my head around how to properly reconcile the cache. Hardest problems in comp-sci I guess...

The cache is already varied by ?include, if references are changes shouldn't the parent caches also been cleared normally? Therefor there isn't much issue here?

I think if we have some proper tests this could be verified.

This issue isn't about being correct, it's about having fewer invalidations while still being correct. Invalidating the overall list cache tag is the easiest option, but it is possibly also to aggressive. Imagine you have a news site, then a news is probably going to be updated every few minutes and node_list is invalidated very frequently. But you might also have dossier/topics or something, and those only change once every few days. So a jsonapi query to list all dossiers does _not_ need to be invalidated every time a news is updated. You know it will only ever list dossiers, so you can just add the node_list:dossier cache tag.

I don't know the jsonapi code very well, but I imagine that this might be much easier to implement than the sister issue for the views module.

Logistically how do we prevent stale relationship data with this?

I think this is a non-issue. Relationship resources don't use the *_list cache tag since new entities are not automatically added to relationship routes—they must be referenced by the parent entity in order to appear. For that reason, relationship routes use the referencing entity's cache tag. For example, if article:42 references related articles and a new article gets created, it will not automatically appear in article:42's list of related articles. However, when someone does explicitly add it, the related route will be invalidated when the node:42 cache tag is invalidated.

I think that would be especially relevant to ?include queries where potentially data from other bundles is included on the parent bundle response.

The same applies here since collections with include queries have the cache tags from each included entity.

tl;dr: relationship routes and the include query param are irrelevant because the ENTITY_TYPE_list cache tags only pertain to "automatic" listings, not lists of referenced content.

Just tried out this patch and needed to make a small change. As we are using JSON:API Cross Bundles, and I noticed on these routes you would get a cachtag of node_list: (i.e. a colon was added but no bundle).

This new patch adds a check to see whether a valid bundle exists.

I also couldn't replicate the issue from #9, when I added filters to the query when using the patch, I still got the node_list:bundle_name tag.

Great you had a look, could you please add an interdiff? That always helps understanding the changes a bit better.

See this page in the documentation

Yes sorry, I tried to create an interdiff but got this whitespace error that I don't have time to look into right now. interdiff: Whitespace damage detected in input

The difference is:

if ($resource_type->getBundle() !== $resource_type->getEntityTypeId()) {

Was changed to

if ($resource_type->getBundle() && $resource_type->getBundle() !== $resource_type->getEntityTypeId()) {

If anyone is interested, I created a custom module for our project that generates cache tags based on JSON:API filter values. (Using bundle specific list cache tags did not go far enough for our requirements).
https://github.com/ministryofjustice/prisoner-content-hub-backend/tree/m...

@Leon Kessler: do you mind publishing this on drupal.org as a module? 🤞😊

I was planning to. But it's a bit bare bones at the moment, only currently supports entity reference fields being filtered by uuid. But I could release as a module in development.

I've now posted this as a full project: https://www.drupal.org/project/jsonapi_filter_cache_tags
Note that tests are currently failing in D10 (they pass on D9), haven't had time to look into it yet.

Also, it only currently supports filtering on entity reference fields, no other field types.

The module was very much created for our own needs, and probably needs a bit of work to get to a stable release.

Isn't this a duplicate now? https://www.drupal.org/node/3107058Nevermind, the issue title/summary misled me.