GRAPHQL How to replace Redux

Comment: Using GRAPHQL can greatly simplify the code in the Client state Management Section.

️ Switch to react

Story background: In 2016, Pathwright's front-end team started switching the client's code from Backbone & Marionette to React. For us the declarative model of the UI is more meaningful than the MVC model.

We use the flux architecture to manage as the application states, and as the business becomes more complex, it adds more and more layers of indirection. When we start working on a branch logic in the store or state tree, we actually replicate the service-side business data and relationships to the client.

We have elegant declarative React components, but the data layer is really action, reducers, asynchronous middleware, and de-normed data logic.

It all feels so wrong.

️ Switch to GRAPHQL

When we tried to graphql, we fell in love with it immediately. We replaced the graphql with a bunch of REST APIs. The store is no longer needed when our UI uses these new graphql. We usually need to create a stores,action wait, but eventually we delete this part of the content because it's not necessary.

Three main reasons for this view

1. Most of our state management code is concerned with merging and transforming the REST resources from the scattered to the data that apply to our UI.
2. Many complex state management is the orderly acquisition of all asynchronous data (sagas, middleware, thunks, and so on.) Actually, in addition to this part of the above, we use our own
3. React state can be a good fit for our daily business.

About GRAPHQL and Redux

Front may be a bit of a heading party. What we really replace is the REST API, and when we successfully replace it we find that most of the state management code is no longer necessary.

When a client can control a specific template that returns data on the server (only one request), which greatly simplifies our application logic (primarily the State Management Section), we no longer even need to use the state Management library to help manage our libraries, because the application logic becomes simple enough.

To illustrate this, let's say our UI communicates through the state management library and back-end services.

This may be the case:

The difference between redux/rest and APOLLO/GRAPHQL is intuitively listed, and Redux has implemented a lot of content for us, but it is unavoidable to handle multiple requests. The GRAPHQL simplifies this part directly from the reduction of processing logic.

I think that for most client applications, GRAPHQL can completely replace the need for Redux. This is not to say that Redux does not meet demand (which is actually a great library). And Redux helps us deal with rest (because many times we have no control over the backend interface using GRAPHQL, mostly using rest).

But...

If you can use GRAPHQL instead of REST, then I recommend using the GRAPHQL advantage to eliminate the complexity logic in client state management.

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