Guia prático de decisão do Blazor
Blazor: Servidor, WebAssembly ou Híbrido?
Blazor é útil quando você sabe qual trabalho permanece no servidor, qual trabalho é movido para o navegador e quais URLs devem existir como links HTML reais.
Este guia ignora a versão do folheto. Ele se concentra nas vantagens e desvantagens que geralmente surpreendem as equipes mais tarde: memória do servidor, conexões ativas, latência, tamanho da carga útil, SEO e roteamento multilíngue.
Antes da escolha do modo de renderização
O que Blazor realmente é
Blazor é a estrutura de componentes da Microsoft para aplicativos da web .NET. Você cria a UI a partir de componentes do Razor, escreve a maior parte da lógica de interação em C# e permite que o ASP.NET Core renderize esses componentes no servidor, no WebAssembly ou dentro de um shell de aplicativo nativo.
Ele surgiu de ideias mais antigas do ASP.NET. Web Forms tentou ocultar a web atrás de controles de servidor. MVC e Razor Pages tornaram o HTML de solicitação-resposta mais limpo. O Blazor adiciona componentes interativos reutilizáveis, mas não torna as páginas MVC ou Razor obsoletas para páginas e formulários de conteúdo simples.
Web Forms, MVC e Razor Pages resolveram problemas diferentes
O Web Forms era produtivo, mas pesado e com estado. MVC e Razor Pages forneceram HTML mais limpo e manipulação de solicitações mais simples. Eles ainda são bons quando uma página lê principalmente dados, publica um formulário e retorna HTML.
Os componentes mantêm a lógica da UI próxima à marcação
Um componente Razor pode conter marcação, parâmetros, eventos, validação, serviços injetados e estado local. Isso é útil para painéis, editores, assistentes, grades e ferramentas onde a página muda sem recarregar completamente.
O .NET moderno permite misturar modos de renderização
Os aplicativos Blazor mais recentes podem combinar HTML estático renderizado em servidor com componentes interativos. Isso é importante porque uma página pode precisar de conteúdo rastreável, enquanto outra parte precisa de um componente ativo.
Sumário
Comece aqui
A versão curta útil
Blazor não é uma arquitetura. É um modelo de componente com vários modos de renderização. A escolha certa depende menos da sintaxe e mais de onde residem o estado, a latência, a memória e os links rastreáveis.
Blazor Server tem estado
Pode parecer rápido no primeiro carregamento, mas o servidor mantém os circuitos ativos. Planeje a memória, reconecte o comportamento e aumente a escala antes que o tráfego aumente.
WebAssembly paga adiantado
Ele remove os circuitos do servidor ativo, mas a primeira visita baixa o tempo de execução e o aplicativo. Cache, corte e pré-renderização são importantes.
Híbrido é uma decisão de produto
Use o Hybrid quando o aplicativo realmente precisar de um desktop ou shell móvel. Para conteúdo público, use renderização web e URLs reais.
Blazor Server
Blazor Server mantém o trabalho ativo entre cliques
Blazor Server não é uma página normal de solicitação-resposta sem estado. Uma guia do navegador conectada obtém um circuito. O servidor mantém o estado do componente e os serviços com escopo definido para esse circuito enquanto o usuário está conectado e, muitas vezes, por uma breve janela de reconexão após uma desconexão.
A memória cresce com circuitos ativos
Cada guia conectada possui um circuito. O estado do componente, os serviços com escopo definido, o estado de validação e o trabalho pendente da UI podem permanecer na memória até o circuito terminar. Os testes de carga devem contar usuários ativos, não apenas solicitações por segundo.
A latência se torna parte da IU
Um clique de botão, um evento de entrada ou uma interação de grade pode ir e voltar do servidor. Hospede perto dos usuários e evite componentes tagarelas quando o público estiver espalhado por regiões.
A expansão precisa de um plano
Várias instâncias de aplicativos geralmente precisam de sessões fixas, um backplane SignalR, serviço Azure SignalR ou design de estado cuidadoso. Caso contrário, as reconexões e os circuitos ativos poderão pousar na instância errada.
Bom ajuste: usuários controlados
O Blazor Server é mais forte para ferramentas autenticadas, telas de administração, painéis e aplicativos internos onde os usuários, a latência e a capacidade de hospedagem são conhecidos.
Blazor WebAssembly
WebAssembly move o custo para o primeiro carregamento
Blazor WebAssembly remove circuitos de servidor, mas não remove custos. O navegador deve baixar o tempo de execução do .NET, os assemblies, os recursos de localização e os ativos do aplicativo antes que a experiência pareça rápida. Visitas repetidas podem ser boas porque o cache ajuda. As primeiras visitas precisam de cuidados.
A primeira carga é o imposto
O navegador baixa o tempo de execução do .NET, assemblies de aplicativos, recursos e ativos estáticos. Aparar ajuda. A compilação antecipada pode melhorar o trabalho pesado da CPU, mas geralmente aumenta o tamanho do download.
Os segredos não podem residir no cliente
Um aplicativo WebAssembly é executado no navegador do usuário. Trate-o como qualquer frontend público: mantenha segredos no servidor, proteja APIs e presuma que o código do cliente pode ser inspecionado.
SEO precisa de conteúdo renderizado
Para artigos públicos, páginas de produtos e páginas iniciais, não confie em um shell em branco que se tornará útil somente após o início do WebAssembly. Use renderização no lado do servidor, pré-renderização, renderização estática ou um caminho de conteúdo separado.
Bom ajuste: aplicativos off-line ou com muitos clientes
O WebAssembly funciona bem quando os usuários retornam com frequência, precisam de comportamento offline ou realizam trabalho pesado no lado do cliente, onde uma viagem de ida e volta ao servidor seria pior.
Híbrido e WebView
Híbrido é para aplicativos, não para páginas de destino públicas
Blazor Hybrid é útil quando uma equipe .NET deseja reutilizar componentes dentro de um desktop ou aplicativo móvel. Ele é executado em um shell nativo por meio de um WebView, para que possa estar próximo de arquivos locais, APIs de dispositivos e implantação corporativa. Não é um atalho para sites focados em SEO.
- Use o Híbrido quando precisar de acesso a arquivos locais, APIs de dispositivos, implantação de desktop ou empacotamento móvel.
- Não escolha Híbrido apenas para reutilizar componentes da web. O shell nativo adiciona trabalho de atualização, armazenamento, assinatura e suporte.
- Para SEO e URLs públicos compartilháveis, o híbrido geralmente é a superfície errada.
Roteamento multilíngue
Links conscientes da cultura devem ser links reais
Um site Blazor multilíngue não deve construir navegação de idioma apenas em manipuladores de cliques ou JavaScript depois que a página se tornar interativa. Os mecanismos de pesquisa e os usuários precisam de tags âncora reais no HTML inicial, com valores href estáveis, URLs canônicos e dados hreflang.
- Use links de páginas centrais e ajudantes em vez de strings criadas à mão, como barra de cultura barra de caminho.
- Renderize links de idioma como tags âncora com valores href durante a renderização HTML inicial.
- Mantenha URLs canônicos, URLs hreflang e navegação de idioma visível sincronizados.
- Evite ocultar links importantes atrás de manipuladores onclick, JavaScript atrasado ou estado Blazor somente interativo.
Guia de decisão
Escolha pelo gargalo que você aceita
Cada modo de renderização move a pressão para um local diferente. Escolha a pressão que você pode medir, hospedar e explicar à equipe.
Quando o primeiro carregamento e a integração de back-end do .NET são mais importantes
Escolha o Blazor Server para aplicativos autenticados controlados onde a memória do servidor, as conexões em tempo real e a latência regional são custos operacionais aceitáveis.
Quando o trabalho do cliente e o comportamento offline são mais importantes
Escolha WebAssembly quando visitas repetidas, armazenamento em cache, uso offline ou trabalho de CPU local forem mais importantes do que o menor primeiro carregamento.
Quando o produto é realmente um aplicativo nativo
Escolha Híbrido quando o aplicativo pertence ao desktop ou móvel e precisa mais de integração local do que de alcance público na web.
Quando o site é composto principalmente de documentos e formulários
As páginas clássicas do ASP.NET Core MVC ou Razor costumam ser mais simples para sites com muito conteúdo, documentação pública e formulários com interatividade limitada.
Seção de referência
Leia isso a seguir quando você construir isso de verdade
Essas referências são úteis após a decisão de arquitetura, pois abrangem as partes que tornam uma página do Blazor confiável na produção: metadados, links de linguagem, hospedagem e UI reutilizável.
Use isto quando cada página precisar de título, descrição, Open Graph, canônico e saída JSON-LD consistentes.
Links idioma-região amigáveis ao SEOUse isto quando o roteamento multilíngue precisar de links rastreáveis reais, caminhos de cultura estáveis e saída hreflang correta.
Hospede Blazor no UpCloudUse isso quando um aplicativo Blazor Server precisar de um pequeno VPS, Nginx, TLS, systemd, logs, backups e implantações repetíveis.
TablerForNetUse isto quando o valor for uma interface administrativa, tabelas de dados, formulários e telas de painel em vez de uma página de marketing.
BlazorUse o hub Blazor quando quiser os guias relacionados em um só lugar antes de escolher o próximo detalhe de implementação.
Perguntas frequentes
Por que o Blazor Server pode precisar de mais memória que o MVC?
MVC pode finalizar uma solicitação e liberar a maioria dos estados da solicitação. O Blazor Server mantém um circuito para cada guia do navegador conectada, para que o estado do componente e os serviços com escopo possam permanecer ativos entre os cliques.
Posso executar o Blazor Server em várias instâncias de aplicativos?
Sim, mas planeje deliberadamente. Circuitos ativos e conexões SignalR precisam de roteamento estável, um backplane ou serviço SignalR gerenciado e um estado de aplicativo que sobreviva às reconexões corretamente.
O Blazor WebAssembly pode ser compatível com SEO?
Sim, mas não enviando um shell vazio e esperando que o rastreador espere. As páginas públicas precisam de HTML renderizado, metadados, links canônicos e dados estruturados antes ou durante a primeira resposta.
Como os links multilíngues do Blazor devem ser construídos?
Use definições de rota central e renderize tags de âncora reais para cada cultura. Mantenha links visíveis, URLs canônicos e dados hreflang alinhados para que usuários e rastreadores vejam a mesma estrutura de linguagem.