How GraphQL replaces Redux

“What?” You scream. “GraphQL is a server-side query language and Redux is a client-side state management library. !”

That’s a good question. Hold on tight, because I’m going to answer your question head-on.

Before I answer, let me give you the background. As early as 2016, our front end team at Pathwright moved the client code from Backbone & Marionette stack to React. For UI, the declarative Model is much more intuitive than the MVC Model.

For us then, and many times still, it was the feeling of fresh air.

Everything is so harmonious except state management. To take care of state management, we quickly started using the Flux architecture, which felt great at first.

However, as our state management becomes more complex, more and more intermediate layers are slowly added. Once you have a bunch of stores and branches in your state tree, you end up having to reproduce the business data and logic on the server side on the client side.

What we ended up with was some nice, clean declarative React components and a data layer that turned into a garbage dump. It contains a large batch of action, Reducer, asynchronous middleware, de-Normed business data and logic.

It just doesn’t feel right.

Then we started using GraphQL. We initially implemented GraphQL on a dashboard with access to multiple data sources and quickly fell in love with it, a scenario that would have been a nightmare to implement using RESTful apis. It’s like meeting React for the first time. With enthusiasm, we worked overtime writing code and finally got the new GraphQL server up and running in just two weeks!

Then we started replacing some of the REST API with GraphQL, and it was still pretty cool.

A side effect of this approach (saga) is that UI components using GraphQL no longer require a Store. We also pre-implemented things like store and action in the beginning, but eventually got rid of them because we found there was nothing left for them to do.

The results led us to three surprising facts:

  1. Most of our state management code merges or changes data obtained from different REST apis (Reducer, selector, Action, etc.);

  2. A lot of the most complex state management code does is get asynchronous data from different sources loaded in the proper order and passed to specified routes (Saga, middleware, Thunk, etc.);

  3. In fact, for almost everything else, such as UI component state, React native state management is just fine.

If only I had used GraphQL! We shed tears of regret for our hindsight…

Then we removed a lot of code and felt good.

My earlier statement that “GraphQL will replace Redux” may have been a bit misleading, but GraphQL is really replacing REST apis, and the result is that most of our state management code is rendered useless.

These state management libraries are of little use when the client can control the content and format of the state so that it meets its needs with a single server request.

To visualize this idea, let’s use an analogy. Suppose our UI component has a conversation with the back-end service through the state management library.

The conversation would go something like this:

Much of what Redux and the accompanying Side-effect management library do is to simplify the tasks in the left-hand dialog.

I think GraphQL can completely replace What Redux does for most client applications.

That’s not to say Redux itself isn’t useful, it’s a great library. The state management model introduced by Redux is here to stay.

For example, Redux can help you a lot in situations where you can’t get your hands on the backend stack and you can only use the REST API.

Redux is also useful in cases where you need to manage very complex state that needs to be traceable and controlled for persistence, such as low-level tasks like client caching, offline data synchronization, and so on. In fact, some popular GraphQL libraries, like Apollo, can use Redux as a cache.

But…

If you can use GraphQL instead of REST, you should. Doing so allows you to significantly reduce the complexity of state management in your client application and narrow the focus of your client code to the rendering of data in your UI components.

Of course, you can still use Redux in your client code, but you just don’t rely on it as much as you used to. Plus, with GraphQL, it’s really cool to have the possibility to delete half your code.

Read more:

Reducing our Redux code with React Apollo:

https://dev-blog.apollodata.com/reducing-our-redux-code-with-react-apollo-5091b9de9c2a

Original address:

https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d