Aplicativo de página única: vantagens e desvantagens [fechado]

Eu li sobre SPA e vantagens. Acho a maioria deles não convincente. Existem 3 vantagens que despertam minhas dúvidas.

Pergunta: Você pode atuar como advogado do SPA e provar que estou errado sobre as três primeiras declarações?

                              === ADVANTAGES ===

1. O SPA é extremamente bom para sites muito responsivos:

É difícil implementar a renderização no servidor para todos os estados intermediários - os estados de exibição pequena não são bem mapeados para URLs.

Os aplicativos de página única são diferenciados por sua capacidade de redesenhar qualquer parte da interface do usuário sem exigir uma ida e volta do servidor para recuperar o HTML. Isso é conseguido separando os dados da apresentação dos dados, tendo uma camada de modelo que lida com dados e uma camada de visualização que lê dos modelos.

O que há de errado em manter uma camada de modelo para não-SPA? O SPA é a única arquitetura compatível com o MVC no lado do cliente?

2. Com o SPA, não precisamos usar consultas extras para o servidor para baixar páginas.

Hah, e quantas páginas o usuário pode baixar durante a visita ao seu site? Dois três? Em vez disso, aparecem outros problemas de segurança e você precisa separar sua página de login, página de administração etc. em páginas separadas. Por sua vez, entra em conflito com a arquitetura do SPA.

3. pode haver outras vantagens? Não ouça mais nada ..

                            === DISADVANTAGES ===

1. O cliente deve ativar o javascript.
2. Apenas um ponto de entrada para o site.
3. Segurança.

PS : Trabalhei em projetos de SPA e não-SPA. E estou fazendo essas perguntas porque preciso aprofundar meu entendimento. Não há como prejudicar os apoiadores do SPA. Não me peça para ler um pouco mais sobre o SPA. Eu só quero ouvir suas considerações sobre isso.

Vejamos um dos sites de SPA mais populares, o GMail.

1. O SPA é extremamente bom para sites muito responsivos:

A renderização no servidor não é tão difícil quanto costumava ser com técnicas simples, como manter um #hash na URL ou, mais recentemente, em HTML5pushState . Com essa abordagem, o estado exato do aplicativo Web é incorporado no URL da página. Como no GMail, toda vez que você abre um e-mail, uma tag de hash especial é adicionada ao URL. Se copiado e colado em outra janela do navegador, é possível abrir exatamente o mesmo email (desde que eles possam se autenticar). Essa abordagem é mapeada diretamente para uma string de consulta mais tradicional, a diferença está apenas na execução. Com o HTML5 pushState (), você pode eliminar #hashe usar URLs completamente clássicos que podem ser resolvidos no servidor na primeira solicitação e carregados via ajax nas solicitações subsequentes.

2. Com o SPA, não precisamos usar consultas extras para o servidor para baixar páginas.

O número de páginas que o usuário baixa durante a visita ao meu site? realmente quantos e-mails alguns leem quando ele abre sua conta de e-mail. Eu li> 50 de uma só vez. agora a estrutura dos e-mails é quase a mesma. se você usar um esquema de renderização do lado do servidor, o servidor o renderizará em cada solicitação (caso típico). - preocupação de segurança - você deve / não deve manter páginas separadas para os administradores / login que dependam inteiramente da estrutura do seu site, como paytm.com, por exemplo, também criar um site SPA não significa que você abra todos os pontos de extremidade para todos os usuários, quero dizer, uso autenticação de formulários no meu site de spa. - no provavelmente mais usado framework Angular JS do SPA, o desenvolvedor pode carregar todo o templo de html do site, para que isso possa ser feito dependendo do nível de autenticação dos usuários. pré-carregamento de html para todos os tipos de autenticação isn '

3. Pode haver outras vantagens? Não ouça mais nada ..

