Hello again,
As I research other headless cms for collapsible scheme feature request i found that prepr have external reference or “Content ignorations” as they call it.
I do not try so I am not sure how they use it. But my idea is to have option defined field which are manage in external source (db, api, ?) and served by squidex API.
This is just an idea i do not need this feature. Also understand that it is something what could be hard to implement from security/performance view.
First of all: You can already implement this with scripting.
I have followed what hygraph is doing and I am not convinced that this is a good idea. I have started to write a blog post about that, but I am not sure if it will ever be published. More about hygraph: https://hygraph.com/blog/graphcms-is-now-hygraph
The idea is to put the CMS in the middle and act as a API gateway:
But such an API gateway has a lot of responsibilities:
Authentication: Determines whether users are who they claim to be.
Authorization: Determines what users can and cannot access. For example some users cannot access certain fields.
Caching: Caches results from the internal APIs to protect them from too many API calls.
Compabitility: Provides the option to integrate all kind of APIs to the gateway, e.g. GraphQL, REST, GRPC, SOAP, XML services and custom protocols.
Logging and Observability: Provides detail statistics about the API calls being made and the peformance characteristics.
Request aggregation: Provide a single endpoint to fetch information from multiple backends. Basically what GraphQL and Hygraph does.
Retry policies, circuit breaker, and QoS: Handles errors when the call to the internal API fails.
Reverse Proxy: Passes through request to the internal API and streams large request and response bodies.
Transformation: Transforms incoming requests to the expected format of the internal APIs and results from the internal APIs to the response from the API gateway, for example if formats or the naming is inconsistent.
Versioning: Ensures compatibility with older clients and provides several versions of the API if needed.
Each of these aspects from above can become very complicated. For example the internal APIs often need to know, who the actual user is, so you have to pass through the user information and connect the internal API to the identity system (e.g. OIDC). If would even say it is not possible to fulfill all the requirements, if you cannot write code directly. Even basic response transformation is not possible in Hygraph at the moment. You can solve a lot of features with complex configuration, but if your configuration becomes too complicated you create logic, which you cannot debug and test anymore.
That is fair i do not think a lot about it. Just from the first looks it seems cool. Maybe for some basic use case. But as i wrote i do not need this at all and it seems you already analyzed this feature a lot and managing everything what you wrote is a lot of things what arguably should not be handled by CMS.
Nevertheless, i think this can be close as it actually looks like sily idea.
I don’t think it is a silly idea, but I am not sure where to draw the boundaries, e.g. right now a lot is already possible with just scripting.
What I am planning to add:
With these features a few things would be solved:
