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
- Determine if it's possible to have all the metadata centralized.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | article?_format=api_json&xhprof=on 2017-01-08 19-06-56.png | 441.07 KB | e0ipso |
Comments
Comment #2
e0ipsoComment #3
e0ipsoComment #4
e0ipsoProbably 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.
Comment #5
e0ipsoComment #6
wim leersIMHO we can close this because we:
Thoughts?
Comment #7
wim leersOr 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?
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.Comment #8
wim leersSo, 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.
Comment #9
wim leersThe IS currently contains this:
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.
Comment #10
gabesulliceComment #11
wim leersI think it's safe to consider this done :)