Escolha entre aplicativos Web tradicionais e aplicativos de página única (SPAs)
Gorjeta
Este conteúdo é um excerto do eBook, Architect Modern Web Applications with ASP.NET Core e Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
"Lei de Atwood: Qualquer aplicação que possa ser escrita em JavaScript, acabará por ser escrita em JavaScript."
- Joaquim Barbosa
Existem duas abordagens gerais para a criação de aplicativos Web atualmente: aplicativos Web tradicionais que executam a maior parte da lógica do aplicativo no servidor e aplicativos de página única (SPAs) que executam a maior parte da lógica da interface do usuário em um navegador da Web, comunicando-se com o servidor da Web principalmente usando APIs da Web. Uma abordagem híbrida também é possível, sendo a mais simples hospedar um ou mais subaplicativos ricos semelhantes a SPA dentro de um aplicativo Web tradicional maior.
Use aplicativos Web tradicionais quando:
Os requisitos do lado do cliente do seu aplicativo são simples ou até mesmo somente leitura.
Seu aplicativo precisa funcionar em navegadores sem suporte a JavaScript.
Seu aplicativo é voltado para o público e se beneficia da descoberta e das referências do mecanismo de pesquisa.
Use um SPA quando:
Seu aplicativo deve expor uma interface de usuário rica com muitos recursos.
Sua equipe está familiarizada com JavaScript, TypeScript ou BlazorWebAssembly desenvolvimento.
Seu aplicativo já deve expor uma API para outros clientes (internos ou públicos).
Além disso, as estruturas de SPA exigem maior experiência em arquitetura e segurança. Eles experimentam maior rotatividade devido a atualizações frequentes e novas estruturas de cliente do que os aplicativos Web tradicionais. Configurar processos automatizados de compilação e implantação e utilizar opções de implantação como contêineres pode ser mais difícil com aplicativos SPA do que aplicativos Web tradicionais.
As melhorias na experiência do utilizador possibilitadas pela abordagem SPA devem ser ponderadas em relação a estas considerações.
Blazor
ASP.NET Core inclui um modelo para criar interfaces de usuário avançadas, interativas e combináveis chamado Blazor. Blazor O lado do servidor permite que os desenvolvedores criem a interface do usuário com C# e Razor no servidor e que a interface do usuário seja conectada interativamente ao navegador em tempo real usando uma conexão SignalR persistente. BlazorWebAssembly Introduz outra opção para Blazor aplicativos, permitindo que eles sejam executados no navegador usando WebAssemblyo . Como é um código .NET real em execução no WebAssembly, você pode reutilizar código e bibliotecas de partes do lado do servidor do seu aplicativo.
Blazor fornece uma nova terceira opção a ser considerada ao avaliar se deve criar um aplicativo Web puramente renderizado por servidor ou um SPA. Você pode criar comportamentos avançados do lado do cliente semelhantes ao SPA usando Blazoro , sem a necessidade de desenvolvimento JavaScript significativo. Blazor os aplicativos podem chamar APIs para solicitar dados ou executar operações no servidor. Eles podem interoperar com JavaScript quando necessário para tirar proveito das bibliotecas e estruturas JavaScript.
Considere criar seu aplicativo Web quando Blazor :
Seu aplicativo deve expor uma interface de usuário avançada
Sua equipe está mais confortável com o desenvolvimento .NET do que com o desenvolvimento JavaScript ou TypeScript
Se você tiver um aplicativo de formulários da Web existente que está considerando migrar para o .NET Core ou para o .NET mais recente, convém revisar o e-book Blazor gratuito para que os desenvolvedores de Web Forms vejam se faz sentido considerar a migração para o Blazor.
Para obter mais informações sobre Blazoro , consulte Introdução ao Blazor.
Quando escolher aplicações Web tradicionais
A seção a seguir é uma explicação mais detalhada das razões declaradas anteriormente para escolher aplicativos Web tradicionais.
Seu aplicativo tem requisitos simples, possivelmente somente leitura, do lado do cliente
Muitas aplicações web são consumidas principalmente de forma somente leitura pela grande maioria de seus usuários. Aplicativos somente leitura (ou principalmente leitura) tendem a ser muito mais simples do que aqueles aplicativos que mantêm e manipulam uma grande quantidade de estado. Por exemplo, um mecanismo de pesquisa pode consistir em um único ponto de entrada com uma caixa de texto e uma segunda página para exibir os resultados da pesquisa. Usuários anônimos podem facilmente fazer solicitações, e há pouca necessidade de lógica do lado do cliente. Da mesma forma, um blog ou aplicativo de gerenciamento de conteúdo voltado para o público geralmente consiste principalmente em conteúdo com pouco comportamento do lado do cliente. Tais aplicativos são facilmente construídos como aplicativos Web tradicionais baseados em servidor, que executam lógica no servidor Web e renderizam HTML para ser exibido no navegador. O facto de cada página única do site ter o seu próprio URL que pode ser marcado e indexado pelos motores de busca (por defeito, sem ter de adicionar esta funcionalidade como uma característica separada da aplicação) é também um benefício claro em tais cenários.
Seu aplicativo precisa funcionar em navegadores sem suporte a JavaScript
Os aplicativos Web que precisam funcionar em navegadores com suporte limitado ou nenhum JavaScript devem ser escritos usando fluxos de trabalho tradicionais de aplicativos Web (ou pelo menos ser capazes de recorrer a esse comportamento). Os SPAs requerem JavaScript do lado do cliente para funcionar; se não estiver disponível, as ZPE não são uma boa escolha.
Sua equipe não está familiarizada com as técnicas de desenvolvimento JavaScript ou TypeScript
Se sua equipe não estiver familiarizada com JavaScript ou TypeScript, mas estiver familiarizada com o desenvolvimento de aplicativos Web do lado do servidor, provavelmente será capaz de fornecer um aplicativo Web tradicional mais rapidamente do que um SPA. A menos que aprender a programar SPAs seja um objetivo, ou a experiência do usuário proporcionada por um SPA seja necessária, os aplicativos Web tradicionais são uma escolha mais produtiva para equipes que já estão familiarizadas com a criação deles.
Quando escolher SPAs
A seção a seguir é uma explicação mais detalhada de quando escolher um estilo de desenvolvimento de aplicativos de página única para seu aplicativo Web.
Seu aplicativo deve expor uma interface de usuário rica com muitos recursos
Os SPAs podem oferecer suporte a funcionalidades avançadas do lado do cliente que não exigem o recarregamento da página à medida que os usuários realizam ações ou navegam entre áreas do aplicativo. Os SPAs podem carregar mais rapidamente, buscando dados em segundo plano, e as ações individuais do usuário são mais responsivas, já que recarregamentos de página inteira são raros. Os SPAs podem suportar atualizações incrementais, salvando formulários ou documentos parcialmente preenchidos sem que o usuário precise clicar em um botão para enviar um formulário. Os SPAs podem oferecer suporte a comportamentos avançados do lado do cliente, como arrastar e soltar, muito mais prontamente do que os aplicativos tradicionais. Os SPAs podem ser projetados para serem executados em um modo desconectado, fazendo atualizações em um modelo do lado do cliente que são eventualmente sincronizadas de volta ao servidor assim que uma conexão é restabelecida. Escolha um aplicativo no estilo SPA se os requisitos do seu aplicativo incluírem funcionalidades avançadas que vão além do que os formulários HTML típicos oferecem.
Frequentemente, os SPAs precisam implementar recursos incorporados a aplicativos Web tradicionais, como exibir uma URL significativa na barra de endereço refletindo a operação atual (e permitir que os usuários marquem favoritos ou façam links diretos para essa URL para retornar a ela). Os SPAs também devem permitir que os usuários usem os botões de voltar e avançar do navegador com resultados que não os surpreenderão.
Sua equipe está familiarizada com o desenvolvimento de JavaScript e/ou TypeScript
Escrever SPAs requer familiaridade com JavaScript e/ou TypeScript e técnicas e bibliotecas de programação do lado do cliente. Sua equipe deve ser competente em escrever JavaScript moderno usando uma estrutura SPA como o Angular.
Referências – SPA Frameworks
- Angular: https://angular.io
- Reagir: https://reactjs.org/
- Vue.js: https://vuejs.org/
Seu aplicativo já deve expor uma API para outros clientes (internos ou públicos)
Se você já estiver oferecendo suporte a uma API da Web para uso por outros clientes, talvez seja necessário menos esforço para criar uma implementação SPA que aproveite essas APIs em vez de reproduzir a lógica no formato do lado do servidor. Os SPAs fazem uso extensivo de APIs da Web para consultar e atualizar dados à medida que os usuários interagem com o aplicativo.
Quando escolher Blazor
A seção a seguir é uma explicação mais detalhada de quando escolher Blazor para seu aplicativo Web.
Seu aplicativo deve expor uma interface de usuário avançada
Como SPAs baseados em JavaScript, Blazor os aplicativos podem oferecer suporte ao comportamento de cliente avançado sem recarregamentos de página. Esses aplicativos são mais responsivos aos usuários, buscando apenas os dados (ou HTML) necessários para responder a uma determinada interação do usuário. Projetados corretamente, os aplicativos do lado Blazor do servidor podem ser configurados para serem executados como aplicativos do lado Blazor do cliente com alterações mínimas, uma vez que esse recurso é suportado.
Sua equipe está mais confortável com o desenvolvimento .NET do que com o desenvolvimento JavaScript ou TypeScript
Muitos desenvolvedores são mais produtivos com .NET e Razor do que com linguagens do lado do cliente como JavaScript ou TypeScript. Como o lado do servidor do aplicativo já está sendo desenvolvido com o .NET, o uso Blazor garante que todos os desenvolvedores do .NET na equipe possam entender e, potencialmente, criar o comportamento do front-end do aplicativo.
Tabela de decisão
A tabela de decisão a seguir resume alguns dos fatores básicos a serem considerados ao escolher entre um aplicativo Web tradicional, um SPA ou um Blazor aplicativo.
| Fator | Aplicação Web tradicional | Aplicação de página única | Blazor Aplicação |
|---|---|---|---|
| Necessária familiaridade da equipe com JavaScript/TypeScript | Mínimo | Obrigatório | Mínimo |
| Suporte a navegadores sem scripts | Suportado | Não Suportado | Suportado |
| Comportamento mínimo do aplicativo do lado do cliente | Bem adequado | Exagero | Viável |
| Requisitos de interface de usuário ricos e complexos | Limitado | Bem adequado | Bem adequado |
Outras considerações
As aplicações Web tradicionais tendem a ser mais simples e têm melhores critérios de Search Engine Optimization (SEO) do que as aplicações SPA. Os bots do mecanismo de pesquisa podem facilmente consumir conteúdo de aplicativos tradicionais, enquanto o suporte para indexação de SPAs pode estar ausente ou limitado. Se seu aplicativo se beneficia da descoberta pública pelos mecanismos de pesquisa, isso geralmente é uma consideração importante.
Além disso, a menos que você tenha criado uma ferramenta de gerenciamento para o conteúdo do seu SPA, isso pode exigir que os desenvolvedores façam alterações. Os aplicativos Web tradicionais geralmente são mais fáceis para não-desenvolvedores fazerem alterações, já que grande parte do conteúdo é simplesmente HTML e pode não exigir um processo de compilação para visualizar ou até mesmo implantar. Se é provável que não desenvolvedores em sua organização precisem manter o conteúdo do aplicativo, um aplicativo Web tradicional pode ser uma escolha melhor.
Os SPAs brilham quando o aplicativo tem formulários interativos complexos ou outros recursos de interação do usuário. Para aplicativos complexos que exigem autenticação para uso e, portanto, não são acessíveis por spiders de mecanismos de pesquisa públicos, os SPAs são uma ótima opção em muitos casos.
