Blazor to nowoczesny framework od Microsoftu pozwalający tworzyć interaktywne aplikacje webowe w C# i .NET, bez użycia JavaScript. Tworząc aplikację w Blazorze, staniesz przed wyborem jednego z dwóch modeli hostowania komponentów: Blazor Server lub Blazor WebAssembly (WASM). Każdy z nich ma swoje unikalne cechy, zalety i ograniczenia. W tym artykule krótko wyjaśnię, na czym polegają różnice między Blazor Server a Blazor WebAssembly, i podpowiem, który wariant może lepiej pasować do Twojego projektu.
Blazor Server – aplikacja na serwerze
Blazor Server uruchamia aplikację całkowicie po stronie serwera. Interfejs użytkownika renderuje się na serwerze w ramach aplikacji ASP.NET Core, a do przeglądarki wysyłane są jedynie różnice w UI (tzw. diffs) przez stałe połączenie w czasie rzeczywistym (SignalR). Przeglądarka klienta działa tu jako cienki klient – otrzymuje minimalny plik HTML/JS, który ustanawia połączenie WebSocket z serwerem i zajmuje się stosowaniem aktualizacji DOM na stronie. W efekcie większość pracy wykonuje serwer, a klient pokazuje jedynie wyniki.
Zalety Blazor Server. Po stronie plusów tego modelu można wymienić bardzo mały rozmiar początkowy aplikacji i szybkie wczytanie – do przeglądarki trafia tylko lekki plik startowy zamiast całego .NET runtime. Aplikacja może od razu reagować, bo nie musi pobierać dużych paczek danych. Ponadto logika działa na serwerze .NET, dzięki czemu mamy pełny dostęp do API platformy .NET i zasobów serwera (np. bazy danych, systemu plików) bezpośrednio z kodu Blazor. Łatwiej jest też zadbać o bezpieczeństwo kodu i danych – cała baza kodu .NET/C# pozostaje na serwerze, więc żadne wrażliwe fragmenty (np. klucze API, tajne algorytmy) nie są wysyłane do przeglądarki. Co więcej, Blazor Server zadziała nawet w starszych lub ograniczonych środowiskach – wspiera przeglądarki nieobsługujące WebAssembly oraz słabsze urządzenia, ponieważ klient nie musi wykonywać ciężkich operacji.
Ograniczenia Blazor Server. Trzeba mieć na uwadze kilka istotnych minusów. Po pierwsze, aplikacja wymaga stałego połączenia sieciowego z serwerem – jeśli je stracimy, interfejs przestanie działać (brak trybu offline). Każda interakcja użytkownika wiąże się z podróżą danych do serwera i z powrotem, co wprowadza dodatkowe opóźnienie zależne od sieci (tzw. latencję). Dlatego bardzo dynamiczne interfejsy (np. śledzenie ruchu myszy w czasie rzeczywistym) mogą działać mniej płynnie w modelu server-side. Kolejna kwestia to skalowalność – serwer utrzymuje osobny stan (tzw. circuit) dla każdego podłączonego klienta, przez co zużycie pamięci i obciążenie CPU na serwerze rośnie wraz z liczbą użytkowników. Przy dużej skali aplikacji może być potrzebne optymalizowanie infrastruktury (np. farmy serwerów, Azure SignalR Service itp.). Wreszcie, Blazor Server nie zadziała bez backendu – do uruchomienia potrzebny jest serwer ASP.NET Core. Nie da się takiej aplikacji hostować jako statycznej strony na CDN czy serwerze plików – zawsze musi działać kod .NET na serwerze.
Blazor WebAssembly – aplikacja w przeglądarce
Blazor WebAssembly uruchamia aplikację po stronie klienta, w przeglądarce użytkownika, wykorzystując technologię WebAssembly. Przy starcie aplikacji przeglądarka pobiera cały potrzebny kod: skompilowane assembly .NET, zależności oraz miniaturowy runtime .NET (plik dotnet.wasm). Gdy wszystko zostanie załadowane, aplikacja Blazor działa w całości w obrębie przeglądarki – renderowanie interfejsu i obsługa zdarzeń odbywają się lokalnie, na wątku UI w JavaScript/WASM, bez ciągłych okrążeń do serwera. Serwer (jeśli w ogóle jest używany) pełni wtedy rolę dostawcy danych lub plików, a nie uczestniczy w bieżącym renderowaniu interfejsu.
Zalety Blazor WebAssembly. Największą korzyścią jest to, że aplikacja po pobraniu może działać samodzielnie, nawet offline – nie jest potrzebne utrzymanie ciągłego połączenia z serwerem[17]. Dzięki temu Blazor WASM świetnie nadaje się do aplikacji, które mają działać jako PWA (Progressive Web App) lub po prostu muszą oferować tryb offline. Kolejny plus: odciążenie serwera – większość przetwarzania dzieje się na urządzeniu użytkownika, co zmniejsza wymagania co do mocy obliczeniowej i zasobów po stronie backendu. Przy odpowiednim zaprojektowaniu, serwer może ograniczyć się do roli API czy dostawcy danych, a logika biznesowa wykonuje się w przeglądarce użytkownika. Blazor WebAssembly umożliwia też tańsze i prostsze hostowanie aplikacji: można ją wdrożyć jako czysto statyczną witrynę (zestaw plików HTML/CSS/JS) na dowolnym hostingu lub CDN, bez potrzeby utrzymywania serwera aplikacyjnego .NET. Dla użytkownika końcowego aplikacja WASM potrafi być bardzo responsywna – po załadowaniu działa lokalnie, więc interakcje nie cierpią na opóźnienia sieciowe.
Ograniczenia Blazor WebAssembly. Cena za powyższe udogodnienia to kilka potencjalnych wad. Przede wszystkim większy rozmiar paczki aplikacji i dłuższy czas wczytywania – przeglądarka musi pobrać dość duży zestaw plików (assemblies .NET, runtime), zanim aplikacja wystartuje. Mimo że w publikowanej aplikacji stosuje się trimmery i kompresję, a pliki mogą cachować się w przeglądarce, pierwsze uruchomienie Blazor WASM bywa zauważalnie wolniejsze niż w przypadku Blazor Server. Ponadto, kod aplikacji jest publicznie dostępny po stronie klienta – doświadczeni użytkownicy mogą podejrzeć zdekompilowane DLL-e i wyciągnąć z nich np. ciągi znaków, klucze API czy logikę biznesową. Oznacza to, że nie należy umieszczać poufnych sekretów ani wrażliwych obliczeń w kodzie, który trafi do przeglądarki. Trzeba też pamiętać o ograniczeniach samego środowiska przeglądarki: aplikacja Blazor WebAssembly działa w sandboxie przeglądarki, więc jest ograniczona do tego, na co pozwala typowa aplikacja frontendowa. Na przykład, nie możemy bezpośrednio skorzystać z bibliotek .NET do dostępu do systemu plików, rejestru Windows czy bazy danych – te zasoby wymagają odrębnego API webowego (np. wywołania HTTP do serwera). W praktyce aplikacja WASM do komunikacji z serwerem używa typowych żądań HTTP/API lub gRPC, podobnie jak każda aplikacja JavaScript działająca w przeglądarce. Warto również zaznaczyć, że Blazor WebAssembly wymaga nowoczesnej przeglądarki z obsługą WebAssembly – w dzisiejszych realiach to standard (Edge, Chrome, Firefox, Safari itd.), ale np. Internet Explorer 11 nie jest wspierany.
Przykład różnicy w dostępie do danych:
W modelu Blazor Server nasza aplikacja działa na serwerze, więc może np. bezpośrednio korzystać z bazy danych przez Entity Framework lub inny mechanizm. Przykładowo, w komponencie Blazor Server możemy wstrzyknąć kontekst bazy i zapisać dane bezpośrednio:
@inject MyDbContext _dbContext;
<button @onclick="ZapiszDane">Zapisz</button>
@code {
void ZapiszDane()
{
var user = new User { Name = "Jan" };
_dbContext.Users.Add(user);
_dbContext.SaveChanges();
}
}W przypadku Blazor WebAssembly taka bezpośrednia operacja na bazie nie jest możliwa, ponieważ kod działa w przeglądarce. Zamiast tego typowo wywołujemy API na serwerze (np. REST API) za pomocą HttpClient. Analogiczny fragment w Blazor WebAssembly mógłby wyglądać tak:
@inject HttpClient _http;
<button @onclick="@(() => ZapiszDaneAsync(new User { Name = \"Jan\" }))">Zapisz</button>
@code {
public record User { public string Name { get; set; } }
async Task ZapiszDaneAsync(User newUser)
{
await _http.PostAsJsonAsync("https://moj-serwer/api/users", newUser);
}
}Tu metoda PostAsJsonAsync wysyła obiekt User do końcówki API na serwerze, która zajmuje się fizycznym zapisaniem danych do bazy. Taki podział na część kliencką (WASM) i serwerową (API) bywa dodatkową komplikacją, ale jest standardem w aplikacjach SPA działających w przeglądarce.
Kiedy wybrać Blazor Server, a kiedy Blazor WebAssembly?
Oba warianty Blazora pozwalają osiągnąć ten sam cel – zbudować bogatą interaktywną aplikację webową w C#, dzieląc nawet ten sam kod komponentów. Wybór zależy od specyfiki projektu.
Poniżej kilka wskazówek pomocnych przy decyzji:
• Wybierz Blazor WebAssembly, gdy zależy Ci na działaniu offline lub PWA – aplikacja po załadowaniu ma działać bez ciągłego połączenia z serwerem. WASM sprawdzi się też, gdy chcesz odciążyć serwer i przerzucić część pracy na klientów (np. w aplikacjach wymagających intensywnych obliczeń po stronie UI). Jest to dobry wybór dla aplikacji, które mają działać na wielu urządzeniach, korzystać z możliwości przeglądarki (np. dostęp do kamery, plików przez API przeglądarki) i być łatwe w wdrożeniu – hostowanie może ograniczyć się do plików statycznych na serwerze lub w chmurze. Przykładowe scenariusze to aplikacje typu SPA/PWA dla użytkowników końcowych, które muszą działać nawet przy słabym łączu lub jego braku (np. aplikacja notatkowa, edytor obrazów, prosta gra przeglądarkowa).
• Wybierz Blazor Server, jeśli bezpieczeństwo danych i kodu jest priorytetem – logika biznesowa i tajemnice pozostają na serwerze, więc łatwiej je zabezpieczyć. Ten model będzie lepszy dla aplikacji, które ściśle integrują się z zapleczem serwerowym – potrzebują bezpośredniego dostępu do bazy danych, plików, usług sieciowych w infrastrukturze firmy itp. Sprawdzi się też, gdy aplikacja ma mieć szybki start i niewielkie wymagania co do przeglądarki (np. musi działać w środowisku korporacyjnym na różnych, także starszych przeglądarkach). Blazor Server bywa naturalnym wyborem dla typowych aplikacji biznesowych: paneli administracyjnych, intranetowych systemów zarządzania, aplikacji finansowych czy formularzy biznesowych – czyli tam, gdzie użytkownik i tak pracuje online, a centralne przechowywanie stanu i logiki na serwerze ułatwia utrzymanie i kontrolę.
Warto dodać, że oba modele nie muszą się wzajemnie wykluczać. Od .NET 8 pojawiły się tzw. hybrydowe podejścia (Blazor United), łączące rendering server-side z funkcjonalnością WebAssembly w jednej aplikacji. Możliwe jest również przeportowanie aplikacji Blazor Server na WebAssembly lub odwrotnie, ponieważ komponenty Razor są współdzielone – jednak wymaga to dodatkowej pracy i przemyślenia architektury. Na start najlepiej wybrać jeden model zgodnie z powyższymi wskazówkami.
Podsumowanie
Blazor Server i Blazor WebAssembly to dwie różne drogi do zbudowania aplikacji Blazor, każda z pewnymi przewagami w określonych scenariuszach. Jeśli potrzebujesz pełnej mocy .NET na serwerze, natychmiastowego renderowania i nie planujesz wsparcia trybu offline – prawdopodobnie lepszy będzie Blazor Server. Jeśli natomiast cenisz działanie po stronie klienta, możliwość pracy bez ciągłego połączenia i łatwą skalowalność po stronie frontendu – Blazor WebAssembly może być właściwym wyborem. Ostatecznie decyzja powinna zależeć od wymagań Twojego projektu, warunków środowiskowych oraz oczekiwań użytkowników.
Jeżeli chcesz lepiej poznać Blazora w praktyce – zarówno w wariancie Server, jak i WebAssembly – zachęcam do sprawdzenia mojego szkolenia online Szkoła Blazora. To kompleksowe szkolenie, w którym krok po kroku budujemy aplikacje w obu modelach i omawiamy ich zastosowanie. Być może pomoże Ci ono szybciej opanować Blazora i zyskać pewność przy wyborze odpowiedniej technologii do kolejnego projektu. Powodzenia w tworzeniu aplikacji.
