.NET Conf

ASP.NET SignalR to nowoczesna, open source’owa biblioteka, która zmienia sposób realizacji funkcjonalności czasu rzeczywistego w aplikacjach .NET. Umożliwia natychmiastowe wypychanie danych z serwera do klientów, eliminując potrzebę ciągłego odpytywania oraz tradycyjny model żądanie-odpowiedź. SignalR automatycznie zarządza połączeniami, zapewniając trwałą komunikację między serwerem a klientem – nawet na dużą skalę.

Spis treści [odkryj]

Technologia wspiera skalowanie do tysięcy klientów, współpracując z popularnymi rozwiązaniami, takimi jak Redis, SQL Server, czy Azure Service Bus. SignalR obsługuje szeroką gamę platform klienckich: JavaScript, .NET, Java oraz Swift, dzięki czemu sprawdza się w aplikacjach webowych, mobilnych, desktopowych i grach.

Fundamenty i architektura SignalR

Koncepcja technologii czasu rzeczywistego

Realizując internetowe funkcje czasu rzeczywistego, SignalR umożliwia błyskawiczne przekazywanie treści z serwera do klientów natychmiast po ich pojawieniu się. Dzięki temu użytkownik widzi aktualizacje bez konieczności odświeżania strony czy długiego sondowania.

Aplikacje webowe z obsługą czasu rzeczywistego pozwalają na kreowanie nowoczesnych, dynamicznych i angażujących interfejsów, które natychmiast reagują na zdarzenia użytkowników oraz zmiany danych.

Mechanizmy transportu i protokoły

SignalR stosuje inteligentną negocjację transportu, automatycznie wybierając najwydajniejszy dostępny protokół komunikacji między klientem a serwerem:

  • webSockets – najwydajniejszy transport niskiej latencji zapewniający pełną dwukierunkową komunikację,
  • Server-Sent Events (SSE) – używane, gdy WebSockets są niedostępne,
  • długie sondowanie (long polling) – fallbackowy mechanizm zapewniający kompatybilność z niemal każdym środowiskiem.

WebSockets to fundament efektywności SignalR; produkcyjnie zaleca się zawsze korzystać z protokołu WSS z szyfrowaniem (443), szczególnie w aplikacjach zewnętrznych. Mechanizmy fallback logic gwarantują, że niezależnie od środowiska, klient podejmie próbę ustanowienia połączenia.

Architektura hub-ów i RPC

Podstawą SignalR są huby (hubs) – centralny pipeline komunikacji opartej o model zdalnych wywołań procedur (RPC). Hub umożliwia serwerowi wykonywanie metod klienta oraz obsługę dynamicznych, asynchronicznych żądań.

Kluczowe korzyści architektury hubów:

  • różnicowanie komunikacji do wszystkich klientów, wybranych grup lub pojedynczych połączeń (Clients.All, Clients.Group),
  • w pełni asynchroniczna obsługa dla optymalnej skalowalności,
  • łatwość integracji logiki biznesowej po stronie serwera i klienta.

Deweloper definiuje metody w klasie dziedziczącej Microsoft.AspNetCore.SignalR.Hub, które po stronie frontendu wywoływane są jako funkcje JavaScript.

Konfiguracja i implementacja SignalR

Podstawowa konfiguracja projektu

Aby dodać SignalR do projektu ASP.NET Core, wykonaj następujące kroki:

  • zainstaluj pakiet NuGet Microsoft.AspNetCore.SignalR komendą dotnet add package Microsoft.AspNetCore.SignalR,
  • zarejestruj usługi SignalR w metodzie konfiguracji aplikacji: builder.Services.AddSignalR(),
  • zdefiniuj endpoint hub-a, np. app.MapHub<ChatHub>("/chatHub").

W środowiskach produkcyjnych zadbaj o:

  • włączenie HTTPS,
  • obsługę HSTS,
  • implementację właściwego mechanizmu obsługi wyjątków i autoryzacji.

Tworzenie i implementacja hub-ów

Proces implementacji hub-a jest niezwykle szybki. Stwórz nową klasę ChatHub dziedziczącą po Hub i zaimplementuj metodę zdalnego wywołania:

