React Apollo vs Redux + REST: Implementing the same feature twice

Gytis Vinclovas
Jul 2 · 8 min read

Why I had to do the same feature twice

Because of the way things have evolved in Wix, we have separate developers working on web and mobile. In mobile we are using React Native, so theoretically same person could work on both platforms. But that isn’t the case now. As time went by, web and mobile developers used different stacks for their modules. One of the modules is using Redux with axios REST calls on the web while the mobile part is using React Apollo. Moreover, both web and mobile use their own middleware servers to communicate with backend servers. That means that every time we want to implement something we have to do the same work twice. This is hurting our development velocity. So I’ve decided to see how much work it would take to reduce the amount of duplication that we do. To do that I had to see how both web and mobile are working right now.

Current module architecture shows why we do same work twice

Feature Explanation

The feature that I had to develop overall was quite simple. I had to enable editing an order. That includes:

  • Adding a button in the order overview screen which opens the edit order form.
  • Adding logic to decide when the button should be displayed.
  • Finally sending updated data to the server and updating the order overview with new info.

Data Loading

One of the first issues that I had to solve was implementing logic whether the loader should be displayed when opening edit form or not. User might open the form from other page and have all the data loaded or he might go to the form directly. That meant that with Redux I had to call multiple selectors and check that all relevant form is loaded. That form is loaded through multiple rest calls and saved into multiple reducers, so for this code I had to write unit tests since it was complex.

Calling the API

Calling the api both with Redux and React Apollo is quite simple. With Redux we emit an action which gets the data out of the store and then calls an api service. With React Apollo we write a mutation query inside the component, and then directly call it inside the component. Once again the amount of code with React Apollo is smaller but personally I don’t like the way you have to write mutations with it. It gets quite messy when you have multiple mutations in one place. React Apollo should get hook support some time in the future, so that should simplify it.

Apollo Mutation pyramid

Updating the local state

After updating the order I have to make sure that the data that we display is correct. With Redux that means updating the state inside the reducer. Once again there are some moving parts here, so to feel safe we write unit tests for it.

Apollo manual cache update

E2E test

Whenever we implement a feature we always write an e2e test for it.

Mocking the query

Typescript and IDE support

When you are working on a bigger project Typescript becomes a really important part for it. But writing Typescript means having to write more code. And I really don’t like typing a lot. For me the best coding experience is the one when I can have as much code completion as possible.

Photo by Glenn Carstens-Peters on Unsplash

Redux benefits

The comparison wouldn’t be fair if I didn’t give any benefits for the Redux. In my opinion the main Redux benefit is that we know that it works and we know that it works well. We can assume that we can easily explain to new people how Redux works. It brings a lot of boilerplate but it doesn’t hide any magic inside itself. If you want to have more flavour in Redux there are libraries that can bring it to you. There are libraries that enable less verbose code, add integrations with other libraries and many other things. Redux is just really popular and you know that if you need something you can find it.

How we are planning to reduce the amount of work

Implementing this feature twice was needed to see how much similarities and differences we have between web and mobile. Moving forward one thing that is really clear is that we need to use one middleware server instead of two. And here GraphQL is a clear winner. GraphQL allows to customise our queries for web and mobile without having to create separate endpoints for it. Also it simplifies our e2e tests because we don’t have to start a real server anymore.

Some statistics

Comparing statistics of how much code I had to write and how many work hours I had to put in is not fair, because web and mobile infrastructure is too much different. So I am giving these numbers just as a general information.


I hope this post helped you to see what you can expect if you were using Redux with REST or React Apollo. In the end you can definitely live with either one and you should weigh the pros and cons of one or another. If I was to implement a new project I would choose React Apollo, but I wouldn’t rush to rewrite a Redux project to it. But one thing I can recommend is to use GraphQL whenever possible, especially if you think that you might have multiple clients in the future.

Wix Engineering

Architecture, scaling, mobile and web development, management and more, written by our very own Wix engineers.

Gytis Vinclovas

Written by

Software Engineer at Wix.

Wix Engineering

Architecture, scaling, mobile and web development, management and more, written by our very own Wix engineers.