Micro-front-ends (MFEs) is a UI architecture philosophy. It’s been gaining traction recently, but it brings a lot of unanswered questions as well.
MFEs have emerged alongside micro-service back-end architecture, and as such have a lot of aligned ideas. Here are the key concepts:
- Each MFE should be a completely self-contained code-base.
- MFEs should not operate on the same resources (that includes the DOM, the State, the URL. More on that later.)
- Each MFE needs to be deployed individually, and served from a unique URL.
The self-contained code-base means separate Webpack builds (if Webpack is your bundler of choice). One of the biggest advantages of MFEs is the ability to update parts of your project incrementally. I once lead a project where we refactored ~500,000 lines of code from Backbone to React. That was only possible, because it was in ~50,000 line chunks that could be refactored individually— I should mention that 50,000 lines is too big for a MFE, we were using a kind of hybrid-approach.
Not operating on the same resources is for the same reasons we don’t like global variables. If many things can operate on the same resource reasoning about the code, and debugging, becomes almost impossible. You’d have to know about how every other MFE worked before you could change the one you were working on, which completely negates the value of doing MFEs in the first place.
Genuine footage of two MFEs trying to operate on the same resource.
In the UI we are stuck with a handful of shared resources that we can’t escape, for example the DOM. To get around this you have to define boundaries for the MFEs. For example, when rendering an Input MFE, you tell it a specific element in the DOM that it is allowed to operate on. That’s where it will render itself.
The third point is a consequence of the other two. If the code is self-contained, and the operations it performs are self-contained, then it follows that it’s safe to deploy it independently knowing it will have no effect on the other MFEs on the page.
#technology #software-engineering #software-development #programming #javascript