Decyzja została podjęta. Blazor się dzieje. Hurra! Ale co teraz? Czy po prostu uruchomić aplikację w IDE i zacząć pisać? Oczywiście, że możesz... To jest dokładnie to, co powinieneś robić, gdy odkrywasz, uczysz się, badasz.
W pewnym momencie nadejdzie jednak czas, aby rozpocząć coś profesjonalnego. Wyjaśnijmy jedną rzecz - Twój konkretny przypadek może wymagać unikalnego podejścia. Nie wdrażaj czegoś tylko dlatego, że jest to uważane za standard lub że tak nakazuje szablon. Poszerzaj swoją wiedzę, naginaj ją do swojego problemu. Nie na odwrót.
Pierwszą decyzją architektoniczną, którą będziesz musiał podjąć, jest wybór pomiędzy Blazor Server i Blazor WebAssembly. Różnica między nimi sprowadza się do ograniczeń i możliwości ich środowisk hostingowych.
Plusy i minusy rozwiązania po stronie serwera
Jeśli aplikacja jest w pełni hostowana na serwerze, jej środowisko uruchomieniowe i biblioteki nie będą musiały być pobierane na urządzenie użytkownika, osiągając bardzo szybki czas renderowania. Jeszcze szybciej z włączonymi opcjami wstępnego renderowania. Oznacza to również, że wykonywanie metod będzie odbywać się w środowisku, nad którym administrator ma pełną kontrolę. Cokolwiek jest potrzebne do uruchomienia aplikacji, może być preinstalowane, co sprawia, że rozwój jest praktycznie nieograniczony. Sprawia to również, że aplikacja jest kompatybilna z praktycznie każdą dostępną przeglądarką. Jest to szczególnie ważne, jeśli aplikacja ma być nadal dostępna dla IE 11 lub innych starszych przeglądarek. Projekt po stronie serwera będzie również najbardziej podobny do tworzenia starszej aplikacji MVC lub projektu API. Można zastosować te same zasady i logikę, więc proces wdrażania programistów powinien być szybki i wydajny.
Z drugiej strony, największym wyzwaniem, przed którym staniesz z serwerem Blazor, jest jego skalowalność. Jeśli pracujesz z Azure, większość ciężkich zadań można wykonać za Ciebie po wprowadzeniu odpowiedniej konfiguracji. W innych przypadkach hostingu, będziesz musiał zarządzać tym wszystkim samodzielnie. Każdy użytkownik będzie miał ustanowione dedykowane połączenie SignalR. Oznacza to również, że komunikacja żądanie/odpowiedź jest zupełnie inna niż w standardowej aplikacji internetowej. Zużycie pamięci może bardzo szybko wymknąć się spod kontroli. Biorąc pod uwagę, że cała komunikacja odbywa się za pośrednictwem ustalonego potoku, a nie przeładowywania pełnej strony, opóźnienia sieciowe muszą być ściśle monitorowane, a rozmiary pakietów zmian zmniejszane, gdy tylko jest to możliwe. Ostatnim minusem, który należy wziąć pod uwagę, jest brak wsparcia offline. W dzisiejszych czasach staje się to raczej oczekiwaną funkcją niż miłym dodatkiem.
O czym należy pamiętać w projekcie Blazor Server?
Przegląd:
- Jeśli masz jakiekolwiek wcześniejsze doświadczenie w tworzeniu aplikacji internetowych, niewiele się zmieni, gdy przełączysz się na Blazor Server.
- wszystkie pliki statyczne będą przechowywane w katalogu wwwroot
- pliki konfiguracyjne powinny być umieszczone w głównym katalogu projektu
- gdy ma to sens, podziel skrypty CSS na mniejsze fragmenty, skorzystaj z Blazora obsługującego pliki CSS na komponent, a także klasy CS code-behind
Wyzwania:
- Zrozumienie komunikacji SignalR
- utrzymywanie "zmienionego" zakresu znaczników na niskim poziomie, aby w pełni wykorzystać możliwości podzielonej komunikacji
- czasy życia usług będą zachowywać się inaczej, ponieważ jedno żądanie może być aktywne tak długo, jak aktywne jest połączenie gniazda
- stosowanie standardowej składni AddDbContext() do rejestracji połączenia z bazą danych może być problematyczne, ponieważ z założenia jej czas życia to AsScoped() - co to jest DbContextFactory?
- Śledzenie aktywnych użytkowników w porównaniu do wydajności aplikacji - co to jest CircuitHandler?
Blazor po stronie klienta - za i przeciw
Przy pierwszym żądaniu cała aplikacja jest pobierana do przeglądarki użytkownika. Oznacza to, że cała wewnętrzna logika jest zarządzana w całości na urządzeniu użytkownika, co skutkuje bardzo szybkim doświadczeniem użytkownika. Reakcje aplikacji powinny być natychmiastowe dla użytkownika, z wyjątkiem wszelkich zewnętrznych wywołań API, które muszą czekać na odpowiedź. Ma to również inną implikację: hostowanie aplikacji WebAssembly nie wymaga działającego serwera. Można ją uruchomić w pełni bezserwerowo! Microsoft sugeruje nawet, aby hostować ją jako statyczną aplikację internetową, ponieważ ogranicza to koszty i poprawia stabilność. Kolejną zaletą WASM jest wsparcie offline. Tak, oznacza to, że aplikację można uruchomić bez połączenia z Internetem, ale nie oznacza to, że aplikacja internetowa nagle zmieni się w natywną. Będzie ona buforowana, dając wrażenie natywnej, ale nadal będzie działać w powłoce podobnej do przeglądarki, ze wszystkimi jej zabezpieczeniami i ograniczeniami.
Bezpieczeństwo będzie największym zmartwieniem, jeśli Blazor Client-side będzie wyborem. Ponieważ cała aplikacja jest pobierana do przeglądarki użytkownika, można ją tam ujawnić przy odrobinie kopania. Niemniej jednak, wszystkie poufne dane lub logika biznesowa powinny być dostarczane za pośrednictwem interfejsu API, a nie w samej aplikacji. Oczywiście można zdecydować się na szyfrowanie, ale zewnętrzny dostawca byłby znacznie bardziej wydajny i ponownie - bezpieczny. Inną rzeczą, która może być wadą, jeśli nie jest odpowiednio zarządzana, jest początkowe ładowanie strony. Im cięższa jest skompilowana aplikacja, tym dłużej użytkownik będzie musiał czekać na jej załadowanie. Wprowadzono kilka ulepszeń, aby temu zaradzić, ale ostatecznie to nadal na deweloperze spoczywa obowiązek uczynienia rozwiązania lekkim i wydajnym. Opieraj się na interfejsach API, które nie muszą być dostępne lokalnie.
O czym należy pamiętać w projekcie Blazor WebAssembly?
Przegląd:
- wszystkie pliki statyczne są nadal przechowywane w katalogu wwwroot
- ten katalog jest wdrażany wraz z aplikacją w przeglądarce użytkownika
- Jeśli masz pliki konfiguracyjne, które są wymagane, należy je również umieścić w tym katalogu
- Obsługa offline wymaga, aby plik manifest.json był dostępny i dostarczony również do przeglądarki.
Wyzwania:
- Utrzymywanie niskiej wagi aplikacji w celu poprawy czasu ładowania strony - czym jest Runtime Relinking?
- Utrzymywanie niskiego czasu kompilacji aplikacji w celu szybszego dostarczania pakietów aplikacji - czym jest kompilacja AOT?
- oddzielając wrażliwe części od tych, którymi można się swobodnie dzielić.
- zarządzanie stanem aplikacji, ponieważ jest ono utrwalane tylko w przeglądarce.
- Rejestrowanie - czym jest rejestrowanie w chmurze?
Mieszaj i dopasowuj - czekaj, co?
Czy możliwe jest uzyskanie tego, co najlepsze z obu światów? Tak, a dzięki temu zarządzanie wyzwaniami każdego z nich może stać się łatwiejsze. Istnieje możliwość posiadania w projekcie mieszanki Server-side i WebAssembly. Byłyby to dwa oddzielne procesy, działające niezależnie, ale mogące ze sobą rozmawiać. Czy WASM i SignalR mogą być dostępne dla tej samej strony lub dokumentu? Nie, jeszcze nie, patrząc na mapę drogową Blazor 2022, może to nastąpić wkrótce!
Mieszanie sprawi, że cała struktura będzie bardziej złożona, ale czy są z tego jakieś korzyści? Po pierwsze, wykorzystanie różnych alokacji pamięci. Blazor Server-side będzie utrzymywać wszystkie aktywne gniazda i sesje na serwerze. W WASM całe obciążenie pamięci jest przejmowane przez przeglądarkę użytkownika. Jeśli masz złożoną logikę biznesową do wykonania po załadowaniu strony, może to być odpowiedzialność części aplikacji hostowanej na serwerze, podczas gdy WebAssembly po prostu utrzymuje stan aplikacji. Obie strony utrzymują swoje wrażliwe dane zabezpieczone i niedostępne, dopóki nie zezwoli się inaczej. Tak więc, jeśli część aplikacji przeznaczona dla użytkownika jest lekka, można ją zbudować jako Blazor Client-side, poprawiając szybkość reakcji i zmniejszając koszty hostingu. Blazor po stronie serwera byłby wtedy odpowiedzialny za dostarczanie większych fragmentów aplikacji, gdy są one wymagane.
Biorąc to pod uwagę, powiedziałbym, że korzyści płynące z miksowania są czasami warte zwiększonej złożoności.
Tak wiele opcji, czy mam dokonać wyboru?
Jak już wspomniałem w poprzednim artykule, dokonanie wyboru zawsze sprowadza się do konkretnego wyzwania i punktu widzenia. Teraz, gdy znasz już większość zalet, wad i wyzwań związanych z każdą opcją hostingu, podjęcie decyzji powinno być łatwiejsze.
W przypadku małych projektów należy zachować prostotę. Nie ma potrzeby przesadzać, gdy tani serwer może obsłużyć całe obciążenie aplikacji lub gdy w aplikacji WebAssembly nie dzieje się nic wrażliwego. Zachowaj złożoność rozwiązania Mixed dla złożonych rozwiązań portalowych, które niosą ze sobą wszystkie wyzwania związane ze skalowalnością, responsywnością i bezpieczeństwem.
Niezależnie od tego, co wybierzesz, a zwłaszcza jeśli nie masz pewności, co będzie najlepszą opcją w przyszłości, oto ostatnia rada: hermetyzuj swoje komponenty w jak największym stopniu w niezależnej bibliotece. W ten sposób, jeśli kiedykolwiek zdecydujesz się przejść na rozwiązanie po stronie serwera lub klienta, a nawet nowy typ aplikacji Blazor, który może pojawić się w przyszłości, przejście będzie znacznie łatwiejsze i sprowadzi się do prostego dostosowania plików startowych i konfiguracji.
Zakończenie
Zanim tu dotarłeś, prawdopodobnie zdałeś sobie sprawę, że wiele pytań zostało opublikowanych, ale pozostało bez odpowiedzi. Słowo kluczowe - Jeopardy! Każde pytanie jest jednocześnie odpowiedzią na poprzedni problem. Jest to również zaproszenie do zapoznania się z tematami Blazora. Być może nawet wygooglowałeś przynajmniej jeden z nich podczas czytania. Każde pytanie będzie działać jako fraza kluczowa w wybranej wyszukiwarce. Próba "zabawy" podjęta przez dewelopera.
Następne - wzorce architektoniczne! Przeanalizujemy najczęstsze wzorce architektoniczne i ich zastosowanie w projektach Blazor. Przyjrzymy się również specyficznym wzorcom Blazor, takim jak BAMStack.
Do zobaczenia!
Więcej z serii Blazor
Część 1 Cześć, tu Blazor. Microsoft Blazor. Poznaliśmy się?
Część 2 .NET, aplikacje internetowe, chmura, IoT - od czego zacząć i dlaczego odpowiedzią jest Blazor?
Część 3 Blazor - jeden, aby rządzić nimi wszystkimi. A może jednak?
P: O czym powinienem pamiętać podczas pracy nad projektem Blazor WebAssembly?
Należy pamiętać, że aplikacja zostanie pobrana na urządzenie użytkownika, początkowy rozmiar pobierania może być duży, ograniczona kontrola nad środowiskiem i zapewnienie kompatybilności ze starszymi przeglądarkami oraz świadomość zwiększonego zużycia zasobów na urządzeniu użytkownika.
P: Czy mogę użyć mieszanki Blazor Server i Blazor WebAssembly w moim projekcie?
Tak, możliwe jest użycie mieszanki Blazor Server i Blazor WebAssembly w projekcie, w zależności od konkretnych wymagań i potrzeb projektu.
P: Serwer i Blazor WebAssembly?
Wybór pomiędzy Blazor Server i Blazor WebAssembly zależy od konkretnych wymagań i potrzeb projektu. Przy podejmowaniu decyzji należy wziąć pod uwagę takie czynniki jak skalowalność, obsługa trybu offline, początkowy rozmiar pobierania i kontrola nad środowiskiem.
