DEV Community: Preeti Islur

Real-Time Architecture Patterns for Blazor Server and SignalR at Scale

Preeti Islur — Tue, 28 Jul 2026 12:17:52 +0000

Beyond the basics

Getting a single SignalR Hub broadcasting to a handful of connected clients is the easy part. The real architectural decisions show up once you need real-time features to work reliably across multiple users, multiple servers, and long-running connections that occasionally drop. This is where a lot of Blazor Server / SignalR apps hit a wall that "add a hub method" doesn't solve.

Groups: the first scaling decision

Broadcasting to every connected client is rarely what you want. SignalR Groups let you scope messages to a subset of connections — a specific document's collaborators, a specific tenant's users, a specific dashboard's viewers.

csharp
public class CollaborationHub : Hub
{
public async Task JoinDocument(string documentId)
{
await Groups.AddToGroupAsync(Context.ConnectionId, $"doc-{documentId}");
}

public async Task NotifyDocumentUpdate(string documentId, string change)
{
    await Clients.Group($"doc-{documentId}").SendAsync("DocumentUpdated", change);
}

}

The common mistake here is forgetting to remove connections from groups on disconnect — OnDisconnectedAsync should clean up group membership, or you'll leak stale group entries that accumulate over the app's lifetime.

Scaling across multiple servers: the backplane problem

A single server holding all SignalR connections in memory works fine until you need more than one server instance — at which point, a client connected to Server A has no way to receive a message triggered by an event on Server B, unless you introduce a backplane.

The standard solution is a Redis backplane, which lets all server instances share connection and group state:

csharp
services.AddSignalR()
.AddStackExchangeRedis(redisConnectionString, options =>
{
options.Configuration.ChannelPrefix = "MyApp";
});

This is the point where "it works on my machine" and "it works behind a load balancer" diverge — if you skip the backplane, users on different server instances simply won't see each other's real-time updates, and this failure mode is easy to miss in local development where everything runs on one instance.

Sticky sessions matter for Blazor Server specifically

Blazor Server has an additional constraint beyond typical SignalR apps: because a circuit holds server-side component state, a user's requests must consistently route to the same server instance for the life of that circuit. If a load balancer round-robins a user's reconnection attempt to a different server, that circuit — and all its in-memory state — is gone.

This means your load balancer needs sticky sessions (session affinity) configured specifically for Blazor Server apps, in addition to any backplane you set up for a separate custom Hub. These solve different problems: the backplane lets separate hub connections communicate across servers; sticky sessions keep a single circuit's requests on one server so its state isn't lost mid-session.

Handling reconnection gracefully

Network drops happen — WiFi hiccups, laptop sleep, mobile network handoffs. Blazor Server has built-in reconnection UI, but the default experience is minimal. A more robust pattern tracks connection state explicitly and gives users clear feedback:

csharp
protected override async Task OnInitializedAsync()
{
hubConnection.Reconnecting += (error) =>
{
connectionState = "Reconnecting...";
InvokeAsync(StateHasChanged);
return Task.CompletedTask;
};

hubConnection.Reconnected += (connectionId) =>
{
    connectionState = "Connected";
    InvokeAsync(StateHasChanged);
    return Task.CompletedTask;
};

hubConnection.Closed += async (error) =>
{
    connectionState = "Disconnected";
    await InvokeAsync(StateHasChanged);
    // Optionally attempt manual reconnect with backoff here
};

}

