search

ecamp / ecamp3

eCamp v3 is a web-based app for camp and course planning. The application is specialized for camps and courses of youth associations and for Y+S offers in the sport of camp sports/trekking.
https://ecamp3.ch
GNU Affero General Public License v3.0
111 stars 49 forks source link

Related collections: Performance vs. supporting non-HAL formats #2829

Open carlobeltrame opened 2 years ago

carlobeltrame commented 2 years ago

Some related collections are expensive to compute, in the sense that they require additional database queries. Examples include Period#getContentNodes() and Day#getScheduleEntries().

With our current implementation, we try to support not only the HAL JSON format, but also JSON+LD and GraphQL. For HAL, we sometimes add an annotation #[RelatedCollectionLink], and the API response therefore only contains a filtered link like /content_nodes?period=/periods/1a2b3c4d, so all the contentNode data which is fetched from the database is completely ignored afterwards. So if we were only supporting HAL JSON, there would be no need to perform these additional database queries. But omitting the queries would break the JSON+LD format and possibly also GraphQL (not sure about that one). This affects all API calls where a period or day entity is normalized (e.g. when loading or patching a single period, when loading all periods, when loading a camp with embedded periods, etc.)

This issue was originally raised by @usu in https://github.com/ecamp/ecamp3/pull/2700#discussion_r867438094 and the decision might influence how to proceed in a past discussion in https://github.com/ecamp/ecamp3/pull/2683#discussion_r873156500.

We should decide how we want to proceed with such getters on our entities. Probably we should assess the performance impact of these first.

manuelmeister commented 2 years ago

Core Meeting Decision

We will drop JSON+LD "support" when we have performance problems Currently we have no tests that cover the JSON+LD support anyway. We see how good the support for GraphQL is in version 2.7

@usu makes a performance analysis of the issue mentioned above

BacLuc commented 1 year ago

Now we have performance problems with the additional queries.

Core Meeting Decision

That this is transparent, it would be good to also remove json-ld and hydra from the error formats and the input formats. That we can remove it from the error formats, we need to add the header Content-Type: application/json in the Create* api tests. They don't specify the Content-Type currently, and then api-platform falls back to json-ld, which is not uspported. Plan: Add the headers in the tests step by step. If this is finished, remove json-ld from config/packages/api_platform.yml and remove it from the Error Serializer

usu commented 1 year ago

Related to this: https://github.com/api-platform/core/pull/5675/files# was merged and should be available in api-platform 3.2

This could be a alternative solution to avoid overloading of data