Microfrontends explained

Microfrontends explained:

What are Microfrontends?

Microfrontends is a software architecture pattern for frontend code. It is influenced by the backend microservices architecture pattern.

To understand microfrontends and why do we need them, we first need to know a bit about microservices.

Microservice architecture – a variant of the service-oriented architecture (SOA) structural style – arranges an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. (Wikipedia)

An example – if we would have a Webshop microservice backend, in which each service is owned by a team, we could have the following microservices:

  • Products
  • Products catalog (management)
  • Reporting
  • Customer
  • Orders

Note: This is a simplified view of a microservices architecture & in a real-world application we could have tens or hundreds of microservices.

In the frontend world, for an application like this – we could have:

Notice a few things:

  • each microfrontend can be built with separate technologies
  • each microfrontend can be owned by a team
  • each microfrontend can depend on only one microservice

Why Microfrontends?

What advantages does this bring? Well, quite a few.

Remember that time you joined a dev team on an old project and the frontend was still built with XSLT & jQuery? A re-write was not even considered and you had to use those old technologies to add new features and fix bugs.

Even if you could convince the stakeholders to do a re-write, and you have a new codebase for 1-3 years. What makes you think in 10 years it won’t be perceived as XSLT & jQuery are today?

Microfrontends promise:

  • smaller, more maintainable codebases
  • each microfrontend can be written with different technologies – this removes as much as possible external dependencies
  • each microfrontend can be handled by a different team – reduce cross-team dependencies
  • we can update/upgrade or delete microfrontends whenever we think it is needed

As a business a commitment needs to be taken – we will constantly be replacing old micro/services/frontends with new ones. So we will continuously evolve our codebases.

Example:
We could delete an old framewok.X.js microfrontend and completely swap it with the new one written in framewok.Y.js. This reduces the risk of an entire app rewrite.

Different approaches

There are different approaches to build microfrontends.

Option 1 – One microfrontend for each microservice 🤖

This option is fine when the microservices architecture is based on features. We can have a feature microservice – for example for checkout, then we also build a checkout microfrontend. The advantage here is that each microfrontend needs to know exactly about one single backend API.

Option 2 – Web components 🌟

Those days, a lot of UI frameworks provide support for web components (Svelte being pretty good in this area).

We can have a legacy UI and constantly swapping old code with new Web components. Each new web component can be a microfrontend written in Svelte, Vue, vanilla JS, or whatever you prefer.

The code for each web component can be hosted on a different server, so individual deployment can be done easily without affecting the rest of the system.

Option 3 – using a Microfrontend tool 🛠️

You can use a tool like single-spa to achieve the wire up of different microfrontends.

This approach fits best for building new microfrontend applications. If you decide to use single-spa make sure you read thoroughly their docs and look at their recommendations.

Note: you can also combine those options to achieve the architecture that you need.

Can I afford microfrontends?

Microfrontends are certainly not for every use case.

Micro/frontends/services tackle the problem of software rewrite and software scalability. Independent deployments are also very important for micro/frontends/services.

It also relies on the fact that the company has a big dev team, so in this case, it’s much easier if not all devs work on a single codebase, stepping on each other’s toes all day. Instead, those devs will be split up in teams, each working on a set of a few or maybe only one micro/frontends/service.

The problems with microfrontends

Obviously, there is nothing without a set of disadvantages, so let’s look into what are the drawbacks of microfrontends:

  • hard to test the entire codebase locally when there are many micro/frontends/service
  • very strict interfaces need to be designed upfront
  • more codebases to maintain, upgrade & address security risks
  • performance cost on the end-user, having to download the applications code for each microfrontend
  • the communication between microfrontends can get very complex
  • the infrastructure & deployment will probably get more complex as well

from Tumblr https://generouspiratequeen.tumblr.com/post/640636069354815488

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s