Azure Service Bus in .NET 10 with Real-Time React Updates Using SignalR

Step 6: Wire Up the Minimal API

Replace Program.cs:

using Azure.Messaging.ServiceBus;

var builder = WebApplication.CreateBuilder(args);
var queueName = builder.Configuration["ServiceBus:QueueName"]!;

builder.Services.AddSingleton(_ =>
    new ServiceBusClient(builder.Configuration["ServiceBus:ConnectionString"]));
builder.Services.AddSingleton(services =>
    services.GetRequiredService<ServiceBusClient>().CreateSender(queueName));

builder.Services.AddSingleton<OrderStatusStore>();
builder.Services.AddSingleton<OrderNotifier>();
builder.Services.AddHostedService<OrderProcessor>();

builder.Services.AddSignalR();
builder.Services.AddValidation();
builder.Services.AddCors(options =>
{
    options.AddPolicy("Spa", policy =>
    {
        policy.WithOrigins(builder.Configuration["Spa:Origin"]!)
            .AllowAnyHeader()
            .AllowAnyMethod()
            .AllowCredentials();
    });
});

var app = builder.Build();

app.UseCors("Spa");
app.MapHub<OrderHub>("/hubs/orders");

app.MapPost("/orders", async (
    PlaceOrderRequest request,
    ServiceBusSender sender,
    OrderNotifier notifier,
    CancellationToken ct) =>
{
    if (request.OrderId == Guid.Empty)
    {
        return Results.BadRequest("An order ID is required.");
    }

    await notifier.PublishAsync(request.OrderId, "Queued", "We received your order.");

    var order = new OrderMessage(request.OrderId, request.Product, request.Quantity);
    var message = new ServiceBusMessage(BinaryData.FromObjectAsJson(order))
    {
        MessageId = request.OrderId.ToString(),
        ContentType = "application/json",
        Subject = "OrderPlaced"
    };

    try
    {
        await sender.SendMessageAsync(message, ct);
    }
    catch (ServiceBusException)
    {
        await notifier.PublishAsync(request.OrderId, "Failed", "The order wasn't queued.");
        return Results.Problem(
            "The order could not be queued. Please try again.",
            statusCode: StatusCodes.Status503ServiceUnavailable);
    }

    return Results.Accepted($"/orders/{request.OrderId}", new { request.OrderId });
});

app.MapGet("/orders/{orderId:guid}", (Guid orderId, OrderStatusStore store) =>
    store.Find(orderId) is { } update ? Results.Ok(update) : Results.NotFound());

app.Run();

Two choices here are easy to overlook:

• Queued is published before the send. If we did it after, a fast worker's Processing update could arrive first and appear out of order.
• CORS uses AllowCredentials with a named origin. The SignalR browser client sends credentials by default, and a wildcard origin can't be combined with credentials.

Step 7: Create the React App

npm create vite@latest order-tracker -- --template react
cd order-tracker
npm install
npm install @microsoft/[email protected]

Create .env.local:

VITE_API_URL=http://localhost:5090

Step 8: Connect to the Hub

This hook owns the connection. Pay special attention to onreconnected. A reconnect gives the browser a new SignalR connection, so it must rejoin its groups. Any updates sent while it was offline are gone, so it also asks the API for the latest status.

Create src/useOrderTracker.js:

import { useCallback, useEffect, useRef, useState } from "react";
import {
  HubConnectionBuilder,
  HubConnectionState,
  LogLevel,
} from "@microsoft/signalr";

const apiUrl = import.meta.env.VITE_API_URL;

export function useOrderTracker() {
  const connectionRef = useRef(null);
  const trackedIds = useRef(new Set());
  const [orders, setOrders] = useState({});
  const [connectionStatus, setConnectionStatus] = useState("Connecting");

  useEffect(() => {
    let active = true;

    const showStatus = (status) => {
      if (active) setConnectionStatus(status);
    };

    const addUpdate = (update) => {
      setOrders((current) => {
        const history = current[update.orderId] ?? [];
        const latest = history[history.length - 1];

        if (latest?.at === update.at) return current;

        return { ...current, [update.orderId]: [...history, update] };
      });
    };

    const connection = new HubConnectionBuilder()
      .withUrl(`${apiUrl}/hubs/orders`)
      .withAutomaticReconnect()
      .configureLogging(LogLevel.Warning)
      .build();

    connectionRef.current = connection;

    connection.on("OrderUpdated", addUpdate);
    connection.onreconnecting(() => showStatus("Reconnecting"));
    connection.onclose(() => showStatus("Disconnected"));

    connection.onreconnected(async () => {
      showStatus("Connected");

      for (const orderId of trackedIds.current) {
        await connection.invoke("TrackOrder", orderId);

        const response = await fetch(`${apiUrl}/orders/${orderId}`);
        if (response.ok) addUpdate(await response.json());
      }
    });

    connection
      .start()
      .then(() => showStatus("Connected"))
      .catch(() => showStatus("Disconnected"));

    return () => {
      active = false;
      connection.stop();
    };
  }, []);

  const placeOrder = useCallback(async (product, quantity) => {
    const connection = connectionRef.current;

    if (connection?.state !== HubConnectionState.Connected) {
      throw new Error("Live updates aren't connected yet.");
    }

    const orderId = crypto.randomUUID();

    // Join first, so the first update can't be missed.
    await connection.invoke("TrackOrder", orderId);
    trackedIds.current.add(orderId);

    const response = await fetch(`${apiUrl}/orders`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ orderId, product, quantity }),
    });

    if (!response.ok) {
      throw new Error(`Request failed with status ${response.status}`);
    }
  }, []);

  return { orders, connectionStatus, placeOrder };
}

