Intention

More than showing code to build micro frontends, this post focuses on the idea behind micro frontends. It lets you understand the core idea and current solutions around it.

When I started building frontend applications, it was just the Javascript. jQuery was in its early stages. Building a frontend application is just to have a bunch of HTML (to be precise in my case, it was PHP), <script> couple of javascript files, and there you go, a running frontend application!

Fast forward to now, we are in a place where, we can build a complicated frontend application, call it a single page, server-side rendered, etc., HTML lives inside Javascript, and with a couple of npm or yarn commands, you have a running frontend application!

Problem

Sure, we are in a better place. But then, there come new problems. I have personally worked end to end throughout the stack. In the backend, the crazy world of APIs, which drive the core business logic is very simple to start with. By now, there are more than a couple of dozens of frameworks across the technologies, to get you started with quickly building the backend application.

To start, that would be helpful. Once your application starts growing, your team starts getting more headcount, and more features and your backend application grows to a level where it will be a nightmare to manage.

Let’s take an example. You are building an e-commerce application. You start with two member tech team. For a month, both work left and right and bring it to live. Celebration moment! You start getting orders. Awesome!

As the owner of the business, you would plan to expand the business which is directly proportional to the features and the scope of the app itself. It is not enough to just have two people working on it, you hire more, and by no time, you would be 30 member team.

If you have experience in managing people and work, you understand the importance of distributing the work for the team to reach the goal. The same applies here. You need a better way to break the work and distribute it. The best way to do this is to break the tech team into sub-teams where each team works on one part of the business. So you would have an Inventory Team, Orders Team, Fulfillment Team, etc.

Each team owns its backend applications, its way of hosting the code, its standards, its release cycles, and others. Here evolves the solution for monoliths

Microservices

It’s not something new by the way. It’s been quite a time since people started adopting microservices. People started moving against microservices because of their downside. Anyways, let us not focus on it this topic though I believe it’s because of poor execution of microservices.

To be short, every team that we discussed above would have a backend application that will have APIs for other teams to interact with it. It is that team’s wish to what technology they use, where they host the code, dependencies, data stores, etc. Till the time the APIs are in place, the implementation does not matter at a global level.

This makes the teams independent and lets them work on their terms and at their own pace. I will stop about microservices here or else it becomes lengthy. A step back, this idea of independent teams is so beautiful and makes sense in reality. Why should it be just for backend applications? Why not the frontend team also?

Micro frontend

Why should there be a single frontend application, let be React, Vue, Angular or Svelte? Why should the entire code be in the same repository? Why should everywhen use the same framework? Why should the deployment pipeline be blocked when there is a bug only in the fulfillment part of the application?

In other words, it is about making the frontend applications functional. It may not be as easy to implement this as it sounds. Let us check a few of the problems with this setup

Managing a Javascript frontend application is getting hard day by day with so many solutions available, and so many npm packages, and versions. It would not be easy to manage multiple frontend projects for sure. Any solutions where

1. We set up multiple frontend applications where each can be independently built and deployed would be a handy solution.
2. We may want to have some common components which will be shared across the sub-projects

This is called monorepo. One repository of the code with multiple sub-applications where code can be shared and each sub-application can be built separately. This solves the problem of building multiple frontend applications.

Our problems do not solve with just a monorepo setup. We need more. If you see the above picture, imagine we are building the browse product page. We would show

1. The list of products to buy
2. Items in the shopping cart
3. The page itself

If you break it down, there are 2 teams involved in it, Inventory, and Cart teams respectively. Now the problem is, how does the page render the products section which is built by the Inventory team, and the shopping cart section which is built by the Cart team on the page? They are completely different applications serving on different hosts.

How does the container app render the child apps? How do the child apps communicate with the container app? How does the data/state of the app gets exchanged? If you observe the above image, the “Add to cart” button is from the Cart team. How do render multiple types of screens from children’s apps? Lot of questions to answer. Let’s go one by one

Mounting

There is a container app and a child app that is being served from a remote host. The requirement is, to mount the children’s app onto the container app. This should be framework agnostic. Once it is mounted it should work and blend with the container app seamlessly. Both in terms of UI and the control part.

Data sharing and communication

The simplest requirement would be, that the child apps need to know who is the logged-in user. There should be a shared data store in between the container and child apps. It should be reactive too. There should be a communication channel too between the container and child apps.

As I was saying above, from a concept point of view this looks interesting but implementing this is not easy. It is strongly not recommended for small teams. More than solving problems, it creates more problems if it is executed poorly.

I want to discuss only the concept because there can be multiple ways and variations of implementation possible, but the idea is the same. So, if we understand the concept we can work and implement what works for us.

Some of the resources I recommend if you want to see it in action

1. https://micro-frontends.org/
2. https://blog.bitsrc.io/how-to-develop-microfrontends-using-react-step-by-step-guide-47ebb479cacd

If you like this post follow me here and on Twitter — (@pramodk73)[https://twitter.com/pramodk73]. I keep posting about Software Engineering, SaaS, and building in public. Cheers!