Escolher entre aplicativos Web tradicionais e SPAs (aplicativos de página única)
Dica
Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos Web Modernos com o ASP.NET Core e o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
"Lei de Atwood: qualquer aplicativo que pode ser escrito em JavaScript será, em última análise, escrito em JavaScript."
- Jeff Atwood
Há duas abordagens gerais para a criação de aplicativos Web hoje: os aplicativos Web tradicionais, que executam a maior parte da lógica do aplicativo no servidor, e os 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 por meio de APIs Web. Uma abordagem híbrida também é possível, e a mais simples é hospedar um ou mais subaplicativos avançados semelhantes ao SPA em um aplicativo Web tradicional maior.
Use os 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 a 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 precisa expor uma interface do usuário avançada com muitos recursos.
Sua equipe estiver familiarizada com o desenvolvimento de JavaScript, TypeScript ou BlazorWebAssembly.
Seu aplicativo já deve expor uma API para outros clientes (internos ou públicos).
Além disso, as estruturas de SPA exigem um maior conhecimento em arquitetura e segurança. Elas passam por uma rotatividade maior devido às atualizações frequentes e às novas estruturas em comparação com os aplicativos Web tradicionais. A configuração de processos de compilação e de implantação automatizados e a utilização de opções de implantação, como contêineres, podem mais difíceis com aplicativos SPA do que com aplicativos Web tradicionais.
As melhorias na experiência do usuário possibilitadas pela abordagem SPA devem ser avaliadas em relação a essas considerações.
Blazor
O ASP.NET Core inclui um modelo para a criação de interfaces de usuário avançadas, interativas e combináveis chamado Blazor. O servidor Blazor permite que os desenvolvedores criem interfaces do usuário com C# e Razor no servidor e que essa interface seja conectada interativamente ao navegador, em tempo real, usando uma conexão SignalR persistente. BlazorWebAssembly apresenta outra opção para os aplicativos Blazor, permitindo que sejam executados no navegador usando WebAssembly. Como é um código .NET real em execução em WebAssembly, você pode reutilizar o código e as bibliotecas de partes do servidor do aplicativo.
O Blazor fornece uma nova e terceira opção a ser considerada ao avaliar se é necessário criar um aplicativo Web puramente renderizado pelo servidor ou um SPA. Você pode criar comportamentos avançados do cliente semelhantes a SPA usando Blazor, sem a necessidade de um desenvolvimento significativo de JavaScript. Os aplicativos Blazor podem chamar APIs para solicitar dados ou executar operações do servidor. Eles podem interoperar com JavaScript quando necessário para aproveitar as bibliotecas e estruturas de JavaScript.
Considere criar seu aplicativo Web com Blazor quando:
Seu aplicativo precisar expor uma interface do usuário avançada.
Sua equipe estiver mais confortável com o desenvolvimento de .NET do que de JavaScript ou TypeScript.
Se você tiver um aplicativo web forms que esteja pensando em migrar para o .NET Core ou para o .NET mais recente, talvez seja interessante ler o livro eletrônico gratuito Blazor para desenvolvedores de Web Forms, para ver se é sensata a migração para Blazor.
Para obter mais informações sobre o Blazor, confira Introdução ao Blazor.
Quando escolher aplicativos Web tradicionais
Na seção a seguir há uma explicação mais detalhada dos motivos já mencionados para escolher os aplicativos Web tradicionais.
Seu aplicativo tem requisitos simples do lado do cliente, possivelmente somente leitura
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 exibição dos resultados da pesquisa. Os usuários anônimos podem fazer solicitações com facilidade, e há pouca necessidade de uma lógica do lado do cliente. Da mesma forma, um aplicativo voltado para o público de um sistema de gerenciamento de conteúdo ou blog normalmente consiste principalmente em conteúdo com pouco comportamento do lado do cliente. Aplicativos desse tipo são criados com facilidade como aplicativos Web tradicionais baseados em servidor que executam a lógica no servidor Web e renderizam o 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 a necessidade de 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 a JavaScript
Os aplicativos Web que precisam funcionar em navegadores com suporte limitado ou nenhum suporte a JavaScript precisam ser escritos com fluxos de trabalho de aplicativo Web tradicional (ou, pelo menos, poder fazer fallback para esse comportamento). Os SPAs exigem um JavaScript do lado do cliente para funcionar; se ele 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 do JavaScript ou do TypeScript
Caso sua equipe não esteja familiarizada com o JavaScript ou o TypeScript, mas esteja familiarizada com o desenvolvimento de aplicativos Web do lado do servidor, provavelmente, ela poderá fornecer um aplicativo Web tradicional mais rapidamente do que um SPA. A menos que o aprendizado de programação de SPAs seja uma meta ou a experiência do usuário proporcionada por um SPA seja necessária, os aplicativos Web tradicionais serão uma opção mais produtiva para equipes que já estão familiarizadas com sua criação.
Quando escolher SPAs
Veja na 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 precisa expor uma interface do usuário avançada com muitos recursos
Os SPAs podem dar suporte à funcionalidade avançada do lado do cliente que não exige o recarregamento da página conforme os usuários executam ações ou navegam entre as áreas do aplicativo. OS SPAs podem ser carregados com mais agilidade, buscando dados em segundo plano, e as ações de usuário individuais são mais ágeis na resposta pois os recarregamentos de página inteira são raros. Os SPAs podem dar suporte a 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 ser compatíveis com comportamentos avançados do lado do cliente, como operações do tipo "arrastar e soltar", com muito mais agilidade do que os aplicativos tradicionais. Os SPAs podem ser designados para serem executados em um modo desconectado, fazendo atualizações em um modelo do lado do cliente que são, por fim, sincronizadas com o servidor depois que uma conexão é restabelecida. Escolha um aplicativo no estilo SPA se os requisitos do aplicativo incluem uma funcionalidade avançada que vai além do que os formulários HTML típicos oferecem.
Normalmente, os SPAs precisam implementar recursos internos de aplicativos Web tradicionais, como a exibição de uma URL significativa na barra de endereços que reflita a operação atual (e permitindo que os usuários marquem ou criem um link profundo dessa URL para retornar a ela). Os SPAs também devem permitir que os usuários usem os botões Voltar e Avançar do navegador com resultados que não os surpreenderão.
Sua equipe está familiarizado com o desenvolvimento do JavaScript e/ou do TypeScript
A configuração de SPAs exige familiaridade com o JavaScript e/ou o TypeScript e bibliotecas e técnicas de programação do lado do cliente. Sua equipe deve ser competente na escrita de JavaScript moderno usando uma estrutura de 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)
Caso você já esteja dando suporte a uma API Web para uso por outros clientes, poderá ser necessário menos esforço para criar uma implementação de SPA que utiliza 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 os dados conforme os usuários interagem com o aplicativo.
Quando escolher o Blazor
A seção a seguir é uma explicação mais detalhada de quando escolher o Blazor como seu aplicativo Web.
Seu aplicativo precisar expor uma interface do usuário avançada
Assim como os SPAs baseados em JavaScript, os aplicativos Blazor 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. Projetados corretamente, os aplicativos Blazor do servidor poderão ser configurados para serem executados como aplicativos Blazor do cliente com alterações mínimas, quando esse recurso tiver suporte.
Sua equipe estiver mais confortável com o desenvolvimento de .NET do que de JavaScript ou TypeScript
Muitos desenvolvedores são mais produtivos com .NET e Razor do que com linguagens do lado cliente, como JavaScript ou TypeScript. Como o lado servidor do aplicativo já está sendo desenvolvido com o .NET, o uso do Blazor garante que todos os desenvolvedores do .NET na equipe possam entender e criar o comportamento do front-end do aplicativo.
Tabela de decisões
A tabela de decisões a seguir resume alguns dos fatores básicos a serem considerados ao escolher entre um aplicativo Web tradicional, SPA ou Blazor.
| Fator | Aplicativo Web tradicional | Aplicativo de página única | Blazor Aplicativo |
|---|---|---|---|
| É necessária a familiaridade da equipe com JavaScript/TypeScript | Mínimo | Necessária | Mínimo |
| Suporte a navegadores sem scripts | Com suporte | Sem suporte | Com suporte |
| Comportamento mínimo do aplicativo do lado do cliente | Apropriado | Exagero | Viável |
| Requisitos avançados e complexos de interface do usuário | Limitado | Apropriado | Apropriado |
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 ser insuficiente ou limitado. Se seu aplicativo se beneficia 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 de fazer alterações para não desenvolvedores, pois grande parte do conteúdo é HTML e pode não exigir um processo de build para visualizaçãop ou até mesmo implantação. Se for provável que não desenvolvedores em sua organização precisem manter o conteúdo do aplicativo, um aplicativo Web tradicional poderá 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 que, 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.
