Have you all thought about supporting a compiler p...

# apollo-kotlin

[John Marshall]

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 is atm a lamda based GQL service which 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?

[John Marshall]

I can file an issue but wanted to check if I am missing something on why this is against the grain first. I like isograph's idea for this: https://github.com/isographlabs/isograph/blob/e078bc1b89d510191d66397b4b05e73a3dbd1da9/libs/isograph-react/src/loadable-hooks/useClientSideDefer.ts

[bod]

So that would be: emit whatever's in the cache first, then emit the network? If so, I think that's essentially the cache first policy but with partial results (which can be enabled in the new cache) (+ maybe @catch)

[John Marshall]

Not quite, I don't want to go to the network if I have the data and it isn't stale/expired

[bod]

I see.
Yes that’s doable by looking at response.hasErrors after the cache call. If there’s no errors, everything was fulfilled from the cache and no need to go to the network.

[John Marshall]

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

[John Marshall]

Sounds like an example would help

[bod]

oh I see you'd like the network query to only fetch what's not already in the cache?

[John Marshall]

yup

[bod]

That would need constructing ad hoc queries indeed - either at build time or runtime.

[John Marshall]

or at least the 'sub-group' of content within the general field its associated with

[bod]

I feel like something like that has been asked before, but can't find a ticket now - so don't hesitate to open one.

[mbonnin]

I think the usual objection there is that it completely breaks persisted queries and/or any kind of observability

[John Marshall]

yea - so I think some trade-offs could help. Having only the fields that were changed would impact those points - but allowing a @clientDefer directive or @segment on some high level fields could be a reasonable middleground?

[John Marshall]

you could still support pre-compiled queries with PQ

[mbonnin]

Also you would need to embed a GraphQL parser/writer in your app, might not be huge deal but still added complexity

[mbonnin]

you could still support pre-compiled queries with PQ

The issue is if you have N branching point like this, you have to whitelist 2^N different query variants

[John Marshall]

right I think having a low limit to prevent that would be necessary

[mbonnin]

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

[mbonnin]

In all cases, if we don't have an issue, please open one, would be good to have this discussion in the repo

[John Marshall]

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.

[John Marshall]

ill open an issue - wanted to see where you all were leaning first. thanks for the discussion

[John Marshall]

tried to capture your points as well: https://github.com/apollographql/apollo-kotlin-normalized-cache/issues/175