• hoje em dia, você pode assumir com segurança que o cliente terá navegadores habilitados para javascript.
• apenas um ponto de entrada do site. Como mencionei anteriormente, a manutenção do estado é possível, você pode ter qualquer número de pontos de entrada que desejar, mas deve ter um com certeza.
• mesmo em um usuário de SPA, verifique apenas o que ele tem direitos adequados. você não precisa injetar tudo de uma vez. carregar modelos diff html e javascript assíncrono também é uma parte válida do SPA.

As vantagens que consigo pensar são:

1. A renderização de html obviamente requer alguns recursos agora, todos os usuários que visitam seu site estão fazendo isso. agora, além de renderizar lógicas importantes, agora são feitas no lado do cliente, e não no lado do servidor.
2. data e hora - eu apenas dou ao cliente a hora UTC em um formato predefinido e nem me importo com os fusos horários em que o javascript lida com isso. essa é uma grande vantagem para onde eu tinha que adivinhar fusos horários com base no local derivado do IP dos usuários.
3. para mim, o estado é mais bem mantido em um SPA, porque depois de definir uma variável, você sabe que ela estará lá. isso dá a sensação de desenvolver um aplicativo em vez de uma página da web. isso geralmente ajuda muito na criação de sites como foodpanda, flipkart, amazon. porque se você não estiver usando o estado do lado do cliente, estará usando sessões caras.
4. os sites certamente são extremamente responsivos - darei um exemplo extremo para esta tentativa de fazer uma calculadora em um site que não seja do SPA (eu sei que é estranho).

Atualizações de comentários

Parece que ninguém mencionou soquetes e pesquisas longas. Se você sair de outro cliente, por exemplo, aplicativo móvel, seu navegador também deverá sair. Se você não usa o SPA, é necessário recriar a conexão do soquete sempre que houver um redirecionamento. Isso também deve funcionar com todas as atualizações de dados, como notificações, atualização de perfil, etc.

Uma perspectiva alternativa: além do seu site, seu projeto envolverá um aplicativo móvel nativo? Se sim, é provável que você esteja alimentando dados brutos para esse aplicativo nativo a partir de um servidor (ou seja, JSON) e processando o lado do cliente para processá-lo, correto? Portanto, com essa afirmação, você JÁ está fazendo um modelo de renderização no lado do cliente. Agora a pergunta é: por que você não deve usar o mesmo modelo para a versão do site do seu projeto? Uma espécie de acéfalo. A questão é se você deseja renderizar páginas do lado do servidor apenas para benefícios de SEO e conveniência de URLs compartilháveis ​​/ que podem ser marcados como favoritos

Sou pragmático, então tentarei analisar isso em termos de custos e benefícios.

Observe que, por qualquer desvantagem que eu der, reconheço que são solucionáveis. É por isso que não vejo nada em preto e branco, mas custos e benefícios.

Vantagens

• Rastreamento de estado mais fácil - não há necessidade de usar cookies, envio de formulários, armazenamento local, armazenamento de sessão etc. para lembrar o estado entre duas cargas de página.
• O conteúdo da placa da caldeira que está em todas as páginas (cabeçalho, rodapé, logotipo, faixa de direitos autorais etc.) é carregado apenas uma vez por sessão típica do navegador.
• Não há latência de sobrecarga na alternância de "páginas".

Desvantagens

