The Problem: Why Blazor Developers Need BluQube

BluQube Blog Series:

  1. The Problem: Why Blazor Developers Need BluQube 2. Introducing BluQube: Write Once, Run Everywhere in Blazor
  2. Deep Dive: CQRS Architecture Made Simple with BluQube
  3. Source Generation Magic: How BluQube Automates the Boring Stuff
  4. Building Real Applications: A Todo App Case Study
  5. Validation, Error Handling, and Authorisation in BluQube
  6. Lessons Learnt: What I Discovered Building BluQube

When Microsoft introduced Blazor, it promised to revolutionise web development by allowing C# developers to build interactive web applications without JavaScript. The technology delivered on that promise, but it also introduced new architectural headaches—especially when it comes to choosing between Blazor Server and Blazor WebAssembly (WASM).

The Tale of Two Blazors

Blazor Server runs your application on the server, streaming UI updates over a SignalR connection. It’s fast to load, works on any device, and has full access to server resources. But it requires a constant network connection, and every user session consumes server resources.

Blazor WebAssembly, on the other hand, downloads your entire application to the browser and runs it client-side. It works offline, feels snappy once loaded, and can be deployed to any static hosting service. But it has no direct access to server-side resources and is subject to browser limitations.

As a developer, you’re forced to choose your deployment model early in the project, and that choice affects every line of code you write.

The Write-Twice Reality

Here’s where the problem becomes real. Let’s say you’re building a simple todo application. In traditional Blazor development, your code might look like this:

Blazor Server approach:

// Direct database access in your component
@inject IDbContext DbContext

private async Task AddTodo(string title)
{
    var todo = new Todo { Title = title };
    DbContext.Todos.Add(todo);
    await DbContext.SaveChangesAsync();
    await LoadTodos(); // Refresh the list
}

Blazor WASM approach:

// HTTP API calls in your component
@inject HttpClient Http

private async Task AddTodo(string title)
{
    var command = new { Title = title };
    var response = await Http.PostAsJsonAsync("/api/todos", command);
    if (response.IsSuccessStatusCode)
    {
        await LoadTodos(); // Refresh the list
    }
}

Notice the problem? These are completely different approaches. Your components, your data access patterns, your error handling – everything is different. If you want to support both deployment models, you end up duplicating a lot of code, or building awkward abstractions that are hard to maintain.

The Integration Nightmare

But wait, it gets worse. Modern applications aren’t just about data access. They need:

  • Validation: Different validation strategies for client vs server
  • Error Handling: Server errors vs HTTP errors vs client-side exceptions
  • Authorisation: Server-side claims vs JWT tokens vs API keys
  • Logging: Server logs vs browser console vs remote telemetry
  • State Management: Server state vs client state synchronisation

Each of these concerns multiplies your complexity when supporting both Blazor models.

Real-World Impact

I’ve seen teams solve this in different ways:

  1. Pick one and stick with it – Limiting your deployment options
  2. Build separate applications – Double the development and maintenance cost
  3. Create abstraction layers – Complex, custom solutions that are hard to maintain
  4. Use existing frameworks – Heavy, opinionated solutions that don’t fit Blazor’s paradigms

None of these solutions felt right to me. There had to be a better way.

What Developers Really Want

After talking to other Blazor developers, the requirements became clear:

  • Write business logic once, deploy anywhere
  • Simple, intuitive patterns that feel native to C#
  • Built-in validation and error handling
  • Minimal boilerplate code
  • Easy to test and maintain
  • Performance optimisations out of the box

This is exactly the problem BluQube was designed to solve.

The Vision

Imagine writing your application logic like this:

// Define your intent
public record AddTodoCommand(string Title) : ICommand;

// Handle it once
public class AddTodoHandler : ICommandHandler<AddTodoCommand>
{
    public async Task<CommandResult> Handle(AddTodoCommand request)
    {
        // Your business logic here – same everywhere
        var todo = new Todo { Title = request.Title };
        await _repository.AddAsync(todo);
        return CommandResult.Success();
    }
}

// Use it everywhere
await _commander.Send(new AddTodoCommand("Learn BluQube"));

The same code. The same patterns. Whether you’re running on the server or in the browser.

Coming Up Next

In the next article, I’ll introduce BluQube and show you how it makes this vision a reality. We’ll explore the core concepts that enable true “write once, run anywhere” development in Blazor, and you’ll see how BluQube lets you focus on your business logic—not your deployment model.

BluQube isn’t just another framework – it’s a new way of thinking about Blazor development that puts your business logic first and deployment concerns second.

Want to see the code right now? Check out the BluQube repository on GitHub to explore the framework and see working examples.

Ready to see how it works? Let’s dive into BluQube in the next article.