Escolher entre aplicativos Web tradicionais e aplicativos de página única (SPAs)

"Lei de Atwood: qualquer aplicativo que possa ser escrito em JavaScript, eventualmente será escrito em JavaScript."
- Jeff Atwood

Há duas abordagens gerais para criar aplicativos Web hoje: aplicativos Web tradicionais que executam a maior parte da lógica do aplicativo no servidor e SPAs (aplicativos de página única) que executam a maior parte da lógica da interface do usuário em um navegador da Web, comunicando-se com o servidor Web principalmente usando APIs Web. Uma abordagem híbrida também é possível, sendo mais simples hospedar uma ou mais subaplicações avançadas semelhantes a SPA em um aplicativo Web tradicional maior.

Use aplicativos Web tradicionais quando:

• Os requisitos do lado do cliente do aplicativo são simples ou até mesmo somente leitura.

• Seu aplicativo precisa funcionar em navegadores sem suporte para JavaScript.

• Seu aplicativo é voltado para o público e se beneficia da descoberta e das indicações do mecanismo de pesquisa.

Use um SPA quando:

• Seu aplicativo deve expor uma interface avançada do usuário com muitos recursos.

• Sua equipe está familiarizada com o desenvolvimento em JavaScript, TypeScript ou BlazorWebAssembly.

• Seu aplicativo já deve expor uma API para outros clientes (internos ou públicos).

Além disso, as estruturas spa exigem maior experiência em arquitetura e segurança. Eles experimentam maior variação devido a atualizações frequentes e novas estruturas de cliente do que os aplicativos Web tradicionais. Configurar processos automatizados de build 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.

Melhorias na experiência do usuário possibilitadas pela abordagem spa devem ser ponderadas em relação a essas considerações.

Blazor

ASP.NET Core inclui um modelo para criar interfaces de usuário avançadas, interativas e composáveis chamadas 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 do SignalR persistente. Blazor WebAssembly apresenta outra opção para Blazor aplicativos, permitindo que eles sejam executados no navegador usando WebAssembly. Como é um código .NET real sendo executado em WebAssembly, você pode reutilizar código e bibliotecas de partes do servidor da sua aplicação.

Blazor fornece uma nova terceira opção a ser considerada ao avaliar se deseja criar um aplicativo Web puramente renderizado pelo servidor ou um SPA. Você pode criar comportamentos avançados do lado do cliente semelhantes a SPA usando Blazor, sem a necessidade de desenvolvimento significativo do JavaScript. Blazor os aplicativos podem chamar APIs para solicitar dados ou executar operações do lado do servidor. Eles podem interoperar com JavaScript quando necessário para aproveitar as estruturas e bibliotecas JavaScript.

Considere criar seu aplicativo Web com Blazor quando:

• Seu aplicativo deve expor uma interface avançada do usuário

• Sua equipe está mais confortável com o desenvolvimento do .NET do que o desenvolvimento de JavaScript ou TypeScript

Se você tiver um aplicativo de web forms existente que está considerando migrar para o .NET Core ou para o .NET mais recente, talvez queira examinar o e-book gratuito para Desenvolvedores de Web FormsBlazor para ver se faz sentido considerar a migração para Blazor.

Para obter mais informações sobre Blazor, consulte Comece com Blazor.

Quando escolher aplicativos Web tradicionais

A seção a seguir é uma explicação mais detalhada dos motivos indicados anteriormente para escolher aplicativos Web tradicionais.

Seu aplicativo tem requisitos simples, possivelmente somente leitura, no lado do cliente

Muitos aplicativos Web são consumidos principalmente em um modo somente leitura pela grande maioria de seus usuários. Os aplicativos somente leitura (ou predominantemente de leitura) tendem a ser muito mais simples do que aqueles que mantêm e manipulam uma grande quantidade de estados. 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, o aplicativo voltado para o público de um sistema de gerenciamento de conteúdo ou blog geralmente consiste principalmente em conteúdo com pouco comportamento do lado do cliente. Esses aplicativos são facilmente criados como aplicativos Web tradicionais baseados em servidor, que executam a lógica no servidor Web e renderizam HTML a ser exibido no navegador. O fato de que cada página exclusiva do site tem sua própria URL que pode ser marcada e indexada por mecanismos de pesquisa (por padrão, sem precisar adicionar essa funcionalidade como um recurso separado do aplicativo) também é um benefício claro nesses cenários.