using Microsoft.AspNetCore.SignalR;
namespace SignalRChat.Hubs
{
    public class ChatHub : Hub
    {
        public async Task SendMessage(string user, string message)
        {
            await Clients.All.SendAsync("ReceiveMessage", user, message);
        }
    }
}

Hub samodzielnie zarządza połączeniami i przesyłaniem wiadomości, co upraszcza implementację nawet rozbudowanych scenariuszy komunikacyjnych.

Integracja z klientami JavaScript

Integracja SignalR po stronie JavaScript opiera się o dedykowaną bibliotekę, która generuje skrypt hubs pozwalający klienckiemu kodowi na połączenie z serwerem oraz odbiór/wysłanie wiadomości.

SignalR na froncie obsługuje automatyczne ponowne nawiązywanie połączenia z użyciem metody .withAutomaticReconnect(). Pamiętaj, by przy reconnect ręcznie przywracać członkostwo w grupach.

Praktyczne przykłady zastosowań

SignalR sprawdzi się w wielu scenariuszach, takich jak:

  • Chat w czasie rzeczywistym – synchronizacja wiadomości między wieloma użytkownikami,
  • Monitorowanie długotrwałych procesów – prezentowanie postępu i etapów przetwarzania na żywo,
  • Dashboardy analityczne – aktualizacja metryk, wykresów i statusów bez odświeżania strony,
  • Gry i aplikacje interaktywne – szybka wymiana komunikatów pomiędzy graczami z niską latencją.

W każdym z tych przypadków SignalR usprawnia wrażenia użytkownika, redukując opóźnienia i tworząc nowoczesny, dynamiczny interfejs.

Zaawansowane funkcjonalności i wzorce

Zarządzanie grupami i targeted messaging

Zaawansowany system grup pozwala ograniczyć ruch i precyzyjnie kierować wiadomości do segmentów użytkowników.

  • Przypisywanie i usuwanie z grup odbywa się metodami AddToGroupAsync() i RemoveFromGroupAsync();
  • Grupy nie są automatycznie odtwarzane po reconnect – konieczna jest manualna obsługa;
  • Targeted messaging radykalnie poprawia wydajność aplikacji przy dużej liczbie klientów.

Uwierzytelnianie i autoryzacja

SignalR obsługuje różne mechanizmy bezpieczeństwa. Dla zapewnienia bezpieczeństwa:

  • Stosuj protokół WSS oraz stateless JWT (Bearer token) w headerze lub parametrze query;
  • Pamiętaj, że uwierzytelnianie następuje tylko podczas nawiązywania połączenia i należy nadal weryfikować każdy komunikat;
  • Wykorzystuj atrybut [Authorize] dla ochrony hubów i ich metod.

Zarządzanie stanem połączeń

Rozłączanie klienta wymaga czyszczenia zasobów w metodzie OnDisconnectedAsync() oraz informowania użytkownika o stanie połączenia w UI. Deweloperzy powinni zarządzać grupami i cyklem życia połączenia manualnie.

Versioning i ewolucja API

Zaleca się wersjonowanie hubów, np. ChatHubV2, oraz stosowanie feature flags podczas zmian. Dodawanie nowych metod powinno odbywać się w sposób nie ingerujący w starszych klientów.

Skalowanie i wydajność

Architektura scale-out i backplane

W podstawowym scenariuszu wszystkie połączenia SignalR obsługuje jeden serwer. W środowisku składającym się z wielu serwerów, niezbędne jest zastosowanie mechanizmu backplane, jak Redis:

  • Redis synchronizuje komunikaty między wieloma instancjami SignalR,
  • pozwala to na rozgłaszanie wiadomości do klientów podłączonych do różnych serwerów,
  • stanowi pojedynczy punkt awarii i może być wąskim gardłem przy dużym obciążeniu.

Azure SignalR Service jako managed solution

Azure SignalR Service to zarządzane rozwiązanie w chmurze, które eliminuje potrzebę własnej infrastruktury. Zalety tego podejścia:

  • Brak konieczności Redis backplane – komunikacja i skalowanie odbywają się wewnątrz platformy;
  • Automatyczne skalowanie oraz load balancing – bez ręcznej konfiguracji środowiska;
  • Obsługa milionów połączeń – dedykowana infrastruktura Azure sprawdzi się nawet w bardzo dużych aplikacjach.

Performance optimization i best practices

