Problem/Motivation

The JSON API code is generating cacheable dependencies in different places. We want to make sure there is no other way to have the cacheable metadata generated in a more centralized location.

At the present moment some metadata is generated during the response generation (on the EntityResource) and some is generated during the normalization process.

Proposed resolution

  1. Determine if it's possible to have all the metadata centralized.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

e0ipso created an issue. See original summary.

e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

Issue summary: View changes
e0ipso’s picture

Probably not relevant, but cacheability related calls show up at the top in an initial profiling. I made a request with all fields, with Null cache backend for 50 articles generated by devel_generate.

I haven't dug more than that, I don't mean to imply anything by this screenshot other than: worth ruling it out.

Profile

e0ipso’s picture

wim leers’s picture

IMHO we can close this because we:

  1. now have extensive test coverage
  2. have had a security release that fixed the problems uncovered by the test coverage

Thoughts?

wim leers’s picture

Or perhaps this was intended to be more architectural, along the lines of the changes that #2940342: Cacheability metadata on an entity fields' properties is lost made?

At the present moment some metadata is generated during the response generation (on the EntityResource) and some is generated during the normalization process.

definitely suggests that.

In fact, that is essentially saying that we should be able to remove the executeInRenderContext() call in \Drupal\jsonapi\Controller\RequestHandler::handle(), which I could not agree more with. That's what I worked on in #2883086-43: [PP-1] Port RequestHandler + ResourceResponseSubscriber improvements from REST module to JSON API.

wim leers’s picture

Title: Audit cacheable metadata generation » [PP-2] Audit cacheable metadata generation
Related issues: +#2952714: Group module's GroupAccessResult::allowedIfHasGroupPermission(s)() does not include cacheability

So, I worked on that in #2883086-43: [PP-1] Port RequestHandler + ResourceResponseSubscriber improvements from REST module to JSON API. I tried to drive it to completion, but you can see in #2883086-47: [PP-1] Port RequestHandler + ResourceResponseSubscriber improvements from REST module to JSON API that the scope was growing larger and larger, hence leading me beyond the purpose of that issue. The root cause was LinkManager, for which I created #2952714: Group module's GroupAccessResult::allowedIfHasGroupPermission(s)() does not include cacheability.

Once #2952714 is done, we will be at a point where no cacheability metadata is bubbled/collected outside of the normalization process!

Marking "PP-2": this is blocked on #2952714 and #2883086.

wim leers’s picture

Issue summary: View changes

The IS currently contains this:

  1. Determine if it's possible to have all the metadata centralized.
  2. Do not output a cache tag for each individual entity in collections (probably coming from the normalizer).

The first point is covered by #8.

The second point does not make sense: if the data of a particular entity is listed, then its cache tag must be present too. Removed that from the IS.

gabesullice’s picture

Title: [PP-2] Audit cacheable metadata generation » Audit cacheable metadata generation
Version: 8.x-1.x-dev » 8.x-2.x-dev
wim leers’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.