A Reappreciation of Redux: Why my team at PayPal removed Apollo Client and went back to Redux
summary
PayPal’s team replaces Apollo Client with Redux after GraphQL experiments reveal practical shortcomings: server‑side rendering quirks, unclear client‑side effects from query components, and fragile handling when mixing REST and GraphQL. The decisive specifics are regained: pure reducers over opaque query wrappers, immutable state, middleware and mature time‑travel debug tooling. The measurable outcome is a working codebase that’s easier to reason about and test for large, edge‑case‑heavy products, so Redux wins back the codebase.
AI-written summary · about
chapters (20)
- 0:00Intro
- 1:08About me
- 3:46What technologies were we using
- 5:01Andrew Clarks tweet
- 5:25Apollo Client
- 6:22Secondguessing our choice
- 7:59Redux is stupid
- 8:12Redux is important
- 8:49The future of GraphQL
- 10:27Aristotle
- 11:24Ridiculous Opinions
- 13:03Redux is not insane
- 13:42Not meant to convince everyone to use Redux
- 14:19Why React is so popular
- 15:37Redux reducer
- 16:04Doug Crockford
- 16:38Functional Programming
- 17:51Pattern Implementation
- 19:32Going back to Redux
- 19:44What to take away
related talks
25mA Reappreciation of Redux
29mWrite Queries, Not Code
33mMigrating from redux to Apollo
31mFrom Relay to Apollo, a story of GraphQL clients
24mBuilding Reactive GraphQL Apps With Apollo
24mReact State Management In a GraphQL Era
05mState management in a GraphQL era
27mReact State Management In a GraphQL Era