Description
While I was doing some research re #5784, I came across these two interrelated Drupal contrib modules (not ported to Backdrop at the time of writing this):
- https://www.drupal.org/project/render_cache
Drupal's building and rendering process of entities is quite time consuming. This module attempts to alleviate needless rebuilding and re-rendering of entities on subsequent page loads by caching.
When an entity is updated a new cache key is generated; there's no waiting for a cache to time out.
- https://www.drupal.org/project/entity_modified (required by the render_cache module)
Drupal does not force entity types to provide a last modified date, nor provides any standard naming convention for those that do.
This module steps in to provide a programmatic way to retrieve the name of the modified property. When the name is unknown, entity modified tracks the date itself.
I'm opening this issue as a task to evaluate complexity of these modules, and possibility of performance and DX gains.
Both of these modules seem to be related to the Entity API module, and are building on top of it. Since Entity API has already been integrated into Backdrop (see #1371), chances are that things we need will most likely already be in core.
How this issue here is relevant/related to #5784 is that the render_cache
module includes a render_cache_views
submodule, which:
render_cache_views
module can also hijack the views node view row plugin, bundled with the Views module, to provide render caching.