Anthony Miller

Hey there! We're making progress. The suggestions in this RFC have made us re-think the Interceptor APIs, and the Apollo team has been busy preparing for and attending GraphQL Conference...

Looking for more feedback here! > I have concerns about taking away cache read/write interceptors. There's a fundamental difference in providing these versus a custom normalized cache. The former operates...

@woodymelling > With these upcoming changes, will Apollo's interceptors properly receive [TaskLocal](https://developer.apple.com/documentation/swift/tasklocal) values from the request callsite? > With full structured concurrency, this happens automatically, but with the class-based interceptors,...

Thanks for all the feedback on the desire for a single return `async` fetch function. We'll devise some solution for that. We’ll need to do some exploration to see what...

I think my PR #528 might fix this. If it doesn't, we should look at this. With the code I've added there, it shouldn't be hard to fix this next.

This use case will be supported by the implementation of the `@fieldPolicy` directive. This is currently [on our roadmap](https://github.com/apollographql/apollo-ios/blob/main/ROADMAP.md#fieldpolicy-directive), but we haven't started implementing it yet. Thanks so much for...

The way it's described in the docs works only if we already know that the server has returned an object in the past for the field with that id. When...

It will update the fields on that object in the cache. Say you call `updateObject` on a `Launch` object with id `123`. The cache record for the key `Launch:123` will...

Thanks for the request @trevor-holliday-instacart! We would need to do some exploration to ensure that this is feasible, but I can't come up with a reason why not off the...

@trevor-holliday-instacart I'm curious why you believe this is affecting your build times so dramatically. Have you done profiling to validate that this is the case?