Blazor w .NET 10: renderowanie, stan i AI

Blazor w .NET 10 pozwala budować interfejs webowy w C#, ale wybór technologii nie kończy się na pytaniu „czy zespół zna .NET”. Trzeba osobno rozstrzygnąć miejsce renderowania, granicę interaktywności, sposób przechowywania stanu, odporność połączenia oraz integrację z usługami AI. Najbezpieczniejszy projekt zaczyna się od tabeli decyzji i małego prototypu, a nie od ustawienia jednego trybu dla całej aplikacji.

Blazor w .NET 10: jedna technologia, kilka modeli wykonania

Dokumentacja trybów renderowania Blazor rozróżnia renderowanie statyczne po stronie serwera oraz trzy tryby interaktywne: Interactive Server, Interactive WebAssembly i Interactive Auto. Tryb można ustalić dla komponentu albo obszaru aplikacji. Ta elastyczność jest zaletą, ale łatwo prowadzi do projektu, w którym granice wykonania są nieczytelne.

Static SSR generuje HTML na serwerze bez interaktywnego środowiska Blazor po dostarczeniu strony. Interactive Server obsługuje zdarzenia na serwerze przez obwód połączenia z przeglądarką. Interactive WebAssembly uruchamia kod .NET w przeglądarce po pobraniu aplikacji. Interactive Auto początkowo korzysta z serwera, a po pobraniu pakietu może używać WebAssembly przy kolejnych wizytach. Nie wybieraj trybu według hasła „najszybszy”. Szybkość początkowa, koszt serwera, praca offline, rozmiar pobrania i dostęp do zasobów serwerowych tworzą różne kompromisy.

Tryb	Gdzie działa interakcja	Mocna strona	Główne ograniczenie
Static SSR	Brak stałej interakcji Blazor	Prosty HTML, mały koszt klienta	Zdarzenia wymagają nawigacji lub innego mechanizmu
Interactive Server	Serwer	Mały pakiet klienta, bezpośredni dostęp do usług serwera	Zależność od połączenia i zasobów dla obwodów
Interactive WebAssembly	Przeglądarka	Interakcja po stronie klienta i mniejsza zależność od obwodu	Pobranie runtime oraz ograniczony dostęp do zasobów serwera
Interactive Auto	Serwer, potem klient	Stopniowe przejście do WebAssembly	Dwa modele wykonania do testowania i utrzymania

Dobieraj tryb na granicy funkcji. Strona informacyjna może pozostać statyczna. Formularz wymagający natychmiastowej walidacji może być interaktywny. Panel pracujący na wrażliwych danych może pozostać po stronie serwera, o ile zespół zaplanuje połączenia, skalowanie i odtwarzanie stanu. Nie zakładaj, że każda interakcja wymaga WebAssembly ani że Interactive Server jest bezstanowym HTTP.

Stan ma właściciela i okres życia

Przegląd zarządzania stanem Blazor opisuje między innymi stan w adresie URL, kontenery stanu w pamięci oraz przekazywanie danych między komponentami. .NET 10 rozszerzył mechanizmy utrwalania podczas prerenderingu. Ogłoszenie .NET 10 wskazuje deklaratywny atrybut PersistentState oraz utrwalanie stanu obwodów jako ważne zmiany Blazor.

Nie oznacza to, że stan aplikacji należy przechowywać w komponencie. Najpierw sklasyfikuj dane. Stan widoku, taki jak wybrana karta, może żyć krótko. Parametr nawigacji powinien znaleźć się w URL, jeśli użytkownik ma móc udostępnić lub odtworzyć widok. Koszyk, sprawa klienta albo wynik procesu wymagają trwałego źródła poza pamięcią komponentu. Dane wrażliwe nie powinny trafiać do przeglądarki tylko dlatego, że komponent korzysta z WebAssembly.

Rodzaj stanu	Przykład	Zalecane źródło prawdy	Pytanie kontrolne
Nawigacyjny	Filtr, identyfikator widoku	URL	Czy odświeżenie ma zachować kontekst?
Prezentacyjny	Otwarta sekcja	Pamięć komponentu lub klienta	Czy utrata stanu powoduje szkodę?
Sesyjny	Niedokończony formularz	Kontrolowany magazyn sesji lub trwały szkic	Jak długo i dla kogo dane są ważne?
Biznesowy	Zamówienie, decyzja, uprawnienie	Backend i baza danych	Kto zatwierdza zmianę i prowadzi audyt?
Wynik AI	Szkic odpowiedzi, cytowania	Backend wraz z kontekstem ewaluacji	Czy można odtworzyć model, źródła i decyzję?

