Microfrontends — when they aren’t the answer (React, Angular, Vue etc)
Taking a look at potential drawbacks of using Microfrontends and when it doesn’t make sense to adopt them.
The concept of Microfrontends introduces a way of dissecting a huge monolith UI into smaller, more manageable chunks.
Think microservices for the frontend.
It’s no silver bullet though — in this brick-themed article I am going to look at when you shouldn’t consider Microfrontends for your project.
I have published lots of articles on Microfrontends as an architectural design pattern and discussed the many advantages over a monolithic UI.
React, Angular, Vue, Ember, Backbone, Stencil, Preact…. in fact there’s probably another one being released right now!
Creating Micro-frontends using Web Components (with support for Angular and React)
If you’re React or Angular, Ember or Vue let’s create a place where they all can live together in perfect harmony using…
I have received lots of interesting feedback on Microfrontends as a design pattern. The feedback has been largely positive as many relate to the problems Microfrontends attempt to resolve.
However, as some have rightly pointed out, there are some instances when it doesn’t make sense to adopt such a architectural design pattern — let’s look at some of those in this article.
Won’t microfrontends increase build complexity?
Complexity isn’t a new problem in UI development.
In order to build a UI project you simply must have a plethora of tools at your disposal to fetch, render, test, update, build, optimise and everything in between.
The introduction of Microfrontends takes that complexity to a whole new level, now you have to manage multiple instances of each, right?
Unfortunately that is true, but there are are ways to mitigate such complexity.
In my opinion, you simply cannot execute on Microfrontends without a strong CI (Continuous Integration) / CD (Continuous Delivery) process in place.
As your application scales into tens or potentially hundreds of little frontends (each with their own build process) you will need to standardise some of the tooling around them or else you will end up in a whole world of pain!
Sticking to a single or couple of UI frameworks (e.g. Angular / React) may be a good start, so all your build processes use similar steps.
Containerisation tools such as Docker / Kubernetes also do a great job of simplifying this complexity.
I’ll pause on this thought and promise to follow this up with an article on what a solid CI/CD process looks like for Microfrontends.
I work on a small app that is unlikely to grow, does it make sense to adopt microfrontends?
In short, the answer here is a definitive no.
I often find that teams that successfully adopt an architectural design pattern (like Microfrontends) are naturally drawn towards it by strongly identifying with the problems it is claiming to resolve.
Let’s look at the qualities of Microfrontends (similar to Microservices):
- Highly maintainable and testable
- Loosely coupled
- Independently deployable
- Organised around business capabilities
In order to successfully adopt Microfrontends, your application should be screaming out to be improved by most, if not all of these.
For example, if you are flying solo developing an application with no other dependencies then you don’t need to worry about being loosely coupled or independently deployable so that isn’t a battle you need to fight, save your energy and enthusiasm for something else!
Won’t components/libraries be duplicated across microfrontends increasing file size and negatively impacting performance?
In a scenario where your application could potentially be composed of several instances of a single framework or multiple frameworks, there could be components and libraries duplicated across your entire application particularly if encapsulation or loose coupling is a factor.
Take Angular for example, it already comes bundled with the RxJS library. If you have 5 Microfrontends based on Angular you could have 5 RxJS instances served up to your users.
How this could be avoided will very much depend on how your application is constructed. In this example it is possible to lazy load some libraries and share them across each of your Microfrontends.
In other cases you may simply have to accept that this is the case, and factor that into making any decision going forward.
How can we enforce design look and feel consistency if all our microfrontends are separate projects?
This is one of the biggest concerns of using Microfrontends. What if the user notices there are multiple projects under the hood by inconsistent UI design and/or user experience (UX)?
Each of these provide a consistent design for what a button, table, title etc should look like and behave.
It may even make sense for you to start with one of these as a baseline and build upon it for your company or application.
Like every decision we make when designing and building software, there are advantages and trade-offs made in context of your application. What makes sense for one, won’t necessarily make sense for another.
If we are in possession of the facts it makes those decisions educated and more likely to succeed when implemented.
Thank you for taking the time to read my article.