I recently embarked on a mission to uncover the details behind the implementation of MicroFrontends under Blazor WebAssembly applications. This post represents a summary of my findings along with a sample application that should serve as a good starting point as you start your own journey of introducing MicroFrontends to your Blazor WebAssembly project.

An excellent place to start understanding MicroFrontends is the following session from .Net Conf 2020 by Florian Rappl. In the session Florian goes through the different options available to introduce MicroFrontends to a Blazor WebAssembly application. I won’t go again over the problem statement of Monolithic Frontends or the possible solutions that Florian discussed as you can refer to his session. Instead in this post I will focus on the details of implementing MicroFrontends in Blazor WebAssembly utilizing the Modular distributed web application model which is demonstrated in the figure below.

Source: Source: Florian Rappl — DotNet Conf 2020

As always the source code for the application can be found on my GitHub repo here.

In order to implement the above architecture I will utilize a new feature that was introduced to Blazor WebAssembly starting with .Net 5 called lazy loading. Lazy loading allows Blazor WebAssembly application startup performance to be improved by deferring the loading of some application assemblies until they are required. For example, assemblies that are only used to render a single component can be set up to load only if the user navigates to that component. After loading, the assemblies are cached client-side and are available for all future navigations

Here is the structure of the solution hosted on Github repo:

MicroFrontend Solution

Note: The different projects that host the different business modules were created as a Razor Class Library (RCL) as it allows us to host the different components which get imported into the main shell.

How To Enable Lazy Loading?

Blazor’s lazy loading feature allows you to mark app assemblies for lazy loading, which loads the assemblies during runtime when the user navigates to a particular route. The feature consists of changes to the project file and changes to the application’s router.

Start by marking assemblies for lazy loading in the app’s project file (.csproj) using the BlazorWebAssemblyLazyLoad item. Use the assembly name with the .dll extension. The Blazor framework prevents the assemblies specified by this item group from loading at app launch. The following example marks a large custom assembly (WaelsMagicFeature.dll) for lazy loading. If an assembly that’s marked for lazy loading has dependencies, they must also be marked for lazy loading in the project file.

Mark WaelsMagicFeature.dll for Lazy Loading

Blazor’s Router component designates which assemblies Blazor searches for routable components. The Router component is also responsible for rendering the component for the route where the user navigates. The Router component supports an OnNavigateAsync feature that can be used in conjunction with lazy loading. In the app’s Router component (App.razor) add an OnNavigateAsync callback. The OnNavigateAsync handler is invoked when the user visits a route for the first time by navigating to it directly from their browser. If lazy-loaded assemblies contain routable components, add a List<Assembly>. The assemblies are passed back to the AdditionalAssemblies collection in case the assemblies contain routable components. The framework searches the assemblies for routes and updates the route collection if any new routes are found.

OnNavigateAsync has a NavigationContext parameter that provides information about the current asynchronous navigation event, including the target path (Path) and the cancellation token (CancellationToken). The Path property is the user’s destination path relative to the app’s base path, such as /WaelsMagicComponent. The CancellationToken can be used to observe the cancellation of the asynchronous task. OnNavigateAsync automatically cancels the currently running navigation task when the user navigates to a different page. Inside OnNavigateAsync, implement logic to determine the assemblies to load. Options include a conditional checks inside the OnNavigateAsync method and a lookup table that maps routes to assembly names, either injected into the component or implemented within the code block.

Finally, LazyAssemblyLoader is a framework-provided singleton service for loading assemblies. Inject LazyAssemblyLoader into the Router component. The LazyAssemblyLoader provides the LoadAssembliesAsync method that uses JS interop to fetch assemblies via a network call and loads assemblies into the runtime executing on WebAssembly in the browser. Here is the completed solution:

App.razor File

As shown above, the different modules can be built/maintained independently and then get referenced by the main shell which loads them on demand. The figure below shows how the WaelsMagicComponent gets loaded on demand upon navigating to the Waels Magic Tab. This will lead to faster startup time as the application avoids downloading all the dlls on startup.

Lazy Loading Waels Magic Feature

In this post we were able to demonstrate how to maintain different components as separate libraries which could be imported into the main shell in order to allow modular distributed development. In addition, we utilized lazy loading to load the different modules on demand instead of eagerly loading all the modules at startup.