Prerendering może wykonać logikę przed uruchomieniem interaktywności, dlatego trzeba uważać na podwójne pobieranie danych i różnice między środowiskiem serwera a klienta. Stan utrwalony między fazami powinien mieć jasny zakres. Nie przenoś sekretów, tokenów ani danych dostępnych wyłącznie serwerowi do payloadu klienta.

Hosting i niezawodność wynikają z trybu

Interactive Server wymaga planu dla obwodów. Użytkownik może stracić sieć, proces serwera może zostać zrestartowany, a instancja może zniknąć podczas skalowania. .NET 10 poprawia odporność obwodów, ale nie usuwa odpowiedzialności za architekturę. Określ zachowanie przy rozłączeniu, limit czasu, sposób zachowania pracy oraz konsekwencje ponownego wykonania działania.

Interactive WebAssembly przenosi część kosztu do klienta. Sprawdź rozmiar pierwszego pobrania, wydajność na słabszym urządzeniu, politykę cache i zgodność używanych bibliotek z WebAssembly. Kod klienta jest dostępny użytkownikowi, więc nie umieszczaj w nim sekretów. Każda operacja biznesowa nadal musi przejść autoryzację w API.

Static SSR dobrze pasuje do treści i przepływów opartych na formularzach. Nie jest „gorszym Blazorem”. Mniejsza interaktywność może zmniejszyć liczbę stanów awarii, koszt hostingu i ilość kodu wysyłanego do przeglądarki. Projekt mieszany często jest rozsądniejszy od globalnej deklaracji jednego trybu.

Integracja AI: interfejs nie może ukrywać niepewności

Komponent Blazor powinien wywoływać własną warstwę backendową, a nie bezpośrednio udostępniać klucz do usługi modelowej. Backend egzekwuje tożsamość, limity, politykę danych, filtrowanie narzędzi i zapis obserwowalności. Strumieniowanie odpowiedzi poprawia odczuwalną szybkość, lecz częściowy tekst nie jest ukończonym wynikiem. Interfejs musi pokazać stan generowania, możliwość przerwania, źródła i błąd.

Warstwa	Odpowiedzialność	Kontrola przed produkcją
Komponent Blazor	Zbiera cel i prezentuje wynik	Dostępność, anulowanie, stany błędu
API aplikacji	Autoryzuje i minimalizuje dane	Test dostępu do każdego zasobu
Orkiestracja AI	Buduje kontekst i wywołuje model lub narzędzia	Lista dozwolonych źródeł i operacji
Model	Generuje propozycję	Ewaluacja jakości i scenariusze nadużyć
Człowiek	Zatwierdza działanie wysokiego ryzyka	Widoczne źródła, zmiany i konsekwencje

Przykład syntetyczny. Aplikacja przygotowuje projekt odpowiedzi na zgłoszenie. Komponent wysyła identyfikator sprawy, nie całą historię przeglądarki. Backend pobiera tylko dane dostępne użytkownikowi, buduje kontekst i zwraca szkic wraz z cytowaniami. Użytkownik może edytować tekst, ale wysłanie wymaga osobnej operacji i ponownej autoryzacji. Szkic AI nigdy nie jest traktowany jako zatwierdzona odpowiedź.

Prototyp rozstrzyga więcej niż dyskusja o trybach

Zbuduj cienki przekrój jednej funkcji w dwóch wariantach. Zmierz czas pierwszego użycia, liczbę połączeń, pamięć serwera, wielkość pobrania oraz zachowanie po utracie sieci. Przetestuj odświeżenie strony w połowie formularza i wdrożenie nowej wersji przy aktywnych użytkownikach. Dla AI dodaj anulowanie odpowiedzi, limit czasu, brak cytowania i odmowę narzędzia.

Test	Co symulujesz	Warunek akceptacji
Pierwsze wejście	Pusta pamięć podręczna i wolniejsze łącze	Użytkownik widzi użyteczny stan bez błędu
Rozłączenie	Utrata sieci podczas edycji	Brak cichej utraty zatwierdzonych danych
Skalowanie	Restart lub zmiana instancji	Operacja jest odtwarzalna albo bezpiecznie przerwana
Autoryzacja	Użytkownik bez prawa do rekordu	Backend odmawia niezależnie od UI
Odpowiedź AI	Brak źródła lub timeout	UI pokazuje ograniczenie, nie fałszywy sukces

W .NET 10 ASP.NET Core dodaje wbudowane metryki między innymi dla Blazor, a śledzenie Interactive Server jest bogatsze. Włącz obserwowalność przed testem obciążenia. Sama średnia czasu odpowiedzi nie pokaże zerwanych obwodów, błędów odtwarzania stanu ani kosztu długich strumieni AI.

