Hello everyone and welcome to the podcast “My Two Cents”.
The topic of today’s podcast is modular monolith.
So we will start by going through to the monolith structure and what problem to face with monolith applications, then we will talk briefly about micro frontends and then we will come back to modular monolith. An approach to software development that will lead us to easy migration to micro-frontend.
In the early days of development, especially in frontend, the projects were not that big and it was manageable 5-6 people. But as time progressed more and more people joins the team, requirement grow, features list grow and after some time code became really messy.
It is no longer manageable and it is restricting the teams to put out new features. During that time the developers think about breaking it down. Breaking this monolith into different models and later on migrated to micro-frontend.
But it is too late now. It’s too late because the code is convoluted. The code has so many dependencies across so many modules that it’s very hard to differentiate between modules so that it can be migrated to micro-frontend.
This brings us to micro-frontend. Like how did micro frontend solve this problem.
Micro-frontend provides isolated way of maintaining the project. It consists of end-to-end pipeline, development cycle inside of a single domain. Let’s say you are building an E-commerce website and you work in Product domain. So product is completely isolated module and will have its own components, its own pages, its own services and also its own routing.
So all of this bundled into a module will be deployed isolated from other modules/domains. Your team will be dedicatedly working on products. They will be responsible for all the features related to the product domain and releasing a new feature to production and all of this development won’t be dependent on any other team or any other domains. This is the power of micro-frontend.
So every module will have its own development pipeline, its own deployment pipeline and testing pipeline. Everything will be isolated.
Coming back to modular monolith. What is it?
Lets say you have to start a project now. It appears that you won’t have a very large feature said you won’t have a victim to manage. So you will most likely start with a mono Repo. This Modular Monolith can benefit from all the features of micro-frontend from the very beginning.
You won’t start coding directly by creating component. What you do is, you will sit back and you will understand the business, you will finalize the domains and their boundaries. And for it to work effectively, you will have to put up discipline in the team that no cross domain dependencies should be created.
You will not cross domain boundaries to access another module. Doing so creates a tight coupling and you don’t want that. So want to have this discipline with your code base, then you can simply as you develop your code in a single model repo and once your product grows inside of you have more people more team members work on the project. Then you can simply take out this module which have been maintained from the start which doesn’t have any dependency outside of its own. You just take it out put it into a separate Repo and everything will work as it is.
The only thing that comes in mind is that the communication between different modules/domains is the event driven communication. I plan to create another podcast on that.
So I’ll just leave it here for you to ponder upon if you have any questions so far.