Micro Front End Architecture — Design Principles + Final Thoughts
The Full Gamut Edition
I personally feel that micro (service) architecture has officially made it’s way over to front end architecture. This means that it is now important for a UI Engineer, to be aware of what constitutes micro architecture. Martin Fowler, one of my favorites, has an excellent article on what the characteristics of micro-service architecture are.
[Background on how this article was created, is that I’m starting to break more into backend architecture. When I started to do a deep dive on micro-services, I started to look for something similar within front end. That is sort what perked my interest, and why I am now writing about it.]
I would like to go through the points mentioned in this article and others I’ve found as well. There is so much on this topic, and it really is all over the place. I just wanted to write an article to help people on this topic, and help them move on to other areas as quickly as possible.
Single Responsibility Principle
Robert C. Martin, otherwise known as “Uncle Bob”, is best known creating the Agile Manifesto. In addition, he is well known for creating/promoting the SOLID principles. One of the SOLID principles, in fact the first letter stands for the single responsibility principle. The single responsibility principle states:
Gather together those things that change for the same reason, and separate those things that change for different reasons.
Micro front end architecture is a natural extension of this concept. It takes front ends which serve different purposes, and makes it so that they are developed, deployed, and maintained independently. However, these services can still communicate with each other, thereby gathering those things that change for the same reason.
Micro Frontend Architecture Design Principles
An architectural style where independently deliverable frontend applications are composed into a greater whole.
Micro Frontend technology is still being developed, and I think there is still a lot of confusion around the benefits of such. I would imagine there is going to be a happy medium moving forward. However, right now I would like to present design principles as I view them, with the best tech currently available.
Each micro front end application address a particular business need of you application. For instance, let’s say that we have an online book store, and that we would like:
- Shopping Cart
- Single Book Page
- Multiple Book Page
Each one of these elements, serves an all around different business purpose within our application. The shopping cart, to give people an option to see everything they’ve bought so far. The multiple book page, to give the user the ability to see all books we are going to sell. The single book page, to get in depth detail of the book they want to buy. The header, to allow people to properly navigate through our site. The footer to give people an abstract of our information.
So, based on the fact that each one of these elements contains a different business use, we would build them into their own application(,or once again it’s own library, as we will do). This allows teams be able to be siloed base on business need. (Core concept taken from Martin Fowler article on micro services here.)
An autonomous feature (in software) means something that can control itself independently. So an autonomous feature here means a front end that can:
- Change, test + deploy independently
- Resilient — If one area of application faults, allows us to degrade just one section of the application.
- Observable — Centralised logging, and monitoring, so we can see what our individual micro front ends are doing.
without breaking other front ends. The immediate obvious-benefit to this, is allowing teams to work independently of each other. This is highly beneficial for extremely large teams.
Front End Framework Agnostic
In practice, autonomous features requires this one distinct feature, which is that applications are front end framework agnostic. From a micro front end perspective, this means:
- Code isolation — All micro frontends are built as a separate library. We use single-spa to accomplish mounting separate front end frameworks. In addition, using Nrwl Nx to keep libs separate, and builds separate.
- Base app — All of our micro frontends are going to need a base app to hook all of our frontends into each other. However, ideally being able to use the browser directly instead of a base app, is ideal.
- Front End API — Within the context of an enterprise Angular front end application. This means allowing our micro front ends to communicate with each other through:
a) The router
b) Browser Events(Razroo us eev)
This part can be a bit controversial, and I can definitely see some companies having opposition to this, being that the ecosystem isn’t yet fully ready for something like this. However, the idea is, is that now we have a micro frontend, we can actually tie an entire ”slice” of our product, end to end, by one team. This means that a single member, will be expected to contribute to front end, backend and the database. Arguably, this is beneficial for two reasons:
- Simplifies communication. No need to talk to database, or dev-ops, because each team is database, devops, backend, and frontend. .
- Simplifies co-ordination. No reason to talk to backend, or database specialist, because once again, each team is the database, devops, backend and frontend specialist.
- Changes happen quicker — Due to expeditious communication.
- Improved performance — The developer get’s to see how optimization they made on database, or back end, affects the performance on the front end.
Final Thoughts on Micro Frontends
The most humorous and simultaneously enlightening piece I found while putting it all together, is a Tweet by Dan Abramov. It’s a very brave tweet, something along the lines of, ”I don’t understand micro-frontends”. Two of my favorite open sourcers on micro-frontends, Joel Denning + Michael Geers, respond that the greatest benefits are:
- Autonomous(work on their own without co-ordination of other teams)
- Full stack
The above two are the single greatest reasons given by both of them, and are synonymous with the reasons for micro-services. However, as I started to think about it more, the landscape with front end isn’t quite the same as it is to backend micro-services. This is simply because of tooling(e.g. Nrwl Nx)and libraries(e.g. @ngrx/store). It just isn’t there on the same level of ease, as is for a framework such as Angular. In addition, the amount of time required by teams to learn the full stack is really difficult to do, on top of lack of tooling.
I can see how it can make sense for very, very large teams, but that would be far and few between. However, while you are a large company, and have the capacity to do so, why not have them all be on a singular framework, and bundle their apps separately? In this scenario, the amount of expertise for backend API’s, or databases might be so sophisticated, that this can be more of trouble than it helps. So once again, I think it just doesn’t make sense at this time, because the tooling isn’t there for micro-frontends. However, as an architect there would be situations where I can see it possibly being beneficial due to migration from legacy systems, or the dynamics of your team.
I hope you enjoyed this article. You might not believe me, but this one was really written from the bottom of my heart, to make your life easier. If you would be kind share the love (re-tweet, clap etc.), that would mean the world. All the best — Charlie