Micro front ends on the Microsoft web platform

Breaking up monolithic code into clusters of services and microservices has been a good thing. It has allowed us to refactor our code and find the bottlenecks and blockers. In some cases, that’s led us back to new, streamlined monoliths, in other cases to building distributed cloud-native platforms.

But there’s one area that’s generally resisted that change: our application front ends, especially those built using web technologies. We’ve gone from forms and tables to JavaScript-powered single-page applications. But despite those changes, the web is still stubbornly monolithic, slowing down development and making it hard to quickly build necessary changes.

Introducing micro front ends

So, why not bring the microservices model to the front end? A web page is simply a container for various page elements that can be treated as components. We can break up a page into sets of functional components that can be managed by different development teams, using themes to customize them. This lets us build common reusable elements, which can be supported outside of web content and reused across different pages, linking to APIs as necessary.

This idea isn’t particularly new, it was first discussed in 2016 in ThoughtWorks’ Technology Radar report, where it was given the name “micro frontends.” As the model of web development has transitioned from dynamic single-page applications to more CDN-friendly static websites, the idea has become more popular.

One other benefit of the micro front ends approach is that it allows you to develop expertise in specific domains rather than in specific applications. For example, building your search functions in a single component means a team can be given specific targets for your various front ends and tune and customize its components. The same would be true for shopping carts, navigation, or any other services you need.

It’s even possible to break things down further. You can have a team that builds and maintains your grid controls or delivers the elements needed to navigate and display catalog contents. Using a common library of design and page elements simplifies delivering and managing front ends, so you can pick and choose components as needed.

Micro front ends and Microsoft

A lot of work has gone into the philosophy and techniques necessary to deliver micro front ends and how you can build architectures that construct an application out of components, using familiar tools. Microsoft has been using the micro front ends approach internally in Azure, but it has also been investing in ways to use it in familiar development tools and frameworks, such as ASP.NET Core and Blazor.

Unfortunately, the current approach does make things a little disjointed; there’s no one way to deliver micro front ends with Azure, so you’ll have to build the necessary architecture yourself. Key technologies to explore include publishing static content to Azure Static Web Apps, as well as the View Components and WebAssembly tools in ASP.NET Core.

Microsoft’s web application frameworks are particularly well suited to micro front ends, as they build on the component model used in XAML desktop applications and the lessons learned in delivering cloud-native applications at scale in Azure. Other tools, such as Azure Static Web Apps, make it possible to build front ends that are suitable for CDNs.

Using View Components to host micro front ends

One approach that can help you transition to micro front ends is ASP.NET Core’s View Components. All you need to do is pass data to a View Component; there’s no model binding. View Components offer all the features necessary to encapsulate functionality in a single block of code, including their own business logic. They work asynchronously and take parameters that are passed through a host page’s logic. In practice, you treat the host as a controller and a view component as a view.

Outside of ASP.NET Core, Microsoft has developed its own React library to deliver micro front ends. Written in TypeScript and available from GitHub, the project provides tools to build both host applications and micro front end components. Data is shared between host and components as context. There’s not much documentation, but you can use the sample code to see how you can implement the library in your applications.

One key point about micro front ends is that they are technology agnostic. The DOM and the web components specification (specifically Custom Elements) are the glue that holds components together. There’s no need to standardize on one web development framework. Each independent element can be built using its development team’s choice of tools.

From HTML and JavaScript to WebAssembly

You can also progressively migrate functionality from HTML and JavaScript to WebAssembly. Blazor offers a framework to host, link, and manage your WebAssembly components using tools like lazy loading to load them as needed, rather than all at once when a page is opened. ASP.NET Core’s route model can manage asynchronous navigation events, helping link UI components through a host that runs inside your web application.

Components can then be delivered as WebAssembly. They are treated as individual containers, and you can use your choice of development languages. With WinUI 3 controls available for WebAssembly, you can quickly build rich user experiences that run in most browsers.

There are many ways to host and deploy micro front ends in Azure. One interesting possibility is to use the lazy loading techniques in many JavaScript frameworks alongside the Azure CDN platform. You’re not limited to the web. Micro front end components can be delivered in React Native or ReactJS, allowing you to separate controls from a common core that can be delivered to specific platforms. Microsoft uses this approach with its Family Safety app, written in Kotlin for Android and Swift for iOS, calling React Native. The same components can be reused in Windows or on the web as ReactJS.

Here Microsoft has developed what it calls a back end for front-end service, which provides a consistent API for components and delivers common visual elements. A layer like this lets you have one common authentication environment managed by the back end for the front end. At the same time, you can use this layer to deliver application-specific business logic allowing micro front end components to be reusable across different applications.

Using Azure Front Door

Azure’s Content Delivery Network allows you to cache static content outside of the core Azure network, using a set of local and metro-level cache servers to deliver content as needed. You’re probably familiar with using Azure CDN and infinite scrolling page designs to avoid loading all of your content at once. The same techniques (and calls) can be used to download micro front end components.

Now part of Azure Front Door, Azure’s CDN tool is the gateway to Azure Static Web Apps sites, ensuring that all your micro front end components are cached and that the service will manage site content for you. It’s a good idea to keep an eye on the time-to-live settings of your cache content. If this is set too high and you push an update to a key component, users will not see it before the cache expires unless you purge the cache. By making a purge part of every deployment, you can ensure that users will get the new code as soon as it’s published.

Because micro front ends are technology agnostic and built on web standards, you’ve got a wide choice of frameworks to use with Azure Static Web Apps, from Angular and React to Next.js and Blazor. This fits with the philosophy that micro front end dev teams have the freedom to build the components they’re responsible for in their choice of tools, with everything coming together in the host template.

Once you’ve started building a library of common micro front end components, you can treat them as an inner source project, where internal teams focus on the needs of the organization rather than a single project. That may mean not meeting your one specific need or having features you won’t use, but at the same time, you should gain quicker bug fixes, improved performance, and a common developer experience with the rest of your organization, making it easier for developers to shift from project to project as needed.