This question, do we really need redux store or ngrx in Angular application is coming back over and over. I already have feeling that I was talking about this topic too many times. So I decided to wrote down my thoughts.
First I will quick explain how ‘normal’ or service based data flow in Angular application looks like:
Angular Service Based architecture
Above we have typical Angular component which is responsible of all view calculation and is sending and receiving data from the service. Service is processing data gathered from component and send it to our server. It is also processing data from the server and send it back to component. Simple, logical and fast to implement. Am I right? Not really, because our application will grow and then we are ending with something which will rather looking like this:
Or in other words in total mess. You are now probably thinking: “No I will never let my application end like this. I will use immutable patterns, always think how to connect things properly, use one responsibility principle and so on. I’m senior developer and I’m coding for ages. I know what I’m doing”
Maybe you are right. But you have to remember that probably not only you will be coding this project. In bigger ones there will be also junior and mid developers who will work on it. Another thing is that you as super senior developer will not be working on this project forever. Some day you will leave and it will end exactly like on the picture above. Even you will loss track what is happening there. Personally, I have been working on few service based projects and each of them ended like one that I described before. So you can ask why I think redux will solve this issue? First let me explain how the typical angular redux architecture looks like.
Angular redux architecture
Redux architecture is build using some specific parts where each of them have its own role. I will describe here typical responsibility of each of them:
- services – getting data from backend
- actions – the only source of information for the store
- reducers – saving data to store
- effects – adding side effects when action is triggered
- selectors – getting data from the store
- pages – facade between dumb components and store, triggering actions, and getting data from selectors
- components – dumb components with only input output and occasionally some view manipulations
- store – one source of truth for the application
So we start with dumb component which is sending data thru @Output to the page component where we trigger appropriate action. This action can send data to reducer or trigger additional effect like for example gathering data from the service. Anyway, finally data will go to reducer which will put it to right data structure in the store. From there we can only take data using specific selector and return it to page component. The final dumb component can only communicate with its parent page component and take data from it. Also as we can see that we achieved here a one directional data flow. Important is that our store is immutable which mean that you cannot modify it. This ensure that we can predict, based on performed actions, what will be there in specific moment of time.
Now, when I shortly explain what is characteristic for each architecture. I want to show you what is good and bad side of them, when we try to make some comparison.
Comparison between redux and service based architecture in angular applications
Angular service based architecture:
- short time of implementation
- easy to learn
- more readable in small application
- lot of freedom in implementing data flow
- not scaling well
- hard to maintain in larger application
- hard to follow data flow
- without immutability it is easy to have some unpredictable changes
- lot of freedom in implementing data flow
Angular redux based architecture:
- easy to maintain when properly build
- easy to track potential bugs due to awesome toolkit
- readable and easy to follow data flow
- strict rules, so its easier even for large team to build consistent project
- immutability is a must
- easy to test
- longer time to introduce changes
- Higher threshold of entry – you have to understand functional programing
- you have to strictly follow redux pattern so you lose some ‘freedom’
So, at first glance you can think that service based architecture is good for small application and redux based is good for the larger one. No! Its a trap! If you are working like me in large corporation, then you probably already know typical software live cycle. First, you create small product or even a POC. Ideal case for service based architecture? NO! Because are two possible outcomes: your app will die or live. If you are like me, you will always believe in the second option. But then app will also grow. New ideas will raise and feature from business side will come. And to your surprise you will see that your small application is now quite big and complicated, but still build on sand.
Believe me it is really hard to convince anyone that app which have only one or two years need really big refactoring or even rewriting. Service based architecture you were doing to save some time is now probably out of control. So, if you are not 100% sure that your small app will be small forever implement redux and save yourself unnecessary trouble. Cost of potential refactoring will be hundred times larger then the time that you will save going the easy way.
So, is redux architecture always good? Of course not. For example, application that not need to process state and only showing data gathered from server, or really small widget that you use in your microfrontend larger project, can stay with services. But for typical angular application redux is definitely way to go. My opinion is that you shouldn’t think if you really need redux in your app. Instead is better to think why you don’t need it and only if you find enough arguments against it, you should go with service based architecture.