Using Redux on the Server and on the Client

Question

Lately, I've been building Universal web apps using two redux stores: one on the client and one on the server. Redux seems like a great tool for managing state data. Is it ok to use Redux for stuff outside of React? Could you use Redux in a command line app for instance?

I feel like this client store and server store approach breaks the "single source of truth rule", but it feels so nice and so far has worked well. What I've found is I can reuse about 80% of the reducers to compose both stores. State on the server is typically a collection where state on the client can be a single object.

For example: Let's say you have client state for a chat app:

{
    user: 'mike@aol.com',
    room: {
       name: 'sports',
       users: [ ... ],
       messages: [ ... ]
    }
}

The server state is similar and can use similar reducers, but it uses collections instead of objects.

{
    connectedUsers: ['mike@aol.com', ... ],
    rooms: [
      {
          name: 'sports',
          users: [ ... ],
          messages: [ ... ]
      },
      { ... },
      { ... }
    ]
}

Creating both state trees reuse a lot of the same reducers. This approach has also allowed me to send actions to the server and respond with actions from the client. It is also not very hard to use the server store to generate state client stores when there are new connections.

My Question

I've had fun with this approach to a Universal App. Does this break any of the rules? Can you have a client store and a server store? It is not very hard to use the server store to generate the initial.

Is anyone else working Universal apps this way?

Answer 1

The main problem that occurs to me with this approach is that the redux store on the server will stay in memory on the node instance. This would be a problem when you go to production and want to scale up from a single server instance.

For example, if you deploy to Heroku, when you increase the number of dynos you're increasing the number of node processes. Each node process will have it's own copy of the redux state. So your client might get one process on the first request, and a different one with different data on the next request.

Answer 2

it is probably a bit late response, but anyway. I've made an experiment, where I was implementing a multi-browser multiplayer tic-tac-toe game. Where Redux was a main state distributor on the back-end.

The experiment ended up in a series of articles, which in a pretty detailed way describe the hows and whys of using Redux on the backend, independently on whether you prefer to use Redux or classical React state on the front-end.

1. Server-side Redux. Part I. The Redux.
2. Server-side Redux. Part II. The Design.
3. Server-side Redux. Part III. The Code.

Feel free to shoot me a message if you will have any questions.