Moving a company to microfront-end environment (kind of)

As a company grows, it’s UI grows as well, and becomes a huge monolith with so many moving parts and entanglements it becomes unbearable, the development experience is horrible and the development team is scared of touching the code base. Development experience is something we look for in our computer environment (IDE/terminal/etc…) but usually not in our code base. Moving to micro-front end architecture is something that will greatly improve our development experience. being in-charge of a smaller domain makes changes easier and development faster. But a large company may not see what you see, sayings like “it works…. why change it” are often thrown around. What do we do ?

Fake it till you make it

When we develop a new part of code we like to mock the data structure to make our lives easier and to get your code running as fast as possible. *This same idea can be also done on the architecture level of your project. *NX is an amazing project that exists mainly to manage your monolith. It has the ability to create multiple Angular/React/Vue projects with ease. why is this important ? We can create our new widgets (domain-driven) as a new applications. which are encapsulated with their own logic and and UI components. Each application exports the required classes/functions/whatever, in order to be consumed by others. Essentially a Micro-frontend with out the remoteEntry part.

Benefits

1. Multiple teams can work on the same monolith in separate domains and will never (almost never) clash (git merge conflicts).
2. allows us to refactor old code and improve our applications behavior widget by widget.
3. This is not an “all or nothing” mentality, this can be done gradually in order to see and test results.
4. Production builds only the applications that have been changed , so build times will go down if only a domain specific application has been changed.
5. The transition to using an actual remoteEntry is simple
6. each application can be run as an independent application and be consumed by other applications.

So why go through the trouble?

Moving parts in large companies move slowly, there are many areas not accounted for, and implications that we may be departmentalized from. But we want to grow as developers and as a team, to keep pushing ourselves forward. Having a huge monolith that no one wants to touch is not something that is going away soon, but we can start breaking our applications into domains and widgets to make development cycle easier and less prone to breaking production on a Friday/Thursday…

Domain Driven Applications

Each Applications has a domain its in charge of, logic/services/interfaces are all included in that domain’s application and is exported outside for others to use.

Example: Our application has 3pages:

1. Lists of all users .
2. Single user view.
3. Settings page.

In this very simple webApp we have 3 domain applications.

1. The shell (the entry point to our application, the main routing, the high level layout is done here)
2. Users — lists and single view
3. Settings

There is no connections between Users and Settings pages, the fact the they are both in the same application is a coincidence. So they can be absolutely independent from one another. they don’t know about each other. one team can work on the User application, and another team can work on Settings application, without conflicts between them. Team 1 can not care about the work that team 2 does (in a perfect world). When team 2 is done and wants to push their work. testing can be done on the domain-driven application level, seeing as just one application has been effected by the changes, we increase our confidence in our updates.

Conclusion

Breaking our monolith into domain focused applications will gives a lot of the benefits that a micro-front end gives us. It’s not the same but I would say its 90% similar. And more importantly, with out going through hoops and DevOps we can create the same easier development experience that we want from MFEs and justify the need for it when the teams are happy to go fix/add/remove stuff from the domain application with out fear about what might be effected (or at least less fear). Code delivery confidence is something that is being talked about a lot over the years. and the smaller your domain is the better confidence you have in them.

Inspiration

I highly suggest reading The Micro-Frontend Chaos (and how to solve it) by Orel Balilti. The article talks about how the Micro-frontend can be not as helpful as the basic demo makes it seems, and how to fix that issue to make production ready projects that can scale.