Granice wyboru Blazor

Blazor jest naturalnym wyborem, gdy zespół chce współdzielić język, modele i kompetencje .NET, a wymagania interfejsu mieszczą się w dostępnych komponentach oraz modelach renderowania. Nie wybieraj go wyłącznie po to, aby uniknąć JavaScript. Integracje przeglądarkowe nadal mogą wymagać JavaScript interop, a ich cykl życia trzeba rozumieć.

Jeśli aplikacja potrzebuje intensywnej pracy offline, bardzo małego początkowego pakietu i złożonej integracji z ekosystemem front end, wykonaj porównawczy prototyp. Jeśli wymaga tysięcy aktywnych obwodów Interactive Server, zmierz rzeczywisty profil pamięci i komunikacji. Jeśli dane biznesowe mają długi cykl życia, zaprojektuj backend niezależnie od komponentów.

Bezpieczeństwo zaczyna się poza komponentem

Ukrycie przycisku nie jest autoryzacją. Użytkownik może wysłać żądanie do API bez użycia interfejsu, dlatego backend sprawdza tożsamość, tenant, uprawnienie do rekordu i dozwoloną operację. Dotyczy to każdego trybu renderowania. Interactive Server wykonuje kod komponentu na serwerze, ale zdarzenie użytkownika nadal nie jest dowodem prawa do zmiany. WebAssembly działa w przeglądarce, więc cały dostarczony kod i konfigurację traktuj jako dostępne klientowi.

Przy integracji AI kontroluj również prompt injection w dokumentach i odpowiedziach z narzędzi. Treść pobrana z pliku nie staje się instrukcją systemową. Orkiestrator powinien oddzielać dane od poleceń, ograniczać listę narzędzi i ponownie autoryzować każdą operację ze skutkiem. Interfejs pokazuje użytkownikowi, kiedy wynik pochodzi z modelu, jakie źródła wykorzystano i które działanie wymaga potwierdzenia.

Walidacja po stronie klienta poprawia doświadczenie, lecz backend powtarza ją dla danych biznesowych. Błąd walidacji, brak dostępu i konflikt wersji to różne stany. Nie pokazuj ich jako jednego komunikatu „coś poszło nie tak”, bo operator nie odróżni błędu użytkownika od incydentu systemowego.

Plan decyzji i migracji

Nie musisz rozstrzygać całej aplikacji w jednym projekcie. Spisz decyzję architektoniczną dla każdej grupy stron: tryb renderowania, właściciel stanu, kontrakt API, wymagania offline i plan obserwowalności. Dodaj powód oraz sygnał ponownego przeglądu, na przykład wzrost liczby aktywnych obwodów albo wymaganie pracy bez sieci.

Pytanie decyzyjne	Pomiar lub dowód	Sygnał zmiany architektury
Czy potrzebna jest interaktywność?	Zadania użytkownika i prototyp	Statyczny formularz pokrywa przypadek
Czy stan może zniknąć?	Analiza skutku odświeżenia i restartu	Utrata wpływa na proces biznesowy
Czy kod może działać u klienta?	Klasyfikacja danych i zależności	Potrzebne sekrety lub biblioteka serwerowa
Czy serwer utrzyma obwody?	Test pamięci, połączeń i reconnect	Koszt lub awaryjność przekracza budżet
Czy AI ma wykonać działanie?	Model zagrożeń i macierz uprawnień	Brak jawnej akceptacji człowieka

Przy migracji ze starszej aplikacji Blazor nie zmieniaj jednocześnie hostingu, modelu stanu, uwierzytelniania i warstwy AI. Zacznij od jednej pionowej funkcji. Zachowaj istniejący kontrakt backendu, wprowadź nowy komponent, uruchom testy bezpieczeństwa i obserwowalności, a dopiero potem rozszerz wzorzec. Dzięki temu wiadomo, która zmiana poprawiła lub pogorszyła wynik.

Warstwa webowa jest tylko jednym elementem systemu działania firmy. Gdy aplikacja ma wiele stanowych jednostek biznesowych, długie procesy i niezależne klucze skalowania, kolejnym krokiem jest ocena modelu virtual actor w Microsoft Orleans.

W poniedziałek wybierz jedną funkcję z formularzem, stanem biznesowym i wywołaniem backendu. Rozpisz jej wykonanie dla Static SSR, Interactive Server i Interactive WebAssembly. Odrzuć warianty, które naruszają granicę danych. Dwa pozostałe uruchom jako cienki prototyp i przetestuj rozłączenie. Wynik pomiaru jest lepszą podstawą decyzji niż ogólna obietnica „jednego C# wszędzie”.