Micro Front End Architecture — Design Principles and Final Thoughts

My Thoughts on Micro Front End Architecture

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 the 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 for 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-Frontends by Cam Jackson

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.

Business Centric

Each micro front end application address a particular business need of your application. For instance, let’s say that we have an online book store and that we would like:

1. Shopping Cart
2. Single Book Page
3. Multiple Book Page
4. Header
5. Footer

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 to be able to be siloed base on business needs. (Core concept is taken from Martin Fowler article on microservices here.)

Autonomous Features

An autonomous feature (in software) means something that can control itself independently. So an autonomous feature here means a front end that can:

1. Change, test + deploy independently
2. Resilient — If one area of application faults, allows us to degrade just one section of the application.
3. 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 require this one distinct feature, which is that applications are front end framework agnostic. From a micro front end perspective, this means: 1. 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 separately. 2. 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. 3. 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: 3a. The router 3b. Browser Events(Razroo uses eev)

Super Resilient

Being that we are going to be hooking in potentially multiple frameworks, that can have an impact on the initial load time of our site. Being able to have a visible site, without data or Javascript being loaded is key. Using something like Ghost Elements(see this incredible article by Thomas Burleson), is crucial, even more so than a single page application. Integrating universal rendering, or static site generation is also a good idea, just to make sure the ability of its loading is faster, granted the cohesive, performance heavy nature of bundling.

Team Ownership

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 the front end, backend, and the database. Arguably, this is beneficial for two reasons: 1. Simplifies communication. No need to talk to a database, or dev-ops, because each team is a database, DevOps, backend, and frontend. 2. Simplifies co-ordination. No reason to talk to the backend, or database specialist, because once again, each team is the database, DevOps, backend and frontend specialist. 3. Changes happen quicker — Due to accelerated communication. 4. Improved performance — The developer gets to see how optimization they made on the 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: 1. Autonomous(work on their own without coordination of other teams. Own framework etc.) 2. Full-stack (developers can work through the entire lifecycle of application)

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 the 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.