What this prompt does
This prompt builds real-time features for an [application_type] using SignalR in [dotnet_version]. It designs a [hub_name] hub with methods for [hub_methods] behind a strongly-typed hub interface, implements group management for [group_scenario], secures the hub with [auth_method] restricted to [authorized_roles], builds a [client_type] client with reconnection and exponential backoff, scales across [instance_count] instances via a [backplane] backplane, and adds streaming for [streaming_scenario] using IAsyncEnumerable.
The structure works because live updates without polling only stay reliable if reconnection, auth, and scaling are handled deliberately. The strongly-typed hub interface keeps client and server in sync at compile time, the Redis backplane fans messages across instances behind a load balancer, and the streaming step avoids loading large datasets into memory. Hub filters for logging, exception handling, and rate limiting round out the design so a misbehaving client can't take the hub down.
When to use it
- A client needs live updates — collaborative editing, dashboards, or notifications — without polling
- You are designing a
[hub_name]hub and want strongly-typed methods for[hub_methods] - You need dynamic group management so messages target the right
[group_scenario] - You must secure the hub with
[auth_method]and restrict access to[authorized_roles] - You are scaling SignalR across
[instance_count]instances and need a[backplane]backplane - You want streaming for
[streaming_scenario]instead of buffering large datasets in memory
Example output
Expect a design with code: a hub class with a strongly-typed client interface, group join/leave logic, authentication configuration accessing user claims and restricting roles, a client implementation handling connection lifecycle and reconnection with exponential backoff, backplane configuration for horizontal scaling, an IAsyncEnumerable streaming method, hub filters for logging, exception handling, and rate limiting, plus integration tests using HubConnection in-process.
Pro tips
- Define a strongly-typed client interface for
[hub_methods]so the compiler catches mismatched method names between server and[client_type]instead of failing silently at runtime - Plan group membership for
[group_scenario]around a stable key like document ID, and handle rejoining groups after a reconnect, since group membership is lost on disconnect - For WebSocket auth, remember the token often rides in the query string, as
[auth_method]notes, because custom headers aren't available on the WebSocket handshake - Add a
[backplane]like Redis as soon as you run more than one instance; without it, messages only reach clients connected to the same server - Build reconnection with exponential backoff into the client from the start, since transient drops are normal and a client that gives up looks broken to users
- Use
IAsyncEnumerablestreaming for[streaming_scenario]to avoid materializing large payloads, and apply hub filters for rate limiting so one client can't flood the hub - Write integration tests with an in-process
HubConnectionso you exercise real hub methods and group routing rather than mocking the SignalR pipeline away
