Interatividade Blazor

Blazor permite que você envie um portal em um dos três modos de interatividade — Servidor, WebAssembly ou Auto. O modo escolhe como os componentes interativos rodam (por uma conexão SignalR no servidor, como compilado em .NET no navegador, ou ambos) e decide o que é gerado no layout do seu projeto. Power Portals Pro roda corretamente em todos os três; As diferenças estão na forma de implantação e na fiação do projeto, não nas características do framework.

Os Três Modos

Servidor

Componentes interativos são executados no servidor. Cada usuário conectado mantém uma conexão SignalR aberta de volta ao host, e cada evento da interface faz ida e volta ao servidor.

• Menor download de cliente. O navegador recebe HTML simples e um pequeno carregador SignalR — nenhum runtime .NET é enviado ao cliente.
• Capacidades completas do servidor. Os componentes injetam qualquer serviço do lado do servidor diretamente (cliente Dataverse, configuração, sistema de arquivos) sem passar por HTTP.
• Implantação mais simples. Um ASP.NET host Core, sem um pacote separado do WebAssembly para publicar.

Concessões:

• Hospedeiro imponente. O circuito de cada usuário é fixado a uma única instância de servidor; Escalabilidade horizontal exige sessões fixas, e um reinício do host cai em toda sessão ativa.
• A latência da interface segue a latência da rede. Cada clique, tecla e rolagem de ida e volta ao servidor, então usuários em links de alta latência sentem o app lento.

WebAssembly

