Related collections: Performance vs. supporting non-HAL formats

[carlobeltrame]

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 #2700 (comment) and the decision might influence how to proceed in a past discussion in #2683 (comment).

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]

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]

Now we have performance problems with the additional queries.

Core Meeting Decision

• we drop jsonld support.

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]

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