Support local-only fields

[tgyhlsb]

Feature request

Local-only fields as the web framework supports: https://www.apollographql.com/docs/react/local-state/managing-state-with-field-policies/

Motivation

We have been trying to use Apollo cache as the source of truth of our data model since we moved to GQL. But we have more and more properties that only belong to the client (mostly the upload state of objects or properties related to optimistic behaviors of mutations).

To do this, we mix the cache with other in-memory storages, and build data streams to merge those before exposing the data to upper layers of the app.

The biggest pain points we face:

• We have many isolated in-memory storages that will require their own persistence mechanism once we want offline support.
• The complexity of the app increases quickly due to all those complex stream to merge data.
• We heavily dependent on Combine to build those streams. But we are now building an SDK and we want a lower minimum iOS version (and as few dependencies as possible), forcing use to work with closures instead. Making the streams even more complex (no map, flatMap or combineLatest out of the box).
• Mixing local-only fragments (not yet sent to the server), properties stored outside of the cache and paginated lists makes it exponentially complex to maintain.

If this feature is not planed in the roadmap we plan to move our source of truth to some DB (CoreData or Realm) and use Apollo for the transport layer only. But that would mean using only a small subset of what your framework offers.

Proposed solution

Implement https://www.apollographql.com/docs/react/local-state/managing-state-with-field-policies/

[calvincestari]

Hi @tgyhlsb, thanks for the feature request. This is a feature that we might be able to support in a future 1.x release; I can't give a timeline for when but we can certainly weigh it against our other priorities - cc. @jpvajda. Our public roadmap is always available to see what it is we're currently working on too.

[jpvajda]

@tgyhlsb Thanks for sharing your use case here. We have been considering supporting local only fields in Kotlin client as well, I'll link these 2 issues together as many developers use both our mobile clients and this may be a shared need across both mobile clients.

apollographql/apollo-kotlin-normalized-cache#217

[tgyhlsb]

Thanks folks, can't wait to test this feature :)

[tgyhlsb]

Hello,
I've seen the v1.x label and 1.0.0 has been release. Do you have an update for this feature?

[AnthonyMDev]

This feature was not included in 1.0.0 and is not slated for the soon to come 1.1.0. But it is something we do want to make happen soon.

The re-written code generation engine for 1.0.0 makes this a lot easier to implement. A big point of 1.0 was creating a better foundational API that enables all of these little features we want to add. The old code-gen engine made this near impossible.

Now that 1.0 is released, we expect the velocity of implementing new features like this to increase noticeably!

The most challenging part of this is going to be ensuring that local-only fields are able to actually be resolved locally, reading and writing from the cache, and then merged into the response from the network request.

Likely, the best implementation of this is going to rely on implementing field policies first. Which is also something on our roadmap, but it's a pretty significant piece.

We hear you loud and clear, and this feature is a totally reasonable request. The underlying mechanisms to allow it are just not in place yet. If this is time-sensitive for you, I think the right approach may be moving to using something else as the local source-of-truth. (I personally recommend Realm over CoreData, but that's just my opinion 😉 )

[tgyhlsb]

Thanks for the update 🙏

We might start using a db as source of truth indeed. I'll keep an eye on this issue tho 🙂

[cerupcat]

I don't see this directive in the roadmap anywhere. Is it still planned at some point?

[AnthonyMDev]

This hasn't been a priority feature for us yet. We do want to implement this at some point, but it's not on our roadmap because it hasn't been actually slated for us to work on currently. It's a backlog item.

But our priorities are highly affected by community feedback. The most effective way you can get this feature implemented (besides working with us to build it and contribute a feature PR yourself) would be to get others who want this feature to comment on this issue and express that! We literally just released a feature today that was way way far down our back log due solely to community feedback that it was important to them (#2738).

Implementing local-only fields is a relatively significant lift. It affects a lot of different pieces (code generation, execution, caching, etc.) and is going to take some significant thought and effort to implement well. If anyone in the community is interested in getting involved in writing the actual code, I am always willing to get on a call or two and think through what needs to be done to guide a PR though!

[irisha8787]

local-only fields would be lovely! +1.