Four Micro-Frontend Architecture Types You Can Implement With Blazor

In this article, we will describe how you can implement micro-frontend architectures using Blazor, an open-source framework for creating web applications using C# and Blazor WebAssembly (Wasm). Much like micro-services architectures do for services, micro-frontend architectures break up web applications into small, functional, and scalable components. Micro-frontend approaches can help you avoid creating spaghetti code, improve code structures, and avoid coupling between components. They can also help teams work on front-end code more efficiently. There are four primary ways you can implement micro-frontend architectures with Blazor, and let’s take a closer look at each.

Method 1: Use micro-apps with a shared session and parameters

For large and complex applications, micro-apps is an excellent approach to micro-frontends. With micro-apps, you have multiple apps with a shared session and parameters, or even styles. Sharing both the session and account or general information across different sites or applications makes the user feel comfortable and safe because they won’t need to start any new sessions or give more information to every app they need to use. 

A good example of this concept is the Google productivity suite, GSuite. Working through a user’s Google account, GSuite makes different apps available to the user (YouTube, GMail, Google Photos, Calendar, Meet, and so on). GSuite provides a consistent user experience across all the apps by using the same styling throughout. To do this with Blazor, every app is a Blazor project and they have shared session information between them (see illustration below).

Example of a micro-app micro-frontend approach, in which every app is a Blazor project and they have shared session information.

Method 2: Use routing

Routing is a simpler way to implement micro-frontend architectures using Blazor. To do this, you create a new project for each URL in the main menu of your application. Every module is accessible by a different route in the URL, and they are each independent projects in the code. 

Example of a micro-frontend approach using routing.

A good example of routing using shared components can be seen within the interface of this site. As you can see, the menu loads a different component depending on what is selected. This repository in GitHub also has an excellent example.

We will explore another method that uses shared components later in the article. 

Method 3: Use Blazor as a component in an existing project

Although this architecture is a little more complex, it’s very useful if you already have a project in JavaScript (such as React.js, Angular, Vue.js, and so on). If you need functionality with high performance or other reasons, you can use Blazor as a complement in an existing project. The main application can also be a Blazor project.

Example of a micro-frontend architecture using Blazor as a component, with blazorComponent and blazorComponent2 as Blazor projects.

In the example below, from Lautaro Carro, you will see a React application consuming a Blazor project that provides a component to compile C# code in the browser.  

Check out the code for this example in this repository: https://github.com/lauchacarro/MicroFrontend-Blazor-React

Method 4: Use shared components or a Razor class library

In Blazor projects, you can add a folder with the name Shared (you can find it within the base project); you can add shared components to this folder that you can reuse across the project in other components or pages. This is a very good and simple way to implement micro-frontend architectures, splitting the UI into small and reusable pieces with only one responsibility. 

You can also create a Razor class library in order to share components across different projects, or create a NuGet package to share them with all the community in https://www.nuget.org/.

Example project type of shared components for Blazor. 

A shared component is a simple piece of code that are a combination of C# and HTML. Share components don’t need to specify a route. Shared components are referenced by the file’s name and will need the decorator [parameter] to specify which properties will be arguments when a module or component uses or calls it. 

Here’s an example of code implementing a shared component:

<div class="my-component">

 

 This component is defined in the <strong>RazorSharedComponents</strong> package.

   This component can be used in different Blazor projects

   This component was call by <strong>@CallModule</strong>

</div>




@code {

   // Demonstrates how a parent component can supply parameters

   [Parameter]

   public string CallModule { get; set; }

}

Example of a micro-frontend project that incorporates two shared components inside its pages or modules.

Check out this repository to see the entire code of this simple demo: https://github.com/Mteheran/BlazorShareComponents

How to get started with micro-frontend architectures with Blazor

We’ve explored four ways you can implement micro-frontend architectures in Blazor. You can use one, or several together, and there are more ways I haven’t discussed in this article. Blazor is relatively new, and I expect to see new ways to implement micro-frontend architectures in Blazor evolve over time. While you can use Blazor in existing JavaScript projects, it’s hard to do right now because Blazor doesn’t have a specific type of project that can be easily exported for use with JavaScript projects. Keep in mind that you can use more than one way to implement micro-frontend. 

That being said, the simplest way to get started or just explore how you might use them is to create shared components and then reuse small pieces of UI code. Shared components are almost mandatory in medium-to-large-sized applications; and, depending on your scenario, you might use shared components with another micro-frontend approach like routing. Whatever the approach that best suits your needs, I encourage you to explore using a micro-frontend approach with Blazor.