Microfrontends: An approach to building Scalable Web Apps

When we talk about building modern Web Apps, Single Page Apps is what comes first to mind.

Single Page Apps have grown in popularity due to their promise of better performance, better User Experience, thereby leading to better conversations.

All of this holds true for small to medium SPAs, however as your app starts to grow, SPAs have a high tendency of becoming slow and sluggish to maintain and deploy. Every small change requires the entire app to be deployed thereby increasing your regression / smoke testing efforts. SPAs also have a high risk of memory leaks if not built correctly.

Come of think of it, Single Page Apps are the monoliths of the frontend world and seem to possess all the drawbacks of a monolith.

Backend teams have long known the drawbacks of working with monoliths and are moving towards a micro services architecture. It is time frontend teams also start exploring applying the principles of a microservice architecture to the frontend world.

Microfrontends brings in the benefits of the microservices architecture to the frontend world.

What are Microfrontends?

The idea behind Micro Frontends is to think about a website or web app as a composition of features which are owned by independent teams. Each team has a distinct area of business or mission it cares about and specialises in. A team is cross functional and develops its features end-to-end, from database to user interface. — micro-frontends.org

Some of the principles of the Microfrontend architecture are:

• The app is broken down into smaller micro apps bound by visual context.
• Each app is independent, it can fetch its own data and has its own encapsulated styling.
• These Micro App don’t share a global state.
• Each team can work on their micro app independently and deploy them independently.

Choosing between a Microfrontend Architecture vs a SPA architecture

A microfrontend architecture might not be the right choice for every project, neither would SPAs be. Deciding when to build a SPA or use a Microfrontend architecture or build out a static server rendered site, would depend on the kind of project you are working on.

Back in May 2013, Aral Balkan wrote an interesting blog post titled Sites vs. Apps defined: the Documents‐to‐Applications Continuum where he tries to differentiate between a website and an webapp. He created a band with a content centric site is on the left and a behavior centric app is on the right.

He goes on to say that every digital property that we see would fall somewhere within the band.

Looking at the band above it becomes quite clear that content heavy marketing sites are best off built out as regular CMS driven sites which are essentially a collection of pages. A SPA on the other hand is most suited for behavior centric apps like say an Online IDE, or a Graphical Editor.

The microfrontends would be most suited for the majority of the central portion of the band with a fair bit of overlap. Trying to implement a microfrontend architecture to projects that fall on either extremes of the band would prover counter productive.

Size and complexity of the project are two other very important factors to keep in mind while deciding on whether or not to use a microfrontend architecture.

Breaking down your App into a Micro Apps

Once you’ve decided to follow the microfrontend approach, the next step is to identify how to go about breaking down the app.

Most modern apps are built on a component model, where every page/screen is a tree of nested components.

When breaking down the App merely converting every component into a micro app would make it way to granular and at the same time treating each page/screen as a micro app may not give you all the benefits of a microfrontend architecture.

The question to at what level do we decide to break down the app into a micro app can be found in Brad Frost’s Atomic Design Pattern

Breaking down the app at the organism level gives us all the benefits of a micro frontend architecture.

The below image illustrates a real world example of how a screen can be composed of micro apps.

Loading up these various micro apps on a page would be as simple as calling them into various container slots within an HTML template.

Organizing your Code base

After you’ve decided on how you are going to breakdown your app, you’ll now need to decide on how are we going to organize our code base. There are two primary approaches.

• Multiple Repos with each Micro App in its individual Repo.
• A Mono Repo with each micro app organized as a project.

Multi- Repo:

This approach works best if you have teams that strictly work on their own micro app.

It is also ideal when you plan to have a polyglot approach to building your micro app, wherein you may want to have each micro app built using a different tech stack or a different version of the framework.

In a multi repo environment each micro app would need to be built individually.

Multi Repo are ideal when you have a very large project and very large teams working on it.

Mono Repos:

Mono Repos work best when you want your teams to have easy access to the entire code base and not just the micro app they are working on.

Mono Repos makes it easier to build out all the micro apps at once. Mono Repos works best if all your micro apps are built using the same tech stack and follow a uniform folder structure and a build and deploy workflow.

Although large organizations like Google and Facebook use mono repos for all their projects, over time, mono-repos can tend to get slower to work especially when working with large teams and the number of commits and files under version control increase.

Microfrontend Architecture:

A microfrontend architecture is all about decoupling the various aspects of an app namely components, templates and routing.

Once the microfrontend framework is in place, the teams can focus on building the micro-apps and deploy them independently to the micro app folder or registry.

The templates or views are merely a collection of HTML markups with empty slots to load in the micro app. These templates can be built by any templating engine or CMS.

The Routing service holds the mapping relation between a route and a template and based on the request coming in, it identifies the template for the given route.

The Assembler plays the crucial role of parsing the template and loading the micro-apps from within the defined slots rendering the page and serving it back to the user.

The Microfrontend Premium

Martin Fowler, talks about the Microservice Premium, where he mentioned that Microservices comes with a bit of overhead and complexity, which he refers to as the microservice premium. Martin goes on the say that benefits of a microservice architecture start showing results only when size complexity boosters kick in.

The same holds true for the microfrontend architecture. The whole process of decoupling the various parts of components, routing, and templates and delegating them to different systems can become an unnecessary overhead for small or medium apps.

The benefits of microfrontends kick in only when your project starts hitting those size and complexity thresholds.

Microfrontends in the Wild

Although a relatively new term and concept, quite a few large and popular sites have already running microfrontends in production. Spotify, Zalando, UpWork and Open Table are a few.

So if you feel your current or next project is looking large and complex then do give microfrontends a try.

Read more about the tech stack choices while getting started on Microfrontends here.