Micro Frontends: blessing or curse?

Are micro frontends the answer to your most pressing frontend architecture issues? Yes and no, but see for yourself.

Sascha Gros
Sascha Gros November 10th, 2021 · 6 minutes to read
Photo by Valery Fedotov on Unsplash

Micro Frontends: blessing or curse?

Everyone in web technology is aware of the term micro services. In its most basic form it means that you encapsulate a specific part of your business logic within a backend service and make it accessible via an API.

With that encapsulation and its well-defined interface to the outside world, it’s easy to develop the micro service independently from the rest of your backend code. You can use your own technology stack, define your own release cycle and let a team work in total isolation from the rest of your development team.

While this approach has a lot of advantages it also introduces a complexity that must be managed by technical architects and cloud engineers especially to keep the API definitions systematic and homogeneous in a corporate context.

But this post is supposed to take a deeper look at micro frontends and answer the question, if you should use them in your project. Frontend projects are getting bigger each year, incorporating more and more features that have been previously developed on the backend. The reason for that is that users expect quick response times, instant feedback on the UI and a seamless user flow when interacting with a website. In contrast to the past, where each click led to a page load, nowadays websites must be blazingly fast and live up to increasing expectations from their users.

To be able to deliver such websites, many different frontend frameworks have been developed that allow to build so-called single-page applications (SPAs). The most popular examples are Vue, React and Angular, but there are a lot more and there will be even more in the future. With those amazing frameworks at hand it is relatively easy to build large applications with a lot of logic and that is what has been done extensively in the last years. But then people (especially people who are responsible for budgets) started to realise, that those frameworks get stale and that there is a cooler and better framework around the corner every other year. And guess what: Your developers don’t want to be stuck with old and rusty AngularJS or Backbone.js but want to dive right into the latest Vue or React version. But what happens to all the legacy code that has been written in AngularJS so far? Will everything be refactored? Is there a migration path? Will the team start from scratch? And who will pay for it all?

image

Photo by Charles Deluvio on Unsplash

As you can imagine, it is very difficult, time-consuming and error prone, to migrate a big monolithic frontend application from one framework to another. If you do not have an extensive test suite that covers all your important business cases, you will most likely end up with a lot less features and a lot more unwanted behaviour. And that’s where micro frontends come into play.

Instead of having one big monolithic frontend application, you split up your frontend code into multiple smaller sub-applications (the so-called micro frontends), that will then be composed into one larger application at run-time. This sounds awesome, doesn’t it? Just think about all the benefits.

Technology independence

Each team can decide their own favorite tech stack without having to align with everyone else in the company. This allows your teams to move fast and use the tools they are most efficient with.

Code separation

Less interdependencies between teams means less communication overhead and faster implementation decisions. Developers can spend more time on producing code than on attending meetings.

Faster onboarding

By keeping micro frontends focused and the development process decoupled from the rest of your company, onboarding will be easier than ever before. It will also make hiring external experts easier since they can be productive in almost no time.

Isolated testing

A Unit test tries to test a piece of code in isolation. Integration tests then make sure, that the individual units also play well together in a larger context. With clear boundaries between the different micro frontends this context is condensed into a domain specific set of functionalities, making your tests more focused and easier to set up.

Faster delivery

Your teams are working in (technical) isolation from each other, so each team can also define their individual release cycles and integration scenarios. Code can be shipped without being forced into tedious and oftentimes bureaucratic alignment meetings.

Wow. That sounds like the solution to all my problems. My personal Utopia. A place of peace and freedom. But is it?

Let me ask some simple questions, that might force you to think a bit longer before making a decision for or against micro frontends.

Problem 1: State handling

How will you handle shared state? Different technologies imply different state handling mechanisms. Are you implementing your own global state handling mechanism? Are you loading data into your micro frontends independently putting a high load on your servers? Or are you trying to load the data only once and then share it between the different micro frontends? How do you know then, if data must be refreshed when it has been loaded by another frontend application? And how do you avoid data inconsistencies between two applications accessing the same state?

Problem 2: Dependency management

Another problem arises with dependencies. How do you handle dependencies that are required by more than one of your micro frontends. Think lodash. Are you okay with increasing the bundle size of your micro frontend code by including those redundant dependencies into each bundle? Or do you want to externalise those dependencies and load them globally to the Window object? Then what happens, if you need two different versions of a dependency?

Problem 3: Code delivery and deployments

The beauty of micro services is, that you can deploy your new version individually while resting assured that everything will run as before as long as you keep the API backwards compatible. So the new API will be used the instance it is deployed. How does that work for micro frontends? They are likely referenced in the header or body of an HTML document. When you deploy a new micro frontend, it will most likely get a new version. Do you then also update that version in your HTML document’s reference? Or are you daring enough to point it to /latest/script.js and to just replace the old file with the new one? And how do you know, if the data structure of the different micro frontend are compatible with each other in different versions? Oh and are you sure your backend API is compatible with the latest version 1.5.5 of micro frontend A while also being compatible with micro frontend B version 1.3.1?

OMG, what should I do now?

image

Photo by Charles Deluvio on Unsplash

I cannot tell you that without knowing your current tech stack, your vision for the future and the capabilities of your developers. But I can tell you, that you must do your due diligence and think about all the implications beforehand. I have seen companies jumping aboard the micro frontend train and with that creating so much complexity and technical management overhead, that it would have been better for them to stay with what they had.

Whatever you do, make sure that your lead developers are with you in that journey. If they don’t see themselves capable of delivering a solution based on a micro frontend approach, I would better listen to them. They might have good reasons for their opinions.