For custom Hub connections (as opposed to the circuit's own reconnection, which Blazor Server handles separately), building in exponential backoff for reconnect attempts avoids hammering the server during a wider outage.

Message ordering and delivery guarantees

SignalR doesn't guarantee message delivery or ordering out of the box — if a connection drops between two SendAsync calls, the client may simply never receive one of them, with no automatic retry. For features where this matters (financial updates, sequential state changes), consider:

Including a sequence number or timestamp in each message so the client can detect gaps
Falling back to a periodic full-state refresh rather than relying purely on incremental real-time messages
Treating SignalR as a "notify and re-fetch" signal rather than the sole source of truth for critical state
Takeaway

The patterns that matter as real-time apps grow are rarely about the Hub method signatures themselves — they're about what happens when you have more than one server, more than a few users, and connections that don't behave perfectly. Groups, a backplane, sticky sessions for Blazor Server circuits specifically, and honest handling of delivery guarantees are the differences between a demo and something that holds up in production.

Fixing Blazor Server Concurrency Issues: SignalR Circuits, StateHasChanged, and Thread Safety

Preeti Islur — Tue, 28 Jul 2026 12:15:33 +0000

Blazor Server doesn't run your app in the browser — it runs on the server and pushes UI updates to the browser over a persistent connection called a "circuit." This circuit is built into Blazor Server itself and exists for every app automatically, whether or not you ever write a line of SignalR code yourself. Every user session gets its own circuit, and every circuit runs on a single logical thread of execution managed by a synchronization context, similar to how WinForms or WPF UI threads work.

This is exactly where most concurrency bugs come from — and it's important to be clear that this is a circuit problem, not a "you added SignalR" problem. Any code that touches component state from a background thread, a timer, or an async callback outside the normal render flow can violate that single-threaded assumption, regardless of whether your app uses a custom SignalR Hub at all. Blazor won't always throw an obvious error either — sometimes it just silently corrupts UI state or throws a vague InvalidOperationException about the current thread.

It's worth separating two things clearly, since they're easy to conflate:

The circuit — Blazor Server's own internal connection that renders your components. Every Blazor Server app has this, automatically, with no code from you.
A custom SignalR Hub — something you explicitly add to your app for app-level real-time features (chat, notifications, live dashboards). This is optional and separate from the circuit.

The InvokeAsync/synchronization-context problem below applies to both — but it's fundamentally a circuit threading issue. A custom Hub callback is just one common trigger for it, not the cause.

The most common failure pattern

// BAD: updating component state from a background task
private void StartBackgroundWork()
{
    Task.Run(async () =>
    {
        await Task.Delay(2000);
        someField = "Updated!";
        StateHasChanged(); // this can throw or silently fail
    });
}

The problem: Task.Run schedules work on a thread pool thread, completely outside the circuit's synchronization context. When that background thread calls StateHasChanged(), it's trying to trigger a UI update from a thread Blazor never expected to touch component state.

The fix: InvokeAsync

// GOOD: marshal back onto the circuit's synchronization context
private void StartBackgroundWork()
{
    Task.Run(async () =>
    {
        await Task.Delay(2000);
        await InvokeAsync(() =>
        {
            someField = "Updated!";
            StateHasChanged();
        });
    });
}

InvokeAsync (inherited from ComponentBase) dispatches the given delegate back onto the correct synchronization context for that circuit — this is the fix for almost every "why does my background update not show up" bug in Blazor Server.

When you also have a custom SignalR Hub

If your app additionally uses its own SignalR Hub (separate from the circuit) — say, to push updates to a component from a hub connection in a real-time dashboard or collaboration feature — the same underlying circuit rule applies. Hub callbacks run on their own thread, not the component's, so they hit the exact same synchronization-context problem as the Task.Run example above. The Hub isn't a special case; it's just another source of "code running outside the circuit's thread."

// BAD: hub callback directly touching component state
hubConnection.On<string>("ReceiveUpdate", (message) =>
{
    latestMessage = message;
    StateHasChanged(); // still the same problem
});

// GOOD: wrap the callback body in InvokeAsync
hubConnection.On<string>("ReceiveUpdate", async (message) =>
{
    await InvokeAsync(() =>
    {
        latestMessage = message;
        StateHasChanged();
    });
});

A subtler bug: concurrent renders on the same circuit

Even with InvokeAsync used correctly, if multiple async operations both try to update the same component in overlapping windows, you can get render exceptions like:

System.InvalidOperationException: The current thread is not associated with the Dispatcher...

System.InvalidOperationException: A task was canceled.

This usually means two different code paths are racing to call StateHasChanged() on the same component near-simultaneously. A practical fix is guarding state mutations with a lock object scoped to the circuit's own logic, not a global static lock (which would serialize unrelated users):

private readonly SemaphoreSlim _updateLock = new(1, 1);

private async Task SafeUpdate(Action updateAction)
{
    await _updateLock.WaitAsync();
    try
    {
        await InvokeAsync(() =>
        {
            updateAction();
            StateHasChanged();
        });
    }
    finally
    {
        _updateLock.Release();
    }
}

Disposal and circuit lifecycle

A related class of bugs shows up when a component is disposed (user navigates away, tab closes) while a background task is still running and later tries to call InvokeAsync on a component that no longer exists.

// GOOD: guard against calls after disposal
private bool _disposed;

protected override void OnInitialized()
{
    _ = PollForUpdatesAsync();
}

private async Task PollForUpdatesAsync()
{
    while (!_disposed)
    {
        await Task.Delay(5000);
        if (_disposed) break;

        await InvokeAsync(() =>
        {
            // safe update here
            StateHasChanged();
        });
    }
}

public void Dispose()
{
    _disposed = true;
}

Without this guard, you'll eventually see ObjectDisposedException or circuit errors in production logs from users who navigated away mid-operation — a very common source of intermittent, hard-to-reproduce bugs.

Quick checklist for diagnosing Blazor Server concurrency bugs

Any StateHasChanged() called from inside Task.Run, a timer callback, or a SignalR hub handler needs InvokeAsync.
Background loops need a disposal flag checked before every state update.
If multiple async paths update the same component, consider a lightweight lock scoped per-component, not global.
Watch server logs for InvalidOperationException mentioning the dispatcher or synchronization context — that's almost always this exact class of bug.

Takeaway

Most Blazor Server concurrency issues trace back to one root cause: code touching component state from outside the circuit's synchronization context. Once you internalize "anything not triggered directly by a Blazor lifecycle method or event handler needs InvokeAsync," most of these bugs become straightforward to both diagnose and prevent.

Building and Connecting an MCP Server to Claude Code: A Practical Walkthrough

Preeti Islur — Tue, 28 Jul 2026 12:05:45 +0000

Why MCP matters right now

The Model Context Protocol (MCP) has quickly become the standard way to give AI coding agents — like Claude Code — structured access to your own tools, APIs, and data sources. Instead of copy-pasting context into a chat window, an MCP server exposes your systems as callable tools the agent can use directly, with proper typed inputs and outputs.

If you're building enterprise SaaS with a lot of internal APIs, this is a genuinely useful integration pattern — not just a novelty.

The core concept

An MCP server is just a lightweight service that speaks a specific JSON-RPC-based protocol. It exposes a set of "tools" (functions with defined input schemas) and optionally "resources" (data the agent can read). Claude Code — or any MCP-compatible client — connects to it, discovers the available tools, and can call them mid-conversation.

The architecture is deliberately simple:

Server: exposes tools/resources over stdio or HTTP
Client (Claude Code, Claude Desktop, etc.): discovers and calls those tools
Transport: stdio for local servers, Streamable HTTP for remote/hosted servers
Local stdio server vs remote HTTP server

For quick personal tooling, a local stdio-based MCP server is the simplest starting point — it runs as a subprocess, communicates over standard input/output, and requires zero networking setup. Great for prototyping.

Once you want a team or multiple clients to share the same server, converting to Streamable HTTP is the natural next step. This lets you host the server on something like Azure Container Apps or AWS App Runner, with proper authentication, instead of every developer running their own local instance.

The conversion mainly involves:

Swapping the stdio transport layer for an HTTP-based one that implements the Streamable HTTP spec
Adding session handling, since HTTP is stateless and the protocol expects some continuity across calls
Putting standard auth (API keys, OAuth) in front of it, since anyone who can reach the endpoint can call your tools
Connecting Claude Code to your server

Once a server is running, pointing Claude Code at it is straightforward — you register the server (local command or remote URL) in Claude Code's configuration, and it becomes available as a tool source in any session. From there, Claude Code can call your custom tools the same way it calls its built-in ones — reading files, running code, or now, hitting whatever internal API or database action you've exposed.

Where this gets genuinely useful

The interesting use cases aren't "let the AI read my database" — they're things like:

Domain-specific coding agents: exposing your own API conventions, schema definitions, or internal libraries as tools so the agent generates code that matches your actual system instead of generic patterns
Agent-to-tool routing: multiple specialized tools (one for database queries, one for deployment, one for internal docs) that the agent picks between based on the task
Multi-agent workflows: chaining several MCP-exposed capabilities together for a task that needs more than one system
Practical lessons

A few things worth knowing before you build one:

Schema discipline matters more than it seems. The agent only knows what your tool's input schema tells it — vague or overly permissive schemas lead to more failed or malformed calls.
Stdio-to-HTTP conversion isn't just a networking change. Session state, error handling, and reconnection logic all need rethinking once you're not running as a simple subprocess anymore.
Start with read-only tools. Exposing anything that mutates state (writes, deletes, sends) needs much more careful guardrails than a tool that just retrieves information.
Takeaway

MCP is still young, but it's rapidly becoming the default way AI agents interact with real systems — moving past "chat with context pasted in" toward "agent with proper tool access." If you're building internal developer tools or SaaS with a lot of API surface area, it's worth experimenting with even a small, single-tool MCP server to see how it changes your own workflow.

Deploying a .NET Core API for Free in 2026: Railway vs Render vs Fly.io vs Cloudflare Tunnel

Preeti Islur — Tue, 28 Jul 2026 12:01:35 +0000

Why this comparison

When I started building Sa, a car comparison platform for the Indian market, I had a working .NET Core Web API with MongoDB running locally — Makes and Models endpoints, Swagger docs, all good. Then came the question every side-project developer eventually hits: where do I deploy this for free?

Azure and AWS have free tiers, but they come with credit card requirements, complex IAM setup, and cold-start behavior that isn't beginner-friendly for a side project you're iterating on daily. So I evaluated four alternatives that are actually built for indie developers.

The options

Railway

Railway offers a straightforward deploy-from-GitHub experience with a genuinely free starter tier. For a .NET Core API + MongoDB setup, it handles builds via Nixpacks or a Dockerfile without much configuration.

Pros: Fast setup, clean UI, good logs, straightforward environment variable management. Cons: Free tier has usage limits (hours/month) that can run out faster than expected if your API stays warm.

Render

Render's free web service tier is popular for small APIs. It supports Docker deployments directly, which works well for a .NET Core app with a custom Dockerfile.

Pros: Reliable, simple YAML-based config, good docs for containerized .NET apps. Cons: Free tier services spin down after inactivity — the first request after idle can take 30-60 seconds, which matters if you're demoing the API live.

Fly.io

Fly.io deploys apps as lightweight VMs close to users, which appealed to me for eventually serving India-based traffic with lower latency.

Pros: Good performance once warm, supports persistent volumes, CLI-first workflow that's scriptable. Cons: Slightly steeper learning curve — you're working with fly.toml and flyctl rather than a pure dashboard experience. Free allowances have also gotten stricter over time, so double-check current limits before committing.

Cloudflare Tunnel

This is a different approach entirely — instead of hosting the API on a cloud platform, Cloudflare Tunnel exposes an API running on your own machine or a home server to the internet securely, without opening ports.

Pros: Free, no cold starts if your machine is always on, full control over the runtime environment. Cons: Only as reliable as your own uptime — not suitable for anything beyond early development/demo purposes.

What I chose and why

For active development with a MongoDB Atlas backend, the tradeoff came down to cold-start tolerance vs. setup complexity. If you're building an API that needs to feel responsive during demos or early user testing, spin-down delays on free tiers are the biggest hidden cost — worth testing with a simple health-check endpoint before committing to a platform.

Takeaway

There's no universally "best" free option — it depends on whether you prioritize zero cold-starts, ease of setup, or long-term scalability path. For a project still in active development, I'd recommend starting with whichever platform gets you deployed fastest, then re-evaluating once you have real usage patterns to optimize against.