The State Management Rollercoaster
summary
Chronicle of a migration: a real use case shows Apollo and Redux Toolkit used side‑by‑side with Neo4j and GraphQL, partial TypeScript adoption, and a staged move from Gatsby to Next.js; results API migration at Maze exposes the concrete tradeoffs—feature‑flagged coexistence forces a custom React context that normalizes shapes, optimistic UI and refetch invalidation become hairy, about 35 engineers see mixed wins, and the plan surfaces: progressively move server state to Apollo while keeping app normalization and escape hatches.
AI-written summary · about
chapters (12)
- 0:00Tech debt and state management
- 3:55Results API migration origins
- 7:05Redux complexity struggles
- 9:36Apollo over Redux
- 13:50Next.js migration with Redux/Apollo
- 17:42Mixing Apollo and Redux
- 19:50Redux Toolkit solution
- 22:21Unique state needs
- 24:31Unified state abstraction
- 29:09State complexity causes
- 33:25Future state strategy
- 35:14Closing & Q&A
related talks
30mReact state management in a GraphQL era
52mState management in a GraphQL era
24mReact State Management In a GraphQL Era
25mReact state management in a GraphQL era
22mReact State Management in a GraphQL Era
05mState management in a GraphQL era
27mReact State Management In a GraphQL Era
33mMigrating from redux to Apollo