feat(extension): add "supports" cacheable extension behavior
| Q | A |
|---|---|
| Branch? | main |
| Tickets | #2769 |
| License | MIT |
| Doc PR | WIP |
When retrieving items or collection through a DataProvider, all extensions are applied. These extensions can be dedicated to a resource class and/or operation name.
In order to optimize process, an interface with 2 methods has been added. It is inspired by https://github.com/symfony/symfony/blob/6.1/src/Symfony/Component/Serializer/Normalizer/CacheableSupportsMethodInterface.php :
-
supportsto check if the extension should be applied. -
hasCacheableSupportsMethodto check if the result ofsupportscan be cached by resource name and operation name.
Before implementing tests for each DataProvider and create a doc PR, I would like to know your opinion about this PR.
Do you have some numbers or a Blackfire profile showing the performance gain?
Also, if we add this, this should be done in the new state providers. Data providers are deprecated in 2.7 and will be removed in 3.0, so let's keep them as-is.
Do you have some numbers or a Blackfire profile showing the performance gain?
Not really because it depends on how extensions are implemented and their usage. Caching supports result will improve performances if this extension does not have to be applied.
So, does the https://github.com/api-platform/core/issues/2769 issue still relevant ?
@CvekCoding Do you have some code to share where caching supports could improve performances ?
Hi, these are interesting changes but I'd also like to see some performances improvements before adding classes we need to then maintain. Also Extensions are doctrine-specific and can not be added to the root namespace. As @dunglas said, these interfaces are deprecated anyways and if we can prove there's a real benefit we can add them to the main branch over the new Provider interfaces.
I'll keep this open pending discussion.
Hi @soyuka,
I updated my PR and made some Blackfire profile by calling provide method multiple times but the gain is not terrible. Use cases from #2769 would be interesting.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.