Budujesz panel administracyjny, system CRM albo aplikację wewnętrzną i chcesz pisać interfejs w C#, bez przenoszenia całej logiki do JavaScriptu? Model Blazor Server pozwala wykonywać komponenty na serwerze, a do przeglądarki przesyłać tylko zdarzenia i zmiany interfejsu. Wyjaśniam, jak działa ta technologia, kiedy ma sens, jak uruchomić ją w aktualnym .NET oraz na jakie problemy uważać przed wdrożeniem.
Serwerowa interaktywność sprawdza się tam, gdzie liczy się szybki start i pełny dostęp do .NET
- Logika aplikacji działa na serwerze, a przeglądarka komunikuje się z nim przez SignalR.
- Start projektu w aktualnym .NET najłatwiej wykonać za pomocą szablonu Blazor Web App z interaktywnością Server.
- Największe zalety to mały rozmiar pobieranych plików, dostęp do API .NET i brak konieczności budowania osobnego backendu dla komponentów.
- Największe ograniczenie stanowi stałe połączenie z serwerem oraz koszt utrzymywania stanu dla każdej aktywnej karty przeglądarki.
- Najlepsze zastosowania to panele biznesowe, intranety, systemy ERP, CRM i aplikacje, w których użytkownicy pracują online.
Jak działa aplikacja Blazor po stronie serwera
W klasycznym podejściu do aplikacji webowej kliknięcie przycisku powoduje wysłanie żądania HTTP, a serwer zwraca odpowiedź. Tutaj komponent Razor działa na serwerze, przechwytuje zdarzenie, zmienia swój stan i wysyła do przeglądarki tylko różnicę w interfejsie. Dzięki temu użytkownik widzi aktualizację bez pełnego przeładowania strony.
Za komunikację odpowiada SignalR, czyli biblioteka do dwukierunkowej wymiany danych w czasie rzeczywistym. Najczęściej wykorzystywane są WebSockety, a gdy środowisko ich nie obsługuje, połączenie może przejść na mechanizm zastępczy, na przykład Long Polling.
Obwód przechowuje stan użytkownika
Każda aktywna karta przeglądarki tworzy po stronie serwera własny circuit, czyli obwód przechowujący stan komponentów i połączenie z klientem. Jeden użytkownik otwierający aplikację w trzech kartach może więc zużywać zasoby podobne do trzech niezależnych sesji interaktywnych.
To ważna różnica względem zwykłych stron renderowanych na serwerze. Zamknięcie karty zazwyczaj zwalnia zasoby od razu, ale chwilowa utrata sieci może pozostawić obwód w pamięci przez czas potrzebny na ponowne połączenie. Przy małej aplikacji nie jest to problem. Przy tysiącach użytkowników trzeba już mierzyć zużycie pamięci, liczbę połączeń i obciążenie procesora.
Przykład obsługi zdarzenia
Prosty licznik dobrze pokazuje cały mechanizm. Kod komponentu pozostaje po stronie serwera, a kliknięcie przycisku wywołuje metodę C# przez aktywne połączenie.
@page "/licznik"
@rendermode InteractiveServer
Licznik
Aktualna wartość: @count
@code {
private int count;
private void Increase()
{
count++;
}
}W nowym projekcie dyrektywa @rendermode InteractiveServer włącza interaktywność dla konkretnego komponentu. Ja preferuję takie podejście na początku projektu, ponieważ pozwala uruchomić interakcje tylko tam, gdzie są potrzebne, zamiast obciążać nimi całą aplikację.
Co naprawdę zyskujesz, a za co płacisz
Największą zaletą jest mały pakiet początkowy. Przeglądarka nie musi pobierać całego środowiska .NET WebAssembly ani wszystkich bibliotek aplikacji. Pierwszy ekran może pojawić się szybko, szczególnie gdy użytkownik pracuje na słabszym urządzeniu albo korzysta z firmowego komputera z ograniczonymi zasobami.
Drugi mocny punkt to dostęp do pełnego środowiska serwerowego. Komponent może korzystać z usług .NET, baz danych, systemów plików i bibliotek, których nie da się bezpośrednio uruchomić w sandboxie przeglądarki. Nie oznacza to jednak, że można bezmyślnie wkładać całą logikę do plików .razor. Warstwa domenowa i dostęp do danych nadal powinny być oddzielone.
Ceną za ten komfort jest zależność od połączenia z serwerem. Każde kliknięcie, wpisanie wartości obsługiwanej przez zdarzenie albo zmiana stanu wymaga komunikacji przez sieć. W tej technologii nie ma prawdziwego trybu offline, a opóźnienie będzie odczuwalne, jeśli użytkownik znajduje się daleko od regionu, w którym działa aplikacja.
Kiedy ten model pasuje najlepiej
- Panele administracyjne, w których użytkownicy wykonują wiele operacji na danych.
- Systemy CRM i ERP, gdzie logika biznesowa korzysta bezpośrednio z usług serwerowych.
- Intranety, ponieważ użytkownicy pracują zwykle w stabilnej sieci firmowej.
- Dashboardy operacyjne, które muszą reagować na zmiany danych w czasie rzeczywistym.
- Narzędzia wewnętrzne, dla których ważniejsza jest produktywność zespołu niż działanie bez połączenia z internetem.
Nie wybrałbym tego modelu do aplikacji, która ma działać w samolocie, na niestabilnym łączu albo jako globalny produkt konsumencki z bardzo dużą liczbą krótkich sesji. W takich przypadkach lepszym kierunkiem może być WebAssembly, renderowanie statyczne albo rozwiązanie hybrydowe.
Jak uruchomić projekt w aktualnym .NET
W projektach od .NET 8 najczęściej tworzy się Blazor Web App, a nie osobny projekt o nazwie sugerującej dawny model hostingu. Serwerowa interaktywność jest dziś jednym z trybów renderowania komponentów. Dla nowego projektu można użyć polecenia:
dotnet new blazor -o Portal -int Server
cd Portal
dotnet runOpcja -int Server ustawia interaktywność serwerową. Szablon przygotowuje podstawową konfigurację, ale dobrze rozumieć, co dzieje się pod spodem. W pliku Program.cs potrzebne są usługi komponentów oraz obsługa serwerowego trybu renderowania.
builder.Services
.AddRazorComponents()
.AddInteractiveServerComponents();
app.MapRazorComponents()
.AddInteractiveServerRenderMode(); Interaktywność można włączyć dla pojedynczej strony albo wyższego komponentu. Gdy używasz jej tylko lokalnie, komponent statyczny może pozostać zwykłym HTML-em, a aktywny fragment otrzyma tryb InteractiveServer. Takie ograniczanie zakresu interaktywności zwykle poprawia kontrolę nad wydajnością.
Ważne jest również prerenderowanie. Najpierw serwer wysyła gotowy HTML, dzięki czemu użytkownik szybko widzi zawartość, a dopiero później komponent nawiązuje połączenie i staje się interaktywny. Jeśli inicjalizacja danych uruchamia się dwa razy albo interfejs przez chwilę miga, przyczyną często jest właśnie brak rozdzielenia fazy prerenderowania od właściwego uruchomienia komponentu.
Blazor Server, WebAssembly i statyczny SSR w jednym zestawieniu
Wybór nie powinien opierać się na popularności technologii, lecz na sposobie pracy aplikacji. Poniższe porównanie pokazuje praktyczne różnice między najważniejszymi wariantami.
| Cecha | Interaktywność serwerowa | Blazor WebAssembly | Statyczny SSR |
|---|---|---|---|
| Miejsce wykonywania kodu | Serwer | Przeglądarka | Serwer podczas żądania |
| Stałe połączenie | Tak | Nie, po pobraniu aplikacji | Nie |
| Rozmiar pierwszego pobrania | Zwykle mały | Zwykle większy | Bardzo mały |
| Działanie offline | Nie | Możliwe po przygotowaniu aplikacji | Nie |
| Dostęp do usług serwera | Bezpośredni | Przez API | Bezpośredni podczas renderowania |
| Interakcje bez przeładowania | Tak | Tak | Nie bez dodatkowego trybu interaktywnego |
| Główne ryzyko | Obciążenie połączeniami i stanem | Duży pakiet oraz ograniczenia przeglądarki | Ograniczona interaktywność |
W praktyce nie trzeba wybierać jednego wariantu dla każdej strony. Współczesny Blazor pozwala połączyć statyczne renderowanie treści, interaktywność serwerową w formularzach i WebAssembly tam, gdzie opłaca się przenieść pracę do przeglądarki. To podejście jest rozsądniejsze niż traktowanie całej aplikacji jako jednego monolitycznego trybu.
Na co uważać podczas wdrożenia produkcyjnego
Skalowanie połączeń
Najczęstszy błąd polega na porównywaniu tej aplikacji wyłącznie przez liczbę żądań HTTP. Tutaj trzeba obserwować także liczbę aktywnych obwodów, czas ich życia, pamięć procesu i przepustowość komunikacji SignalR. Dziesięć tysięcy krótkich żądań może być łatwiejsze do obsłużenia niż kilka tysięcy długotrwałych sesji z intensywną interakcją.
Przy wielu instancjach aplikacji potrzebujesz świadomej konfiguracji warstwy SignalR i równoważenia ruchu. W większych środowiskach warto rozważyć zarządzaną usługę SignalR, ale sama usługa nie naprawi źle zaprojektowanych komponentów. Najpierw ogranicz ilość stanu, częstotliwość odświeżania i rozmiar danych przesyłanych przy interakcji.
Stan komponentu i baza danych
Nie przechowuj długo żyjącego obiektu DbContext bezpośrednio w komponencie. Obwód może działać przez wiele minut, a nawet godzin, podczas gdy kontekst Entity Framework Core powinien zwykle żyć krótko i obsługiwać konkretną operację. Bezpieczniejszy wzorzec to fabryka kontekstu oraz osobny kontekst dla odczytu lub zapisu.
Podobnie ostrożnie traktuj dane użytkownika. Stan komponentu jest przechowywany na serwerze, więc trzeba kontrolować jego rozmiar i nie wkładać do niego dużych kolekcji, plików ani danych, które można ponownie pobrać z repozytorium.
Przeczytaj również: var w JavaScripcie - zakres, hoisting i pułapki starego kodu
Połączenia i bezpieczeństwo
WebSockety powinny działać przez poprawnie skonfigurowany serwer proxy, a aplikacja musi reagować na utratę połączenia czytelnym komunikatem. Użytkownik powinien wiedzieć, czy formularz został zapisany, czy tylko oczekuje na ponowne połączenie.
Blazor nie zwalnia z klasycznych zasad bezpieczeństwa. Nadal potrzebujesz autoryzacji po stronie serwera, walidacji danych wejściowych, ochrony przed nieuprawnionym dostępem i kontroli uprawnień przy każdej operacji biznesowej. Ukrycie kodu C# przed przeglądarką nie zastępuje poprawnego modelu bezpieczeństwa.
Jak podjąć dobrą decyzję dla konkretnej aplikacji
Ja zaczynam od czterech pytań. Czy użytkownicy będą pracować stale online? Czy interfejs wykonuje operacje wymagające dostępu do serwera? Czy liczba równoczesnych sesji jest możliwa do oszacowania? Czy aplikacja musi działać na urządzeniach mobilnych z niestabilnym połączeniem?
Jeśli odpowiedzi brzmią odpowiednio tak, tak, tak i nie, model serwerowy jest bardzo rozsądnym kandydatem. Otrzymujesz szybki start, jeden język po obu stronach i prosty dostęp do usług .NET. Jeśli najważniejsze są praca offline, globalny zasięg i odciążenie serwera, zacząłbym od WebAssembly albo rozwiązania mieszanego.
Przed ostateczną decyzją przygotowałbym mały prototyp z logowaniem, formularzem, tabelą danych i operacją zapisu. Następnie zmierzyłbym czas reakcji, zachowanie po zerwaniu sieci oraz zużycie pamięci przy jednej, dziesięciu i większej liczbie aktywnych kart. Taki test daje więcej niż ogólne opinie o wydajności frameworka.
Najrozsądniejszy pierwszy krok z Blazorem
Jeżeli tworzysz aplikację biznesową w ekosystemie .NET i nie potrzebujesz trybu offline, zacznij od małego projektu z interaktywnością serwerową włączoną tylko tam, gdzie jest potrzebna. Zadbaj od początku o krótkie operacje bazodanowe, ograniczony stan komponentów i poprawne zachowanie po utracie połączenia.
To podejście pozwala wykorzystać moc C# i ASP.NET Core bez dokładania niepotrzebnej warstwy komunikacyjnej. Gdy wymagania się zmienią, komponenty można stopniowo przenosić do WebAssembly albo pozostawić statyczne, zamiast przebudowywać całą aplikację od zera.
