--- title: "Blazor w .NET 10: renderowanie, stan i AI" url: "https://majchrzycki.com/blog/microsoft-blazor-intelligent-web-apps" description: "Jak dobrać tryb renderowania Blazor w .NET 10, hosting, zarządzanie stanem i bezpieczną integrację aplikacji z AI." --- # Blazor w .NET 10: renderowanie, stan i AI 14 kwietnia 2024· Aktualizacja: 27 września 2026·6 min czytania·Krzysztof Majchrzycki Temat: [AI SDLC](https://majchrzycki.com/blog/filar/ai-sdlc) 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](https://learn.microsoft.com/en-us/aspnet/core/blazor/components/render-modes?view=aspnetcore-10.0) 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](https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management/?view=aspnetcore-10.0) 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](https://devblogs.microsoft.com/dotnet/announcing-dotnet-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](https://majchrzycki.com/system). 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](https://majchrzycki.com/blog/microsoft-orleans-scalable-distributed-applications). 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”. - Agenci AI - Zarządzanie zmianą - Strategia ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Microsoft Orleans 10: kiedy wybrać virtual actors](https://majchrzycki.com/blog/microsoft-orleans-scalable-distributed-applications) - [Aspire: AppHost, service discovery i dashboard](https://majchrzycki.com/blog/microsoft-dot-net-aspire-cloud-native) - [.NET 10 dla aplikacji AI: warstwy i wybór](https://majchrzycki.com/blog/microsoft-dot-net-ai-apps) - [Python w aplikacjach AI: architektura i test](https://majchrzycki.com/blog/python-ai-apps)