React+Redux项目集成Apollo Client：双Store是否合理？能否用单Store？

Great question! This is a super common point of confusion when adding Apollo Client to an existing Redux-based React app, so let’s break it down clearly.

Is using a dual-store setup reasonable? #

Absolutely—this is actually a widely accepted and reasonable approach used in many production applications. The key here is recognizing that Apollo Client and Redux serve distinct, complementary purposes:

• Apollo Client is purpose-built for handling GraphQL data fetching, caching, and synchronization. It comes with out-of-the-box optimizations like normalized caching, automatic cache updates after mutations, request deduplication, and pagination handling—all things you’d have to build from scratch in Redux, which would be extremely time-consuming and error-prone.
• Redux shines for managing local application state that isn’t tied to remote GraphQL data. Think UI state (like sidebar collapse/expand status, active tab), form input values, user session metadata that doesn’t come from your GraphQL API, or global feature flags.

By keeping these two stores separate, you’re enforcing clear responsibility boundaries. This makes your codebase easier to maintain, debug, and scale—each tool does what it’s best at without stepping on the other’s toes.

Can you merge them into a single store? #

Technically, yes—but it’s almost never worth the effort, and I’d strongly advise against it. Apollo used to offer tools like apollo-link-redux that let you integrate its cache into your Redux store, but this approach has fallen out of favor for good reasons:

• You lose most of Apollo Client’s built-in optimizations. Apollo’s caching logic is tightly integrated with its query/mutation handling; shoehorning it into Redux means you’ll have to manually manage cache updates, request loading states, and other logic that Apollo handles automatically.
• Your Redux store becomes unnecessarily bloated and complex. Apollo’s normalized cache has a specific structure that’s not intuitive to work with in Redux, making debugging and state inspection far harder.
• It’s redundant work. Apollo Client already acts as a fully-featured state management solution for GraphQL data. Merging it with Redux adds extra layers of complexity without any meaningful benefits.

Best practices for coexisting stores #

If you go with the dual-store setup (which I recommend), here’s how to make them work smoothly together:

• Clear state ownership: Stick to the rule: Apollo manages all GraphQL-fetched data and related state; Redux manages local, application-specific state.
• Seamless integration: You can easily access Redux state in Apollo components using useSelector or the connect HOC, and you can trigger Apollo queries/mutations from Redux actions using the Apollo Client instance (you can inject it via context or pass it as a dependency).

内容的提问来源于stack exchange，提问作者Mohamed Taboubi