The active flag handles React's StrictMode, which starts and cleans up effects twice in development. The check on at stops a resynced update from appearing twice.

Step 9: Build the Live Screen

Replace src/App.jsx:

import { useState } from "react";
import { useOrderTracker } from "./useOrderTracker";

export default function App() {
  const { orders, connectionStatus, placeOrder } = useOrderTracker();
  const [product, setProduct] = useState("Laptop");
  const [error, setError] = useState("");

  async function handleSubmit(event) {
    event.preventDefault();
    setError("");

    try {
      await placeOrder(product, 1);
    } catch (err) {
      setError(err.message);
    }
  }

  return (
    <main>
      <h1>Live Order Tracker</h1>
      <p>Live updates: {connectionStatus}</p>

      <form onSubmit={handleSubmit}>
        <input
          aria-label="Product"
          value={product}
          onChange={(event) => setProduct(event.target.value)}
          required
        />
        <button type="submit">Place order</button>
      </form>

      {error && <p role="alert">{error}</p>}

      {Object.entries(orders).map(([orderId, history]) => (
        <section key={orderId}>
          <h2>Order {orderId.slice(0, 8)}</h2>
          <ol>
            {history.map((update) => (
              <li key={update.at}>
                <strong>{update.status}</strong>: {update.detail}
              </li>
            ))}
          </ol>
        </section>
      ))}
    </main>
  );
}

Step 10: Try It

Start the emulator, then run both apps in separate terminals:

# In OrderTracker.Api
dotnet run --urls http://localhost:5090

# In order-tracker
npm run dev -- --port 3000

Open http://localhost:3000 and run through these tests:

Remember the sample store is in memory. Restarting the API clears it, so the restart test works properly only after you move the status to a database.

Inspect the Dead-Letter Queue

A dead-letter queue is only useful if someone looks at it. Each queue has one built in, and you can read it with a SubQueue option. Add this endpoint above app.Run():

app.MapGet("/admin/dead-letters", async (ServiceBusClient client, CancellationToken ct) =>
{
    await using var receiver = client.CreateReceiver(
        queueName,
        new ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter });

    var messages = await receiver.PeekMessagesAsync(20, cancellationToken: ct);

    return Results.Ok(messages.Select(message => new
    {
        message.MessageId,
        message.DeadLetterReason,
        message.DeliveryCount
    }));
});

Peeking reads messages without removing them. Protect this endpoint with authorization before you deploy it.

Common Errors and Fixes

Moving to Production

The biggest change appears when you run more than one server. Imagine the worker runs on server A while the browser is connected to server B. Server A's push never reaches that browser.

Microsoft recommends Azure SignalR Service for SignalR apps hosted on Azure, because it manages client connections and doesn't require sticky sessions. Add the Microsoft.Azure.SignalR package and one line:

builder.Services.AddSignalR().AddAzureSignalR();

Use a passwordless connection to Service Bus too. Add the Azure.Identity package, then assign your app the Azure Service Bus Data Sender and Azure Service Bus Data Receiver roles:

var client = new ServiceBusClient(
    "YOUR_NAMESPACE.servicebus.windows.net",
    new DefaultAzureCredential());

Before you go live, work through this checklist:

• Protect the hub. Require sign-in, and check that the user owns an order before adding them to its group.
• Replace the in-memory store with a database, so status survives restarts and works across servers.
• Make processing idempotent. Service Bus can deliver a message more than once, so use the order ID to skip completed work.
• Add a delay between retries. Abandoning a message retries it right away. For long outages, reschedule it with a delay instead.
• Alert on the dead-letter queue, and have a process for reviewing and replaying messages.
• Reuse clients. Keep ServiceBusClient, senders, and processors as singletons. Microsoft advises against creating them for each message.

Conclusion

This pattern gives users the best of both worlds. Service Bus makes sure the work survives failures, and SignalR makes the waiting visible.

Keep the responsibilities clear: save the status, then push the news. Join the group before sending, rejoin after reconnecting, and always give failed messages somewhere to go. Do that, and a slow background job starts to feel like a live experience.