How GraphQL Replaces Redux

⚛️ Switching to React

First, a little back-story. Back in 2016, the front-end team at Pathwright began switching our client-side code from a Backbone & Marionette stack to React. The declarative model for UI made much more sense than the MVC patterns we’d been dealing with.

↪️ Switching to GraphQL

That’s when we tried GraphQL. We began by implementing it on a new dashboard that combined a bunch of different data sources (this would have been a nightmare to do with our RESTfull APIs) and soon fell in love. It was like discovering React for the first time. Enthusiasm was high enough that we ended up getting our newly minted GraphQL server in production in only two weeks!

🤯 Three Startling Realizations

This led to three startling, yet obvious in hind-sight, realizations for us:

  1. Most of our state management code was concerned with merging and mutating data from discrete REST resources into the right shape for our UI (reducers, selectors, actions etc.).
  2. A lot of our most complex state management was trying to manage the asynchronous nature of getting all that data in the right order for a specific route (sagas, middleware, thunks etc.).
  3. Practically everything else, UI state, worked great with plain old React state.

So about GraphQL and Redux…

My title was a little mis-leading (made you click?). What we really replaced was our REST API and then found as a result that most of our state management code was no longer necessary.

Redux + REST left — Apollo + GraphQL right

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mark Johnson

Mark Johnson

Web designer, developer, and teacher. Working at the cross-section of learning and technology. Co-Founder, CTO of Pathwright. Launcher of side projects.