We have a react/typescript app with a GraphQL back-end that is using the Apollo client. We're looking for an Apollo expert to help refactor the front-end state management architecture.
The app is currently broken down into pages, and components. Right now (mostly) pages run all the GraphQL queries and then the components below them use that data. We also use React Context in some places, and we often load the response from GraphQL into a local state variable through useState which gets passed down to child components.
There are a few problems with the architecture for managing state on the front-end right now. Most of these problems come from the fact that we're not using the Apollo client and cache as the single source of truth for the front-end. Some of the issues are:
- Having the state both in the cache and in useState variables means there can be bugs caused by not keeping state consistent between both.
- We have to pass useState variables down the component tree and ensure they remain updated.
- We re-run network requests to fetch data on all page loads, and mutations, instead of updating the right parts of Apollo's cache so that only some components re-render based on what data has changed.
We would also like to start using Apollo's subscription functionality to update the cache over websockets. If you have a lot of experience with the Apollo client and using its cache for front-end state management please reply with a plan explaining how to best use it in our case.