Seu aplicativo precisa funcionar em navegadores sem suporte para JavaScript

Aplicativos Web que precisam funcionar em navegadores com suporte limitado ou sem JavaScript devem ser gravados usando fluxos de trabalho de aplicativo Web tradicionais (ou pelo menos ser capazes de fazer fallback para esse comportamento). Os SPAs exigem JavaScript do lado do cliente para funcionar; se não estiver disponível, os SPAs não serão uma boa opção.

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, ela provavelmente poderá fornecer um aplicativo Web tradicional mais rapidamente do que um SPA. A menos que aprender a programar SPAs seja uma meta ou a experiência do usuário oferecida por um SPA seja necessária, os aplicativos Web tradicionais são uma opção mais produtiva para as 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 avançada do usuário com muitos recursos

Os SPAs podem dar suporte a funcionalidades avançadas do lado do cliente que não exigem recarregar a página à medida que os usuários tomam ações ou navegam entre áreas do aplicativo. Os SPAs podem carregar mais rapidamente, buscando dados em segundo plano e ações individuais do usuário são mais responsivas, pois recarregamentos de página inteira são raros. Os SPAs podem dar suporte a atualizações incrementais, salvando formulários ou documentos parcialmente concluídos sem que o usuário precise clicar em um botão para enviar um formulário. Os SPAs podem dar suporte a comportamentos avançados do lado do cliente, como arrastar e soltar, muito mais facilmente 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 eventualmente são sincronizados de volta ao servidor depois que uma conexão é restabelecida. Escolha um aplicativo no estilo SPA se os requisitos do aplicativo incluirem funcionalidade avançada que vai além do que os formulários HTML típicos oferecem.

Frequentemente, os SPAs precisam implementar recursos integrados a aplicativos Web tradicionais, como exibir uma URL significativa na barra de endereços refletindo a operação atual (e permitir que os usuários marquem ou façam um link profundo para essa URL 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 surpreendam.

Sua equipe está familiarizada com o desenvolvimento de JavaScript e/ou TypeScript

Escrever SPAs requer familiaridade com JavaScript e/ou TypeScript e bibliotecas e técnicas de programação do lado do cliente. Sua equipe deve ser competente ao escrever JavaScript moderno usando uma estrutura SPA como o Angular.

Referências – Estruturas de SPA

• Angular: https://angular.io
• React: 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 dando suporte a uma API Web para uso por outros clientes, poderá exigir menos esforço para criar uma implementação de SPA que aproveite essas APIs em vez de reproduzir a lógica no formulário do lado do servidor. Os SPAs fazem uso extensivo de APIs Web para consultar e atualizar dados à medida que os usuários interagem com o aplicativo.

Quando escolher o 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 avançada do usuário

Assim como os SPAs baseados em JavaScript, Blazor os aplicativos podem dar suporte a comportamentos avançados do cliente 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 quando esse recurso tiver suporte.

Sua equipe está mais confortável com o desenvolvimento do .NET do que o desenvolvimento de 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 da equipe possam entender e potencialmente criar o comportamento do front-end do aplicativo.

Tabela de decisões

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.

Outras considerações

Os aplicativos Web tradicionais tendem a ser mais simples e têm melhores critérios de SEO (Otimização do Mecanismo de Pesquisa) do que os aplicativos SPA. Os bots do mecanismo de pesquisa podem consumir facilmente conteúdo de aplicativos tradicionais, enquanto o suporte para indexação de SPAs pode estar ausente ou limitado. Se seu aplicativo se beneficiar da descoberta pública por 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 SPA, isso pode exigir que os desenvolvedores façam alterações. Os Aplicativos Web tradicionais geralmente são mais fáceis para os não desenvolvedores fazerem alterações, pois grande parte do conteúdo é simplesmente HTML e pode não exigir um processo de build para visualizar ou até mesmo implantar. Se os não desenvolvedores em sua organização provavelmente precisarem manter o conteúdo do aplicativo, um aplicativo Web tradicional poderá ser uma opção 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 usar e, portanto, não são acessíveis por crawlers de motores de busca, Aplicativos de Página Única (SPAs) são uma ótima opção em muitos casos.