• Monitoramento de desempenho - mãos atadas: a maioria das soluções de monitoramento de desempenho no nível do navegador que eu vi focam apenas no tempo de carregamento da página, como tempo até o primeiro byte, tempo para criar o DOM, ida e volta da rede para o HTML, evento onload etc. Atualizando a página pós-carregamento via AJAX não seria medido. Existem soluções que permitem instrumentar seu código para registrar medidas explícitas, como ao clicar em um link, iniciar um cronômetro e encerrar um cronômetro após renderizar os resultados do AJAX e enviar esse feedback. A New Relic, por exemplo, suporta essa funcionalidade. Ao usar um SPA, você se vinculou a apenas algumas ferramentas possíveis.
• Teste de segurança / penetração - de mãos dadas: as verificações de segurança automatizadas podem ter dificuldade em descobrir links quando toda a página é construída dinamicamente por uma estrutura de SPA. Provavelmente existem soluções para isso, mas, novamente, você se limitou.
• Agrupamento: é fácil entrar em uma situação quando você está baixando todo o código necessário para todo o site no carregamento inicial da página, o que pode ter um desempenho terrível para conexões de baixa largura de banda. Você pode agrupar seus arquivos JavaScript e CSS para tentar carregar pedaços mais naturais à medida que avança, mas agora você precisa manter esse mapeamento e observar se arquivos indesejados são atraídos por dependências não realizadas (aconteceu comigo). Mais uma vez, solucionável, mas com um custo.
• Refatoração do Big Bang: se você deseja fazer uma grande mudança na arquitetura, como, por exemplo, mudar de uma estrutura para outra, para minimizar os riscos, é desejável fazer alterações incrementais. Ou seja, comece a usar o novo, migre de alguma forma, como por página, por recurso, etc. e depois largue o antigo. Com o aplicativo tradicional de várias páginas, você pode alternar uma página de Angular para React e depois outra página no próximo sprint. Com um SPA, é tudo ou nada. Se você deseja alterar, é necessário alterar o aplicativo inteiro de uma só vez.
• Complexidade da navegação: existem ferramentas para ajudar a manter o contexto de navegação nos SPAs, como history.js, Angular 2, a maioria dos quais se baseia na estrutura de URL (#) ou na API de histórico mais recente. Se cada página fosse uma página separada, você não precisa disso.
• Complexidade de descobrir código: pensamos naturalmente nos sites como páginas. Um aplicativo de várias páginas geralmente divide o código por página, o que ajuda na manutenção.

Novamente, reconheço que todos esses problemas são solucionáveis, a algum custo. Mas chega um momento em que você passa todo o seu tempo resolvendo problemas que você poderia ter evitado em primeiro lugar. Ele volta aos benefícios e à importância que eles têm para você.

Desvantagens

1. O cliente deve ativar o javascript. Sim, essa é uma clara desvantagem do SPA. No meu caso, sei que posso esperar que meus usuários tenham o JavaScript ativado. Se você não pode, não pode fazer um SPA, ponto final. É como tentar implantar um aplicativo .NET em uma máquina sem o .NET Framework instalado.

2. Apenas um ponto de entrada para o site. Eu resolvo esse problema usando o SammyJS . 2-3 dias de trabalho para configurar seu roteamento corretamente, e as pessoas poderão criar marcadores de link direto no seu aplicativo que funcionem corretamente. Seu servidor precisará expor apenas um terminal - o terminal "forneça o HTML + CSS + JS para este aplicativo" (pense nele como um local de download / atualização para um aplicativo pré-compilado) - e o JavaScript do cliente que você escrever manipular a entrada real no aplicativo.

3. segurança.Esse problema não é exclusivo dos SPAs; você precisa lidar com a segurança exatamente da mesma maneira quando tiver um aplicativo cliente-servidor "antigo" (o modelo HATEOAS de usar o Hypertext para vincular páginas). É só que o usuário está fazendo as solicitações em vez do seu JavaScript e que os resultados estão em HTML, em vez de JSON ou algum formato de dados. Em um aplicativo não-SPA, você deve proteger as páginas individuais no servidor, enquanto em um aplicativo SPA, você deve proteger os pontos de extremidade de dados. (E, se você não deseja que seu cliente tenha acesso a todo o código, também é necessário dividir o JavaScript para download em áreas separadas. Simplesmente vinculo isso ao meu sistema de roteamento baseado no SammyJS, para que o navegador apenas solicite coisas que o cliente sabe que deve ter acesso, com base em um carregamento inicial das funções do usuário,

Vantagens

1. Uma grande vantagem arquitetural de um SPA (que raramente é mencionado) em muitos casos é a enorme redução na "chattiness" do seu aplicativo. Se você o projetar adequadamente para lidar com a maioria dos processos no cliente (o ponto todo, afinal), o número de solicitações ao servidor (leia "possibilidades de erros 503 que prejudicam sua experiência do usuário") será reduzido drasticamente. De fato, um SPA torna possível o processamento totalmente offline, o que é enorme em algumas situações.

2. O desempenho é certamente melhor com a renderização do lado do cliente, se você fizer o que é certo, mas esse não é o motivo mais atraente para criar um SPA. (Afinal, as velocidades da rede estão melhorando.) Não defenda o SPA apenas com base nisso.

3. A flexibilidade no design da interface do usuário talvez seja a outra grande vantagem que encontrei. Depois de definir minha API (com um SDK em JavaScript), pude reescrever completamente meu front-end sem impacto no servidor, além de alguns arquivos de recursos estáticos. Tente fazer isso com um aplicativo MVC tradicional! :) (Isso se torna valioso quando você tem que se preocupar com implementações ativas e consistência de versão da sua API.)

Portanto, se você precisar de processamento offline (ou pelo menos desejar que seus clientes possam sobreviver a interrupções ocasionais do servidor) - reduzindo drasticamente seus próprios custos de hardware - e você pode assumir JavaScript e navegadores modernos, precisará de um SPA. Em outros casos, é mais uma troca.

Uma grande desvantagem do SPA - SEO. Somente recentemente o Google e o Bing começaram a indexar páginas baseadas no Ajax executando JavaScript durante o rastreamento e, em muitos casos, as páginas ainda estão sendo indexadas incorretamente.

Durante o desenvolvimento do SPA, você será forçado a lidar com problemas de SEO, provavelmente pós-renderizando todo o site e criando instantâneos de html estático para o uso do rastreador. Isso exigirá um investimento sólido em infraestruturas adequadas.

Atualização 19.06.16:

Desde que escrevi esta resposta há um tempo, ganho muito mais experiência com os aplicativos de página única (ou seja, o AngularJS 1.x) - então tenho mais informações para compartilhar.

Na minha opinião, a principal desvantagem dos aplicativos de SPA é o SEO, limitando-os apenas aos aplicativos de "painel". Além disso, você terá muito mais dificuldade com o cache, em comparação com as soluções clássicas. Por exemplo, no ASP.NET, o cache é extremamente fácil - basta ativar o OutputCaching e você é bom: a página HTML inteira será armazenada em cache de acordo com a URL (ou qualquer outro parâmetro). No entanto, no SPA, você precisará lidar com o armazenamento em cache (usando algumas soluções, como cache de segundo nível, cache de modelos, etc.).

Gostaria de defender que o SPA seja o melhor para aplicativos orientados a dados. O Gmail, é claro, trata de dados e, portanto, um bom candidato a um SPA.

Mas se sua página é principalmente para exibição, por exemplo, uma página de termos de serviço, um SPA é um exagero.

Eu acho que o ponto ideal é ter um site com uma mistura de páginas de estilo SPA e estática / MVC, dependendo da página em particular.

Por exemplo, em um site que estou construindo, o usuário acessa uma página de índice padrão do MVC. Mas quando eles acessam o aplicativo real, ele acessa o SPA. Outra vantagem disso é que o tempo de carregamento do SPA não está na página inicial, mas na página do aplicativo. O tempo de carregamento na página inicial pode ser uma distração para os usuários do site iniciantes.

Esse cenário é um pouco como usar o Flash. Após alguns anos de experiência, o número de sites apenas em Flash caiu para quase zero devido ao fator de carga. Mas como um componente de página, ele ainda está em uso.

Para empresas como google, amazon etc., cujos servidores estão funcionando com capacidade máxima no modo 24/7, reduzir o tráfego significa dinheiro real - menos hardware, menos energia, menos manutenção. Mudar o uso da CPU do servidor para o cliente compensa e os SPAs brilham. As vantagens sobrepeso desvantagens de longe. Portanto, o SPA ou não o SPA depende muito do caso de uso.

Apenas por mencionar outro caso de uso, provavelmente não tão óbvio (para desenvolvedores da Web), para SPAs: Atualmente, estou procurando uma maneira de implementar GUIs em sistemas embarcados e a arquitetura baseada em navegador parece atraente para mim. Tradicionalmente, não havia muitas possibilidades de UIs em sistemas embarcados - Java, Qt, wx, etc ou estruturas comerciais apropriadas. Alguns anos atrás, a Adobe tentou entrar no mercado com flash, mas parece não ter tanto sucesso.

Atualmente, como os "sistemas embarcados" são tão poderosos quanto os mainframes há alguns anos, uma interface do usuário baseada em navegador conectada à unidade de controle via REST é uma solução possível. A vantagem é que a enorme paleta de ferramentas para interface do usuário é gratuita. (por exemplo, Qt exige 20-30 $ por unidade vendida em taxas de royalties mais 3000-4000 $ por desenvolvedor)

Para essa arquitetura, o SPA oferece muitas vantagens - por exemplo, uma abordagem de desenvolvimento mais familiar para desenvolvedores de aplicativos de desktop, acesso reduzido ao servidor (geralmente na indústria automobilística, a interface do usuário e os problemas do sistema são hardware separado, onde a parte do sistema possui um sistema operacional RT).

Como o único cliente é o navegador interno, as desvantagens mencionadas, como disponibilidade de JS, log do lado do servidor e segurança, não contam mais.

2. Com o SPA, não precisamos usar consultas extras para o servidor para baixar páginas.

Ainda tenho que aprender muito, mas desde que comecei a aprender sobre o SPA, eu os amo.

Este ponto em particular pode fazer uma enorme diferença.

Em muitos aplicativos da Web que não são SPA, você verá que eles ainda irão recuperar e adicionar conteúdo às páginas que fazem solicitações de ajax. Então, acho que o SPA vai além, considerando: e se o conteúdo que será recuperado e exibido usando o ajax for a página inteira? e não apenas uma pequena parte de uma página?

Deixe-me apresentar um cenário. Considere que você tem 2 páginas:

1. uma página com lista de produtos
2. uma página para visualizar os detalhes de um produto específico

Considere que você está na página da lista. Então você clica em um produto para visualizar os detalhes. O aplicativo do lado do cliente acionará 2 solicitações de ajax:

1. uma solicitação para obter um objeto json com os detalhes do produto
2. uma solicitação para obter um modelo html no qual os detalhes do produto serão inseridos

Em seguida, o aplicativo do lado do cliente inserirá os dados no modelo html e os exibirá.

Depois, você volta para a lista (nenhuma solicitação é feita para isso!) E abre outro produto. Desta vez, haverá apenas uma solicitação de ajax para obter os detalhes do produto. O modelo html será o mesmo para que você não precise fazer o download novamente.

Você pode dizer que em um SPA não, quando você abre os detalhes do produto, faz apenas 1 solicitação e, nesse cenário, fizemos 2. Sim. Mas você obtém o ganho de uma perspectiva geral. Quando você navega por muitas páginas, o número de solicitações será menor. E os dados transferidos entre o lado do cliente e o servidor também serão mais baixos porque os modelos html serão reutilizados. Além disso, você não precisa baixar em todas as solicitações todos os arquivos css, imagens e javascript que estão presentes em todas as páginas.

Além disso, vamos considerar que a linguagem do lado do servidor é Java. Se você analisar as 2 solicitações que eu mencionei, 1 baixa dados (você não precisa carregar nenhum arquivo de visualização e chamar o mecanismo de renderização de visualização) e os outros downloads e modelo estático de html para que você possa ter um servidor da Web HTTP que possa recuperar diretamente sem precisar chamar o servidor de aplicativos Java, nenhum cálculo é feito!

Finalmente, as grandes empresas estão usando o SPA: Facebook, GMail, Amazon. Eles não jogam, eles têm os melhores engenheiros estudando tudo isso. Portanto, se você não vê as vantagens, pode confiar inicialmente nelas e esperar descobri-las no caminho.

Mas é importante usar bons padrões de design de SPA. Você pode usar uma estrutura como o AngularJS. Não tente implementar um SPA sem usar bons padrões de design, pois você pode acabar tendo uma bagunça.

Desvantagens : Tecnicamente, o design e o desenvolvimento inicial do SPA são complexos e podem ser evitados. Outras razões para não usar este SPA podem ser:

• a) Segurança: o aplicativo de página única é menos seguro em comparação com as páginas tradicionais devido ao script entre sites (XSS).
• b) Vazamento de memória: o vazamento de memória no JavaScript pode até causar a desaceleração do poderoso computador. Como os sites tradicionais incentivam a navegar entre as páginas, qualquer vazamento de memória causado pela página anterior é quase limpo, deixando menos resíduos para trás.
• c) O cliente deve ativar o JavaScript para executar o SPA, mas no aplicativo de várias páginas o JavaScript pode ser completamente evitado.
• d) O SPA cresce no tamanho ideal, causando um longo tempo de espera. Por exemplo: trabalhando no Gmail com conexão mais lenta.

