apollographql / apollographql/apollo-kotlin-normalized-cache
Support @clientDefer compiler plugin for more granular/optimized cache/network behavior
- Dominant language
- Kotlin
- Stars
- 24
- Forks
- 15
- Avg merge
- 23h 26m
- Merged PRs (30d)
- 5
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
Contributor guide
No contributing guide indexed for this repository
Research direction
The issue names no files, tests, or concrete entry point. Start by reviewing the compiler-plugin and normalized-cache architecture against the @defer, persisted-query, and observability constraints described here. Done would require a scoped design and an agreed implementation path, which the issue does not yet provide.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, kotlin
- Domain
- performance, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100