Splitting a Monolith Reporting Web App with Blazor

Modern web development has increasingly embraced microservices architecture, where applications are composed of independently deployable services that communicate over APIs. This model offers improved scalability, flexibility, and maintainability, which is especially valuable in complex domains like reporting.

In this article, we’ll demonstrate how to apply a microservices architecture to a Blazor-based reporting application using ActiveReports.NET. By separating the reporting engine from the client-facing interface, you can transform a monolithic reporting solution into modular services that are easier to manage, extend, and deploy.

Table of Contents

• From Monolith to Microservices

• Blazor Hosting Models Overview

• Why a Microservices Approach Works for Blazor Reporting

• Build the Reporting Service Application

• Build the Client-Facing Blazor App

From Monolith to Microservices

Traditionally, reporting applications have followed a monolithic architecture, where all core functions are bundled into a single deployment. A typical ASP.NET Core reporting app using the ActiveReports JS Viewer might include:

• A client interface (HTML with embedded JS Viewer)

• Report template storage and management (.rdlx files)

• Server-side endpoints for rendering and exporting reports

This centralized model works well across popular front-end frameworks like React, Angular, and Vue—all of which integrate seamlessly with the JS Viewer. However, Microsoft’s Blazor framework introduces a new paradigm: building interactive web UIs in C# rather than JavaScript.

Want to Try It Out? Download ActiveReports.NET Today!

Blazor Hosting Models Overview

Blazor offers two primary hosting models:

• Blazor Server – Executes UI interactions on the server via SignalR in an ASP.NET Core app

• Blazor WebAssembly – Runs entirely in the browser with minimal server interaction, ideal for static hosting and CDN deployment

Each model has distinct trade-offs and use cases, which are explored further in Microsoft’s documentation.

Why a Microservices Approach Works for Blazor Reporting

Although monolithic patterns are still viable, particularly with Blazor Server, Blazor WebAssembly introduces limitations for reporting. Because it runs entirely in the browser, it lacks server-side capabilities for rendering and exporting reports.

To overcome this, we recommend a Blazor microservices approach. Here, the reporting logic is offloaded to a dedicated backend service, allowing the client application to remain lightweight while still accessing full reporting capabilities.

This architecture works well with both Blazor hosting models and provides several advantages:

• Independent Deployment – Reporting services can evolve separately from the UI

• Cross-App Reuse – A centralized service can support multiple apps and include features like report design and template management

Blazor Web Assembly

Blazor Server

Now that you have a good understanding of the concept, let’s walk through building this Blazor microservices architecture with an ASP.NET Core report service and a Blazor Web Assembly frontend with the ActiveReports.NET Blazor Report Viewer.

Build the Reporting Service Application

1. Create the Visual Studio Solution/Project

   • In Visual Studio, create a new project using the ASP.NET Core Web API project template

   • Name it BlazorReporting, choose .NET 9.0, and uncheck Configure for HTTPS

2. Add the ActiveReports.NET ASP.NET Core Viewer NuGet Package

   • Right-click Packages under BlazorReporting, and select Manage NuGet Packages

   • Under Browse, search for MESCIUS.ActiveReports.Aspnetcore.Viewer and install it to the project

3. Create a Report Storage Directory

   • Create a Reports folder under the root of the project

   • Add a report definition file (ex: Medical Reports - BloodTestReport.rdlx from GitHub).

     • Set its Build Action to Embedded Resource

4. Set up the Report Service

   • Open the Program.cs file

   • Add at the beginning of the file: using GrapeCity.ActiveReports.Aspnetcore.Viewer;

• • Add the following code before var app = builder.Build():

//Add services for CORS policy
builder.Services.AddCors();
//Add services required for the report viewer
builder.Services.AddReportViewer();

• • Add the following code after var app = builder.Build():

//Configure CORS policy
app.UseCors(cors => cors.SetIsOriginAllowed(origin => new Uri(origin).Host == "localhost")
	.AllowAnyMethod()
	.AllowAnyHeader()
	.AllowCredentials()
	.WithExposedHeaders("Content-Disposition"));

//Configure report storage for the viewer
app.UseReportViewer(config =>
{
	config.UseEmbeddedTemplates("BlazorReporting.Reports", Assembly.GetExecutingAssembly());
});

4. • Notes:

     • The CORS configuration must come before the UseReportViewer() configuration, or you will run into CORS permissions errors when trying to access the reports from the front end application later.

     • UseEmbeddedTemplates() will store the reports as resources in dlls. You can also use UseFileStore() to store reports in the file system, or UseReportProvider() which allows you to implement custom storage solutions to store reports in any location such as a database.

5. Note your Report Service’s URL for later:

   • Under the Properties folder, open launchSettings.json

   • Make note of the value of applicationUrl

     • In this case, this is http://localhost:5070

That’s all for the Report Service application, so now we can move on to building the frontend Blazor half to tie into it!

Build the Client-Facing Blazor App

In our example, we will be using WebAssembly, but you can follow the same steps for a Blazor Server app if you prefer.

1. Create the front-end Blazor project

   • In Visual Studio, right-click on your BlazorReporting solution, and choose Add, then New Project

   • Choose the Blazor WebAssembly Standalone App template

   • Name it BlazorReportingApp, choose .NET 9.0, and uncheck Configure for HTTPS

2. Add the ActiveReports.NET Blazor Viewer NuGet Package

   • Right-click Packages under BlazorReportingApp, and select Manage NuGet Packages

   • Under Browse, search for MESCIUS.ActiveReports.Blazor.Viewer and install it to the project

3. Add the Blazor viewer to the home page:

   • In the Pages directory, open the Home.razor file

   • Replace the code with the following:

@page "/"
@using GrapeCity.ActiveReports.Blazor.Viewer

<PageTitle>Index</PageTitle>

<div style="width:100%; height: 100vh">
    <ReportViewer ReportName="Medical Reports - BloodTestReport.rdlx" ReportService="@_reportService"></ReportViewer>
</div>

@code{
    private ReportServiceSettings _reportService = new ReportServiceSettings()
    {
        Url = "http://localhost:5070/", // URL of the report service
    };
}

Replace localhost:5070 with the URL that the Reporting Service Application you made earlier listens to, and replace “Medical Reports - BloodTestReport.rdlx” with the file name of the report template that you have added in the Reporting Service application.

4. Configure startup projects:

   • Right-click the BlazorReporting solution, and choose Configure Startup Projects…

   • Select Multiple startup projects

   • Set the Action and Debug Target for both BlazorReporting and BlazorReportingApp to Start and http

5. Run the application

That’s it! You should now have a functional ASP.NET Web API Report Service, serving reports to a Blazor Web Assembly Report Viewer front end.

You can download the Project Sources here.

By decoupling the reporting logic from the Blazor front end, you unlock the full potential of a microservices architecture—scalable deployments, easier maintenance, and shared reporting services across multiple applications. This approach is particularly effective with Blazor WebAssembly, enabling you to serve lightweight client apps via CDN while securely handling report generation through a centralized backend API.

Have questions or feedback? Feel free to drop a comment below—we’d love to hear from you.

Thanks for reading, and happy coding!

Want to Try It Out? Download ActiveReports.NET Today!