Micro-Frontend(MicroFE) is superman!!! [Part 1 — Basic understanding & architectures]

A zoo with Microfe animals

Question: What is Microfrontend (Microfe)?

Ans 1: Displaying two webapps in an iframe on a same webpage is called Microfrontend. Both frontend apps are managed by two different teams. — Very specific definition.

Ans 2: Micro frontend architecture is an approach to developing web application as a composition of small frontend apps. Instead of writing a large monolith frontend application, the application is broken down into domain specific micro frontends, which are self-contained and can be developed and deployed independently. — Really good definition.

Ans 3: Micro Frontend is the same concept as Microservices but for the frontend of the web app. The idea here is the same — to make small independent service work together for a large complex application.

Ans 4: I know the answer but my definition is not true always. 😢😢😢!!!. But trust me, we have built a webapp with Microfes and it one is in React another is in Angular. — Emotional definition

So an of the above scenarios, or any other scenario which is not mentioned here, may be a Microfrontend depending on your use case. The main key points to go for Microfrontend are;

1. Independent development & deployment — different teams
2. Different web technologies at one page — React, Angular, Vue, etc.
3. A less dependent sub-domain of the business

Enough theory….

Let’s begin the journey

Micro-Frontends are saviour for the situation where you want to be Tech-Independant, want to be in Tech-Trends but because of the OLD-FART (It is someone who is old fashioned and does not like any change.) technology of the existing application your super cool ideas of breaking the world with the new usage of technologies is being lost in a maze.

But if you could fight and win the battle against the Old-Fart, then this blog is going to be your best friend. And it is going to tell you how your new plants (the new Micro-frontends) are going to be your new way of designing the front-end application.

Be prepared for Microfe

I recommend reading following blogs which will give you enough information about what a Micro-frontend is and how you are going to make it happen. I personally found the single-spa Micro-frontend framework to be the best of fulfilling my Micro-frontend dream.

Microfe wiring architecture

So the first question which may bother you is, What is this wiring architecture? So the wiring is gonna tell you how are you going to make two Microfes or one Microfe and one Old-Fart work together? There are two wiring strategy I have observed while going with Microfes. One is useful when you are planning a new project with Microfes and other is useful when you want to build the young Microfes with the Old-Fart application. Let’s see them in detail.

A. One stitching layer and all Microfes.

Stitching Layer and Microfes

Build Microfes and one stitching layer to connect them and display them on single web-page. The component which binds them together is called stitching layer. This component can have all the common CSS and JS modules, which can be imported in the Microfes as dependency (npm or git) and this way their duplicity can also be avoided. You can also have a medium of communication between the Microfes by developing some kind of event-bus on the stitching layer. We will see what could be the best way of making the communication happen in a while.

B. The existing application as stitching layer and all Microfes.

Existing app as stitching layer and all Microfes

All of us want such help, where we can use Microfes with the existing application. As it will be hard to replace the existing app by the stitching layer and then use the existing app again as Microfe, so we can make the existing app work as the stitching layer and the new sub-app as Microfe (The new baby in the family).

Note: I am going to explain the rest of the article keeping the architecture B as base. My tech-stack is, I have the old-fart app in React 14 and the the new Microfe as React 16. Both are using their own Redux to maintain their app state.

For us, the requirement was to render the new Microfe inside the running component of the other React app. This made it a really bit complex for us. Because as per single-spa, the DOM element on which an app is mounted is stable. By stability I mean, the DOM element should not be deleted and again added. Think of the case, when we want to render the Microfe under the other React app, then in that case, the DOM element would be controlled by the rendering flow of the other React app. I will further explain this problems’s solution in Part 3 of this article series.

There are multiple scenarios where a running Microfe wants to communicate with another running Microfe. Although we try to minimize such scenarios, still there could be such cases where one has no other option than to have a communication bridge. For this purpose, we built a custom JS library which gives couple of ways to communicate with other Microfe at run time.

We will read about such communication in detail in the Part 2 of this article.

Please read the Part 2 for an interesting topic.

Thanks for reading this!!!

Part 2 is here : micro-frontend-microfe-is-superman-part-2-run-time-communication