[jdiaz5513]

I'm 100% with you on this. One of my teams just spent 3 weeks ripping out all of that tedious (and error-prone!) resolver code that resulted from trying to use apollo-link-state for local state management and switching it all to redux instead.

It is insane how many silent failure modes the Apollo cache has. Performance and ability to estimate work (predictability) went through the roof since then. It's just way overcomplicating things to do state management this way - Apollo is a lovely GQL client otherwise.

I may do a write-up on this one day, as a cautionary tale. It boggles the mind that this is being pushed so hard as an ultimate solution to state management - nice in theory but awful in practice.

[Stoids]

I'd love to read something about your experience. We are currently using Apollo for one of our newer projects. We've written Redux apps in the past and understand the tradeoffs and limitations that come with that approach. We really love the component-level declarative data-fetching of Apollo client, but were pretty hesitant around the apollo-link-state stuff.

How are you integrating GQL in your Redux code? Do you still use Apollo Query/Mutation components? Do you use Redux in lieu of the Apollo cache? How do you deal with the slight mismatch of denormalized GQL data with a normalized Redux store?

I understand the problem that the Apollo cache is solving, and I feel like I do a lot of low value handwritten code when I use Redux instead--but the visibility and transparency of Redux still feels worth it?

I think leaning too heavily into apollo-link-state is going to draw the same boilerplate complaints of Redux. The amount of client code generation needed, plus all the schema details bleeding into your code (__typename)... doesn't feel like we are at the "solution" yet.

Just a few of my rambling thoughts. Kudos to the Apollo team for continuing to push the community forward. These are hard problems and we won't solve them without people trying to innovate.