Além do acima, outras limitações arquiteturais são perda de dados de navegação, nenhum registro do histórico de navegação no navegador e dificuldade no teste funcional automatizado com selênio.

Este link explica as vantagens e desvantagens do aplicativo de página única.

No meu desenvolvimento, encontrei duas vantagens distintas no uso de um SPA. Isso não quer dizer que o seguinte não possa ser alcançado em um aplicativo Web tradicional, apenas porque vejo benefícios incrementais sem introduzir desvantagens adicionais.

• O potencial para menos solicitações do servidor, pois a renderização de novo conteúdo nem sempre é uma solicitação do servidor http para uma nova página html. Mas eu digo potencial, porque o novo conteúdo pode facilmente exigir uma chamada do Ajax para obter dados, mas esses dados podem ser incrementalmente mais leves que o próprio, além da marcação, proporcionando um benefício líquido.

• A capacidade de manter o "Estado". Em seus termos mais simples, defina uma variável na entrada do aplicativo e ele estará disponível para outros componentes durante toda a experiência do usuário sem transmiti-lo ou configurá-lo para um padrão de armazenamento local. No entanto, o gerenciamento inteligente dessa capacidade é essencial para manter o escopo de nível superior organizado.

Além de exigir o JS (o que não é uma loucura exigir dos aplicativos da web), outras desvantagens observadas são, na minha opinião, não específicas do SPA ou podem ser mitigadas por bons hábitos e padrões de desenvolvimento.

