Blazor WebAssembly i Server Side-Rendering, który powinienem wybrać?

Rozpoczynając projekt w Blazorze jedną z pierwszych decyzji do podjęcia będzie wybór modelu hostowania. Jest to dosyć istotna kwestia ze względu na różnice, które występują między nimi. Po dokonaniu wyboru musimy cały czas pamiętać, gdzie tak naprawdę wywołuje się kod i jakie są tego konsekwencje. Nie traćmy czasu i sprawdźmy czym różnią się od siebie.

Blazor Server Side-Rendering

W modelu Blazor Server Side-Rendering cała aplikacja hostowana jest po stronie serwera. Podczas pierwszego pobrania aplikacji nawiązywane jest połączenie przez SignalR, które do serwera przesyła akcje użytkownika, a następnie serwer oblicza zmiany komponentów jakie należy wprowadzić oraz przesyła je w formie wyrenderowanych części DOM strony do klienta. Schemat takiej aplikacji wygląda następująco:

The browser interacts with the app (hosted inside of an ASP.NET Core app) on the server over a SignalR connection.
Źródło: Blazor Server, docs.microsoft.com

Takie podejście zapewnia mniejszy czas pierwszego ładowania strony, ponieważ nie potrzebujemy pobierać całego kodu aplikacji frontendowej do naszej przeglądarki oraz runtime .NETa, który pozwoliłby na jego uruchomienie. Natomiast wszelkie akcje wykonywane na stronie będą dodatkowo opóźnione poprzez network latency, czyli czas w jakim odpowiedź z serwera będzie przesyłana do klienta. Również skalowalność takiego rozwiązania może okazać się niezbędna ze względu na to, że to serwer zajmuje się całym procesem renderowania, lecz w zamian otrzymujemy rozwiązanie, które jest niezależne od tego czy przeglądarka klienta wspiera najnowsze rozwiązania takie jak WASM oraz na jakie są parametry maszyny na której uruchamiana jest aplikacja po stronie klienta. Należy jeszcze pamiętać o tym, że skoro cały kod jest renderowany po stronie serwera to również JavaScript, który umieścimy na stronie będzie renderowany przez serwer. Podsumowując poniżej lista zalet i wad tego podejścia:

Zalety Blazor Server-Side Rendering
  • Obsługa wszystkich bibliotek wspierających .NET,
  • Początkowe ładowanie aplikacji jest bardzo szybkie,
  • Aplikacja po stronie klienta nie ma potrzeby pobierania dodatkowych bibliotek do działania,
  • Wsparcie dla starszych przeglądarek,
  • Obsługa Hot-Reload w .NET 6,
  • Niezależna od parametrów maszyny klienta,
  • Możliwość cache’owania danych oraz wyników obliczeń po stronie serwera,
  • Kod aplikacji nie trafia do klienta, jedynie wynik renderowania z serwera.
Wady Blazor Server-Side Rendering
  • Skrypty JavaScript wykonywane po stronie serwera,
  • Aplikacja nie działa w trybie offline,
  • Responsywność aplikacji jest gorsza, każda akcja użytkownika trafia na serwer, jest tam renderowana, a wynik musi być przesłany do klienta,
  • Skomplikowana skalowalność aplikacji,
  • Aplikacja będzie zużywała większe ilości pamięci ze względu na bardziej intensywną prace,
  • Nie ma możliwości wykorzystania modelu serverless po stronie serwera.

Blazor WebAssembly

Model Blazor WebAssembly wykorzystuje wsparcie przeglądarek dla Webassembly, czyli możliwość wykonania kodu w językach takich jak C++, Rust czy C# bezpośrednio w przeglądarce. Aby to było możliwe na początku przeglądarka pobiera runtime .NETa, następnie pobiera pliki dll naszej aplikacji oraz wykonuje je renderując poszczególne komponenty. Schemat działania takiej aplikacji wygląda następująco:

Blazor WebAssembly: The Blazor app runs on a UI thread inside the browser.
Źródło: Blazor WebAssembly, docs.microsoft.com

