Description
Have you all thought about supporting a compiler plugin for a client-side @defer solution? One obvious use case for us is that our GQL service can't keep the connections open to support proper @defer yet. However, even assuming that's resolved, I don't love that a large GQL query would need to be sent to the server if a partial match is found, and would prefer to break it down into smaller queries that might be more reasonable to be sent together. Do you think I am thinking of GQL wrong in wanting to compose it this way?
I'm thinking about a case where a majority of the query is fulfilled by the cache, which might request 3 different types of data, and we only need to go to network for 1 of the 3. I guess one answer could be to split up the query into 3 separate distinct types? I was thinking it would be nice for apollo to split these at compile time with some directives so my experience code doesn't need to include these optimizations for network usage at that layer
Concerns [from slack]:
- That would need constructing ad hoc queries indeed - either at build time or runtime.
- I think the usual objection there is that it completely breaks persisted queries and/or any kind of observability
- Also you would need to embed a GraphQL parser/writer in your app, might not be huge deal but still added complexity
- The issue is if you have N branching point like this, you have to whitelist 2^N different query variants
- All doable in theory of course but people are already finding GraphQL complex so that might be the last straw for 99% of users out there
Mitigations:
- Could still support pre-compiled queries with PQ, not fully dynamic fields though
- having a low limit per query to prevent that would be necessary - or some cyclomatic complexity / cardinality rule
- It feels similar in optimization to the embeddable directive in the cache, not in implementation but in how the teams think more granular about the impact of their schema.
https://kotlinlang.slack.com/archives/C01A6KM1SBZ/p1749611277122049