An introduction to micro-frontends

Over the last five years SPAs (Single Page Applications) have been making waves in the world of frontend development.

An SPA differs from a website in the way it creates and presents what the user perceives as the ‘website’ they are visiting. SPAs dynamically rewrite the current web page with new data from the web server, whereas a website has to load a new page from scratch, increasing load time.

Under the hood, JavaScript is used to create this dynamic rewrite and with technologies such as AJAX and Server Side Rendering, we can make the loading of new components and data on the page seamless.

However, the proliferation of SPAs is presenting a new set of problems when trying to divide the work between multiple teams.

For example, imagine a typical digital banking journey:

1. The customer logs in
2. They are presented with a dashboard, showing an overview of their products, such as the balance on their current account, savings accounts and credit cards
3. They make a payment from their current account

These steps will typically be built as separate SPAs that are linked seamlessly (as far as the user is concerned)

In the background, the SPAs will use shared code (e.g headers, footers and other UI components, authentication libraries, etc) and use a common set of libraries, for example they could all be built in React or all use a set of open source libraries.

This presents a complicated list of dependencies that spans across teams and need to be managed. Without careful management, this can lead to issues like version conflicts, eventually increasing build and deployment times and creating bottlenecks.

To resolve these problems, there was a need for developers to think of different architectural models - and that’s how micro-frontends came to be.

Micro-frontend architectures are front-end apps funnelled into individual, semi-independent ‘microapps’ that work loosely together. This can in-turn help make large projects more manageable, for example when transitioning from legacy codebases.

In effect, micro-frontend architectures extend the microservices model to the front-end, letting teams build small apps that share screen space and can work together or independently.

This brings a variety of benefits, including:

• Scalable development: Scale in development capacity can be achieved more easily when using micro-frontends by working without inter-dependencies. Two teams can work on the same page without affecting the work of the other. All micro-frontends are either operating as stand-alone apps or talk to each other via defined APIs
• Reduced cost for enterprise applications: Costs are reduced as it’s easier to share code and components, because micro-frontends can be shared across different apps and use cases
• Robust maintenance of applications: It’s typically easier to upgrade applications when upgrading parts of the application as opposed to the whole, this offers greater flexibility and there is no need for a big-bang approach as each micro-frontend can be upgraded independently. For example, switching from Angular to React can be carried out at the micro-app level without needing to upgrade everything at once
• Flexible ways of distributing work: Micro-frontends are typically focused on solving small, well defined tasks. As such the development can be spread across more teams and completed quicker
• Faster error free deployments: Micro-frontends typically offer a faster route to going live, because by keeping the apps small teams can build, test and deploy faster

However, nothing is entirely plain sailing and micro-frontends come with their own set of challenges, including:

• Reusability of components: It’s important to consider which parts are meant to be micro-frontends and which are meant to be reusable components (i.e, buttons, input boxes, footers, etc.). Just like any other app structure, code reuse speeds up development and not everything can be a micro-frontend
• Versioning: Since micro-frontends are independent applications that load on the host page or application, we have to manage different versions of their dependencies that load on the same browser. To solve this we need to have a team that maintains code and architectural standards 
• Payload and resources: Micro-frontends use multiple libraries just like any other web app. A plan needs to be in place to minimise loading of the same resource numerous times for multiple micro-frontends, as this will have an impact on total payload size and loading times for users

As web applications grow ever more complicated, it’s important to always think about the correct architecture that enables us to have fast delivery, zero dependencies between teams and minimum maintenance.

With the right approach, micro-frontends can bring many benefits to the development process and should be one of the tools considered for your next programme of work.