Componentes interativos rodam no navegador como código compilado .NET. O trabalho do servidor se reduz a servir arquivos estáticos e os endpoints da API HTTP do framework sob /api/auth/* e /api/*.

• Servidor sem estado. O host escala horizontalmente sem sessões fixas, reinicios não causam interrupção visível e o custo de memória por usuário no servidor é quase zero.
• Interface rápida. A maior parte da interação fica dentro do navegador — sem SignalR de ida e volta por clique — então o app parece instantâneo assim que o pacote é carregado.
• Com capacidade offline. Um portal carregado continua renderizando e validando contra dados em cache mesmo quando a rede cai, sincronizando de volta com a API quando retorna.

Concessões:

• Download inicial. O runtime .NET, os assemblies do framework e o código do seu portal são enviados para o navegador na primeira carga (comprimidos, geralmente alguns MB). As visitas subsequentes são carregadas do cache do navegador.
• É necessária superfície de API. Tudo que a interface precisa do servidor precisa ser exposto como um endpoint HTTP. O Power Portals Pro fornece os dados e endpoints de autenticação logo de cara; a lógica de servidor personalizada precisa de seus próprios controladores ou endpoints de API mínima.
• Desempenho do lado do navegador. Trabalhos pesados em CPU (grandes grades, cálculos gráficos complexos) rodam na velocidade do WebAssembly, que é rápida, mas mais lenta que a .NET nativa do lado do servidor.

Auto

A primeira pintura vem do servidor (para que o usuário veja o conteúdo imediatamente) e o runtime muda transparentemente para o WebAssembly assim que o pacote cliente termina de baixar. Auto = Servidor primeiro, WebAssembly depois, nas mesmas rotas.

• Melhor carga percebida + melhor experiência de usuário em regime estacionário. Os usuários recebem uma primeira pintura instantânea sem esperar pelo pacote WASM, e depois aproveitam as interações rápidas do WebAssembly assim que o tempo de execução é armazenado em cache no navegador.
• Implantação única. Um host, uma etapa de publicação — igual ao WebAssembly, com o runtime do servidor acompanhado para o pré-render.

Concessões:

• Layout de projeto mais complexo. Ambos os tempos de execução precisam ser conectados por cabos; Os componentes devem funcionar corretamente em qualquer um dos renderizadores (sem serviços exclusivos para servidor injetados em componentes compartilhados).
• Breve janela renderizada pelo servidor. Na primeira visita, a página renderiza do lado do servidor até a troca do WASM ser concluída — o template do Power Portals Pro esconde essa transição com uma sobreposição de carregamento para que os usuários não vejam o estado intermediário.

Dica

Este site de documentação roda no modo Auto. Abra a aba de rede das ferramentas de desenvolvimento do navegador na primeira carga e você verá o HTML renderizado pelo servidor chegar primeiro, depois o fluxo do pacote WASM em um ou dois segundos — após o que as navegações param de acessar o servidor para HTML.

Qual escolher

Regras básicas quando não há uma restrição específica que força uma escolha:

• Escolha o servidor se o portal tiver poucos usuários concorrentes, estiver dentro de uma rede corporativa com conexões estáveis, ou se sua equipe for nova em Blazor e quiser o modelo mental mais simples.
• Escolha WebAssembly se o portal for voltado para clientes com alta concorrência, se sua fatura de hospedagem escalar com sessões ativas, ou se você precisar de comportamento offline. Aceite o custo inicial de download como uma visita única por visitante.
• Escolha Auto se quiser o WebAssembly em estado estável sem pagar a latência da primeira pintura para baixar o pacote. A maioria dos portais de produção acaba aqui.

Guia de Dicas

O que muda entre os três modos, arquivo por arquivo. Use isso como referência ao comparar um projeto gerado com um dos templates, ou ao buscar uma discrepância após uma troca manual.

Layout do Projeto

Os três modos geram um projeto host de servidor E um projeto irmão .Client . O que difere é o .ClientSDK de 's e se ele realmente foi compilado para um bundle WebAssembly.

• Server — .Client usa Microsoft.NET.Sdk.Razor; é uma biblioteca de classes que armazena componentes compartilhados, mas não é publicada como WASM.
• WebAssembly — .Client usa Microsoft.NET.Sdk.BlazorWebAssembly com seu próprio Program.cs, compilado em um pacote para download.
• Auto — igual ao WebAssembly: Microsoft.NET.Sdk.BlazorWebAssembly com seu próprio Program.cs.

.csproj Diferenças

O .Client SDK do projeto muda, e os pacotes de framework específicos do WebAssembly só aparecem quando o host realmente executa o WASM:

Referências adicionais de pacotes quando o WebAssembly ou Auto está ativo:

Server Program.cs — Registro de Serviços

AddRazorComponents() Seleciona os pares de componentes apropriados do modo de renderização com base nos métodos do construtor que estão encadeados:

Server Program.cs — Mapeamento de Endpoints

MapRazorComponents<App>() encadeia os endpoints correspondentes do modo de renderização:

App.razor — Política de Renderização por Rota

O PageRenderMode getter em App.razor decide qual renderizador cada rota usa. Os hosts de servidor retornam servidor em todos os lugares; Hosts WebAssembly e Auto precisam fixar explicitamente as /Account/* rotas para que o WASM apenas IAuthService resolva:

Por que /Conta/* está fixada

A primeira pintura do Auto roda no renderizador do servidor, mas as páginas IAuthService da conta só são registradas no gráfico DI do cliente WASM. Sem o pin explícito em InteractiveWebAssemblyRenderMode(prerender: false), um host automático falha em resolver [Inject] IAuthService na pré-renderização da sessão fria. prerender: false pula completamente a etapa de pré-renderização do lado do servidor, então a página renderiza apenas uma vez, no runtime WASM.

. Cliente/Program.cs — Somente quando interativo

Hosts apenas de servidor não têm .Client/Program.cs nenhum (é .Client uma biblioteca de classes Razor). Os hosts WebAssembly e Auto incluem este arquivo, que configura o runtime do WASM, registra o HttpClient encaminhamento com credenciais de cookies, registra os serviços clientes WASM do Power Portals Pro e faz pré-busca para a localização transversal no início:

Páginas de Identidade / Conta

Power Portals Pro vem com dois conjuntos paralelos de páginas de Conta — um para cada contexto de renderização. Qual conjunto está no seu projeto depende do modo do host:

• Server — páginas Razor renderizadas pelo servidor sob Components/Account/Pages/ uso UserManager direto. Endpoints de post-formulário registrados via app.MapAdditionalIdentityEndpoints().
• WebAssembly / Auto — páginas interativas usando .Client/Pages/Account/ o wrapper do IAuthService framework. Endpoints JSON registrados via app.MapAuthEndpoints<PortalUser>() login de handle, registração, gerenciamento/* e conclusão de login externo como application/json chamadas.

Próximos Passos

Se você já tem um projeto em um modo e quer converter para outro, veja a página Switch Blazor Interactivity para as alterações arquivo a arquivo.