Microfrontends

#  
Frontend
Dominik Pietrzyca

Frontend developer

25
.
08
.
2023
6 min read
Microfrontends caused a lot of buzz in the IT world a few years ago. Although there has been less talk about it recently, I believe this trend will eventually come back. Why? Well, as time passes, IT systems become increasingly complex. Some technologies become outdated. Moreover, the pressing demands of business often do not allow for the settlement of growing technological debt. Developed solutions become increasingly difficult to maintain over time and adding new team members may not always result in desired improvements. Also deploying the whole solution together might cause some trouble. Suddenly, it turns out that adding a simple functionality takes an enormous amount of time. Precisely in such situations microfrontends come into play with their unique features:

Scalability

In frontend, scalability means something different than in backend. On the server-side, this concept is associated with speed or bandwidth. On client-side, scalability means the ability to add people to the team to speed up work. In the book "The Mythical Man Month," Frederick Brock described in detail why this is possible. Adding new people to your team speeds up work, provided that it can be divided into separate fragments without significant interaction. By design, microfrontends should have minimal interaction between themselves. At the same time, there is less communication overhead between different units. This is consistent with Amazon's "two-pizza rule" - one team should be small enough to be fed with two pizzas. Another assumption of microfrontends is the freedom of technology. Here, you should be cautious - it can either help or harm depending on the team's preferences. In general, it is worth exercising common sense.

Isolated Errors

In one deployment unit, everything will crash if there is an error. In the case of microfrontends, only defective part will crash. Undoubtedly, this is a significant advantage, especially if there have been some serious mishaps in the company's history.

Gradual Refactoring

If you completely rebuild the system, the only thing you can expect is a complete disaster. Business requires security and stability of an already working system. At the same time, it wants to see some measurable progress. Martin Fowler described a pattern of rebuilding an existing legacy system without destroying it precisely on his website - I highly recommend checking it out. However microfrontends are not the only way to achieve this. Separating smaller modules with independent responsibilities within a distributed monolith sometimes may be sufficient.Unfortunately, there is no rose without thorns, and in the case of microfrontends, these thorns are tremendous. The above-mentioned features come at the cost of greater system complexity, larger package size, and significantly more challenging testing. The lack of standards in this field and multitude of implementations are also painful, although Webpack with its Module Federation proposed some solutions. But that's a topic for another post.

Also check