Add support for Drupal cache tags in the revalidate functionality

[bojanbogdanovic]

Package

Not package-specific

Describe the feature request

Currently next-drupal only supports revalidating by path for the node that is being added/updated/deleted. Yes, you can specify additional paths per bundle, but that is only applicable if you are dealing with predefined paths. I'm currently working on a project that is multilingual but most importantly it is working with dynamic routes with catch-all segments. This means any node can have a different path (different from the URL alias pattern). This becomes a problem when referenced entities are being used in the node, e.g: Media, Taxonomy term, other Nodes. Dependencies are not being revalidated, e.g: updating a taxonomy term name that is being referenced on a node, won't trigger the revalidate on the associated node and the change won't be visible on the frontend.

Describe the solution you'd like

If we look at Drupal how it deals with dependencies on data, the cache tags from the Cache API is a great example. For the project that I'm working on, I have introduced an event subscriber that tracks and registers the cache tags on API calls coming from the frontend. With this info it's possible to resolve all associated nodes that need to be revalidated. For example: taxonomy term name has been updated, by querying into the tracked cache tags, I'm able to pinpoint all the nodes that are referencing this taxonomy term and revalidate them by path.

Describe alternatives you've considered

I have consider to register the cache tags on the frontend side, in a static JSON file or in Redis cache. But because in the project we are dealing with allot of data (entities), a update from a single entity could potentially trigger many pages to be revalidated, which could introduces performance issues. That's why a queue would be advisable and luckily Drupal has one out of the box. Also the registered cache tags need be queried by context, e.g: langcode and next site, hence a table in the database would be more appropriate.

Additional context

This implementation is already up and running on the project that I'm working on, the question is would this be interesting for the community if I would contribute this to next-drupal?