Photo by laura buron on Unsplash

Introduce an opinionated react front end architecture


  • react.js is just a view (+ some controller logic) in classical MVC
  • redux introduces some architecture but its incomplete
  • why we need to become opinionated
  • suggested solution for a react-redux architecture
  • advantages of using a completely defined architecture

React is a library, not a framework

Its known react is just a library. If we would map it to the most known design pattern MVC then it would be the V(iew) + some ability to trigger controller actions, who can exist on the view itself.

If we add redux to the stack we usually follow the official flux architecture.

So framework wise we cover the MVC functionality and unfortunately this is still not the complete picture. To make an example this are the parts of the logic that are not mentioned in the flux architecture. The structure for the rest of logic is open for the team to decide.

  • logging logic with addition reporting to some external bug tracking tool
  • domain specific logic, like some tax calculations or business objects management that is used from several react components
  • environment management, specifically activating some feature in dependency of the environment at runtime or feature toggles
  • technically neutral http and REST logic
  • i18n logic used by many components
  • mock data generation and management from central place, used by many unit and integration tests
  • redux store setup, specifically in dependency of the current environment

So we see there are many areas left out of the flux architecture, since its goal is to organise the react view part itself and not more.

In case its left undefined where all the other logic parts go, developers will randomly make their architectural decisions. In the most cases it will result in an uncoordinated architecture, not centrally handled concerns and many specific assumptions.

So what is the solution? Obviously to cover the rest of the stack and to answer the questions, that seem unclear.

After I started working with the javascript, this issue was one of the first big problems in my eyes. Coming from the java back end development, I would say that any undefined logic group should go into a specific module. In general the service object pattern fits, that seems to be known to some people. In the same way many spring applications structure their logic.

So I integrated the following react-redux architecture that is based on best practices from a spring back end.

Extended flux architecture

Core new points of this architecture

  • we have a services layer, that is used top down from the react components, I will describe a service in a separate article in more detail
  • it is strictly forbidden to break the architectural borders, like passing around the reference of the dispatch function from redux to other architecture layers
  • we have a rest calls middleware that works with specific rest actions, I will present it in a separate article as part of this series.
  • there is no redux thunk or saga, we use a redux middleware to make async calls in only ONE place
  • something that I called “the action chains” and “service actions” are used as a pattern, I will describe it with the middleware

The result

  • with this extended architecture we can clearly assign new types of logic to the services layer. We cover the client site to the end and developers have a clear framework to structure the code
  • within a company you can rely that any project is following the same structure, so people have an easier way to jump in and find their way around
  • there are no unknown or single person specific patterns used in the stack
  • junior developers can focus on parts of the present parts of the architecture, without having to know everything right away

I used this stack in two projects right away and made the best experience with it. During this time I brought at least 4 new developers on board into this projects. My colleagues we productive after 1–2 days inside the code base. Besides a react router integration we had no other architectural choices to make.

The core simplification comes clearly form the rest middleware and the services layer, wich I will present in the following articles.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Location via latitude longitude in a flutter

The new Apollo Server is 💯

Analyse Your Commodity Trading By Getting Rates In JSON API

React js Experience Developer 10 Most Essential Tips For Application Development

The 3 essentials to get started with styled-components

Two-Factor Authentication (2FA) Using Speakeasy and Express.

Maximum AND value of a pair in an array

Why shallow rendering is important in Angular unit tests

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
Denis Lutz

Denis Lutz

More from Medium

FE Standards

What is the difference between react js-and react native — clarification

Client-Side Routing in React

React Life Cycle Hooks