Tente não considerar o uso de um SPA sem antes definir como abordará a segurança e a estabilidade da API no lado do servidor. Então você verá algumas das verdadeiras vantagens de usar um SPA. Especificamente, se você usar um servidor RESTful que implementa o OAUTH 2.0 para segurança, obterá duas separações fundamentais de preocupações que podem reduzir seus custos de desenvolvimento e manutenção.

1. Isso moverá a sessão (e é segurança) para o SPA e aliviará o servidor de toda essa sobrecarga.
2. Sua API se torna estável e facilmente extensível.

Sugerido anteriormente, mas não explicitado; Se seu objetivo é implantar aplicativos Android e Apple, a gravação de um SPA JavaScript envolto por uma chamada nativa para hospedar a tela em um navegador (Android ou Apple) elimina a necessidade de manter uma base de código da Apple e uma base de código do Android.

Entendo que essa é uma pergunta mais antiga, mas gostaria de acrescentar outra desvantagem dos aplicativos de página única:

Se você criar uma API que retorne resultados em uma linguagem de dados (como XML ou JSON) em vez de uma linguagem de formatação (como HTML), estará permitindo uma maior interoperabilidade de aplicativos, por exemplo, em aplicativos B2B (B2B). Essa interoperabilidade tem grandes benefícios, mas permite que as pessoas escrevam software para "extrair" (ou roubar) seus dados. Essa desvantagem específica é comum a todas as APIs que usam uma linguagem de dados, e não aos SPAs em geral (de fato, um SPA que solicita ao servidor HTML pré-renderizado evita isso, mas à custa de uma separação pobre de modelo / exibição). Esse risco exposto por essa desvantagem pode ser mitigado por vários meios, como limitação de solicitação e bloqueio de conexão, etc.