Najważniejsze wytyczne w zakresie wydajności SignalR:

  • Korzystaj z WebSocketów, jeśli to możliwe;
  • Włącz automatyczne ponowne połączenie przez .withAutomaticReconnect();
  • Minimalizuj i debouncuj komunikaty o dużej częstotliwości (np. typing, ruch myszą);
  • Loguj i monitoruj połączenia, zdarzenia błędów oraz wskaźniki wydajności z użyciem narzędzi Application Insights, Datadog, Prometheus.

Testy obciążeniowe i monitoring

Aplikacje SignalR powinny być testowane pod kątem:

  • przerw sieciowych oraz reconnect,
  • przepustowości przy dużej liczbie klientów (symuluj za pomocą narzędzi typu k6, Artillery),
  • latencji i rozkładu typów transportu,
  • rutynowego monitoringu Redis, sieci oraz serwerów aplikacyjnych dla identyfikacji wąskich gardeł.

Najlepsze praktyki i bezpieczeństwo

Najważniejsze wytyczne bezpieczeństwa

  • Zawsze stosuj protokół WSS (port 443) w środowisku produkcyjnym;
  • Używaj uwierzytelniania JWT lub opartego na roszczeniach ([Authorize]);
  • Waliduj wszystkie przychodzące wiadomości po stronie serwera, łącznie z sanityzacją treści HTML oraz ograniczeniami rozmiaru;
  • Ograniczaj częstotliwość wysyłania wiadomości, wdrażaj obsługę rozłączeń, czyszczenie pamięci oraz heartbeat.

Wzorce zarządzania połączeniami

Zaimplementuj łagodną obsługę rozłączeń, pooling połączeń oraz sprzątanie nieaktywnych klientów za pomocą OnDisconnectedAsync().

Stosuj limity i heartbeat do utrzymania zdrowia wszystkich połączeń oraz wykrywaj nieaktywne sesje.

Projektowanie komunikatów i optymalizacja protokołów

Projektowanie wiadomości powinno zapewniać ich lekkość i kompatybilność:

  • stosuj kompaktny JSON,
  • wersjonuj schematy komunikatów, by utrzymać zgodność wsteczną,
  • wdrażaj wsadowe przetwarzanie tam, gdzie obsługa pojedynczych wiadomości jest zbyt kosztowna.

Obsługa błędów i odporność

Stosuj circuit breaker, bulkhead oraz strategie timeout. Informuj użytkowników o statusie systemu i wdrażaj tryby degradacji, aby minimalizować wpływ awarii.

Ograniczenia i wyzwania

SignalR ma kilka istotnych ograniczeń, kluczowych dla aplikacji na dużą skalę:

  • skalowanie przy dużej liczbie połączeń wymaga Redis lub Azure SignalR Service, które mogą być wąskimi gardłami,
  • manualne zarządzanie grupami użytkowników i problematyką reconnect,
  • ograniczone wsparcie dla niektórych platform i restrykcyjnych przeglądarek,
  • potencjalne przeciążenie serwerów oraz narzut przez dużą liczbę wiadomości i połączeń.

Porównanie z alternatywami

Poniżej znajdziesz porównanie letnich technologii czasu rzeczywistego:

Rozwiązanie Model komunikacji Obsługa dwukierunkowa Automatyczna obsługa transportów Integracja z .NET Obsługa multimediów
SignalR Hub klient-serwer Tak Tak (WebSocket/SSE/Long Polling) Znakomita Nie (wymagana integracja)
WebSocket (surowy) Peer-to-peer/klient-serwer Tak Nie Tak (wymaga własnej implementacji) Nie
SSE (Server-Sent Events) Server-to-client Nie Nie Tak Nie
WebRTC Peer-to-peer Tak Nie Nie (wymaga dodatkowego kodu) Tak (audio/wideo)
gRPC streaming Klient-serwer/mikroserwisy Tak Nie Bardzo dobra (wymaga Protocol Buffers) Nie

SignalR wyróżnia się prostotą implementacji, automatycznym wsparciem transportów i ścisłą integracją z ekosystemem .NET, jednak alternatywy, jak surowe WebSockety czy gRPC, mogą być lepszym wyborem tam, gdzie liczy się maksymalna wydajność oraz pełna kontrola nad protokołem.