Index · Quick recall Q&A | SignalR

Backend / SignalR / Index / Quick recall Q&A

Index · Quick recall Q&A

1 min read

Mid-level5 min read

Rapid overview

Quick recall Q&A

Quick recall Q&A

SignalR when you need automatic fallbacks, connection management, groups for broadcasting, and easy horizontal scaling with Redis. Raw WebSockets for maximum performance with custom protocols where you control both endpoints.

Q: When would you choose SignalR over raw WebSockets?

Use a backplane like Redis or Azure SignalR Service. The backplane distributes messages across server instances so any server can send to any connected client.

Q: How do you scale SignalR horizontally?

Skip negotiation bypasses the initial HTTP request that determines transport. Use it when you know WebSocket is supported and want faster connection establishment. Don't use it if you need fallbacks.

Q: What is skip negotiation and when would you use it?

Inject IHubContext<THub> and use its Clients property to send messages. The background service doesn't need a connection - it uses the server's infrastructure.

Q: How do you send notifications from a background service?

Create groups prefixed with tenant ID (e.g., tenant:{tenantId}). On connection, validate the tenant claim and add to appropriate groups. Always scope group names by tenant for isolation.

Q: How do you handle multi-tenant notifications?

No. Service Workers can't maintain WebSocket connections. The pattern is: SignalR → Main Thread → postMessage → Service Worker → OS Notification. Service Workers only handle display.

Q: Can Service Workers receive SignalR messages directly?