Microfrontends — Connecting JavaScript frameworks together (React, Angular, Vue etc)

Like most things in life, a variety of choices informs a toxic culture of mine is better than yours and you’re wrong and I’m right.

Since technology advancements have got us in this mess, is there any chance it could get us out of it as well?

Enter Microfrontends…

Introduction to Microfrontends

Modern UI development regardless of your framework has became all about component composition: You adapt to a framework’s way of doing things by following their patterns and conventions to create components usually underpinned by some sort of data model usually in the form of a service or state object.

For example: Angular has a strong opinion on how everything should be architected in the frontend. React although it only deals with components has a huge ecosystem backing it driven by a community of React-centric developers.

**Microfrontends **have gathered huge momentum recently as away of allowing multiple teams to work on a single UI using multiple frameworks, but could it really change the landscape of UI development?

In this article, I am going to spend some time looking at the SDLC (software development lifecycle) and the advantages of adopting such an architecture.

Where’s the problem?

The current trend in UI development, is to build a feature-rich and powerful browser application (single page application) using a chosen framework.

Development results in building lots of little components which are then bundled together in some sort of build process using something like webpack or rollup.

Over time the UI layer often developed by separate or multiple teams, grows and gets more difficult to maintain creating a huge monolithic frontend.

Monolithic frontend SDLC

Monolithic frontends deployment architecture

Reversing the microservice anti-pattern:

Microfrontends looks at removing that monolithic build step, and results in completely decoupled services that can be independently built and deployed:

Microfrontend SDLC

Microfrontend deployment architecture

Now our UI architecture has all the qualities of traditional microservices:

Highly maintainable and testable
Loosely coupled
Independently deployable
Organised around business capabilities

How could this bring the big frameworks together?

Since we have decoupled our UI components into many microfrontends, we no longer have to dictate which framework each component uses.

The below illustration shows how we could potentially have different application teams using different technologies to create their independently built and released microfrontend:

SDLC using multiple frameworks

There are **several ways **to solve this using technologies but let me illustrate one example:

**Develop: **Three teams using a different JavaScript framework for each microfrontend
Build: Wrapping their microfrontend components as web components*** ***and building their project as a JavaScript file
Release: A single JavaScript file is released inside a docker container served using Ngnix

Once we have released our microfrontends, we should compose them together in a single UI layer. The communication between the microfrontends should be handled by the composition layer which should have a well defined contract.

Deployment architecture using multiple frameworks

From a user perspective they access a single application, but the developer’s ability to solve a problem is no longer limited by what single framework the application uses.

Thanks for reading ❤

If you liked this post, please do share/like it with all of your programming buddies!

Introduction to Microfrontends

Where’s the problem?

Reversing the microservice anti-pattern:

How could this bring the big frameworks together?

Further reading about JavaScript

medium.com

Microfrontends — Connecting JavaScript frameworks together (React, Angular, Vue etc)