Innowacyjność tego pomysłu polega na tym, że nie musimy używać parserów z C# do JavaScript bądź przesyłać do serwera naszego kodu w momencie, gdy chcemy wykonać akcje na stronie. Takie podejście pozwala na stworzenie aplikacji, która może działać całkowicie w offline mode, dodatkowo nasz serwer nie jest tak mocno obciążony, bo większość pracy wykonuje przeglądarka klienta. Ma to też swoje konsekwencje, musimy mocniej dbać o szybkość działania aplikacji, bo nie mamy kontroli nad tym na jakim sprzęcie zostanie uruchomiona, a nasze pliki wynikowe są bezpośrednio wykonywane w przeglądarce, więc potencjalnie mogą zostać przechwycone oraz zdekompilowane. Niewątpliwą zaletą pozostaje także to, że w dalszym ciągu możemy nawiązywać komunikacje z przeglądarką korzystać z jej API jak localStorage i wykonywać na niej kod JavaScript.

Zalety Blazor WebAssembly
  • Dostęp do Web API przeglądarki oraz lokalne uruchamianie JavaScriptu,
  • Czysty podział na część frontendową i backendową, a co za tym idzie łatwiejsze utrzymanie kodu wysokiej jakości,
  • Szybsze wykonywanie akcji użytkownika przez brak narzutu w postaci komunikacji z serwerem,
  • Aplikacja może działać w trybie offline,
  • Łatwiejsze skalowanie części backendowej aplikacji,
  • Wykorzystywanie maszyny klienta do uruchamiania frontendu obniża koszty utrzymania rozwiązania,
  • Server backendowy może być napisany w dowolnej technologii,
  • Możliwe jest wykorzystanie rozwiązań serverless.
Wady Blazor WebAssembly
  • Wolniejsza inicjalizacja aplikacji, ze względu na potrzebę pobrania zależności i runtime .NET,
  • Rozmiar aplikacji do pobrania jest znacznie większy,
  • Konieczność większej optymalizacji aplikacji, aby działała płynnie na słabszych maszynach,
  • WebAssembly dla .NETa jest znacznie wolniejsze niż rozwiązania w JavaScript,
  • Brak wsparcia z Hot Reload,
  • Brak wsparcia dla starszych przeglądarek,
  • Kod aplikacji przesyłany do przeglądarki, potencjalnie może być przejęty i zdekompilowany.

Jeżeli stoisz przed wyborem, który model hostowania aplikacji Blazor wybrać to przede wszystkim weź pod uwagę jak bardzo rozbudowana jest aplikacja pod względem ui oraz na jakich maszynach będzie uruchamiana. Jeżeli jest to bardziej skomplikowana aplikacja i nie masz pewności co do tego czy wszystkie maszyny będą wystarczająco wydajne, aby uruchomić Twoją aplikację to lepszym pomysłem jest wybór Blazor Server-Side Rendering. Kolejną kwestią, którą warto wziąć pod uwagę jest ilość użytkowników korzystających jednocześnie z aplikacji. W przypadku modelu Blazor Server-Side Rendering im więcej jest użytkowników tym serwer będzie bardziej obciążony ze względu, że każda zmiana aplikacji musi być przez niego wyrenderowana, więc o wiele korzystniejsze jest wybranie Blazor WebAssembly. Dodatkowo, jeżeli aplikacja ma działać w trybie offline bądź backend niekoniecznie musi być wykonany w C# wtedy jedynym wyjściem jest Blazor WebAssembly, natomiast gdy wsparcie dla starszych przeglądarek jest priorytetem to nie pozostaje nic innego jak wybrać Blazor Server-Side Rendering.

Bez względu na początkowy wybór modelu hostowania późniejsza jego zmiana jest możliwa. Dobrze zaprojektowane komponenty w większości przypadków będą wyglądać podobnie w obu modelach, więc przejście z jednego modelu do drugiego nie powinno wymagać zbyt wiele czasu.

Jeżeli uznasz ten post za przydatny to proszę udostępnij go innym, natomiast jak chcesz być na bieżąco i otrzymywać informacje o moich aktywnościach przed innymi to zapraszam Cię do newslettera na którym regularnie udostępniam przedpremierowo artykuły, materiały wideo i wiele więcej.

Share via
Copy link
Powered by Social Snap