SPA: o que é e quando usar?

O SPA ao qual me refiro não é aquele lugar de descanso para relaxar e sim um interessante conceito em termos de desenvolvimento WEB cuja sigla significa Single Page Application ou MVC client-side.

A sigla parece meio óbvia... é uma aplicação web de uma página só... sim, beleza é isso, mas não é só isso: aplicativos de uma única página se distinguem pela sua capacidade de redesenhar qualquer parte da interface do usuário sem a necessidade de ida e volta no servidor para recuperar HTML, já que os dados enviados para o navegador apresentam-se em formato bruto JSON ou XML, através do padrão RESTful (onde o servidor expõe um conjunto de endpoints consumidos por clients JavaScript). Funcionando como uma aplicação desktop instalada na máquina do usuário, fica a cargo do navegador  fazer a conversão e o processamento dos dados em HTML, ou seja, desonera o servidor, tornando o tempo de resposta mais rápido.

Modelo tradicional server-side sem ajax

Model, view e controller executam no servidor, geram o html e o enviam ao navegador do cliente.

Modelo tradicional server-side com ajax

Semelhante ao modelo anterior porém, com a implementação de JavaScript utilizando-se de ajax, algumas das funcionalidades da view são processadas no lado cliente, fazendo requisições parciais, o que evita o reload total em cada interação do usuário com a página web.

Modelo client-side

A view e o controller são executados no lado cliente. Já o model passa a ter duas partes, uma executada no lado servidor e outra no lado cliente. O server além de fornecer e armazenar os dados é responsável por fornecer uma API (geralmente em formato RESTful) para ser consumida pela aplicação cliente.Este lado  fica responsável pela renderização de templates e pelo controle de rotas. As validações são responsabilidade de ambos e devem ocorrer tanto no lado cliente quanto no lado servidor.

Em SPA também se utilizam conceitos de desenvolvimento mais modernos como foco em interface mais rica. Interações ricas significam que os componentes da interface têm muito mais estados intermediários, como por exemplo, menu aberto, menu fechado, menu oculto, item de menu clicado, item A do menu selecionado, item B do menu selecionado. Se a renderização destes estados tivesse que ser tratada no lado do servidor a implementação seria bem mais difícil porque os mesmos não são bem mapeados para URLs.
Como temos que focar em escrever mais código client-side a necessidade de padronização e de hierarquia ganha espaço e temos um código JavaScript mais organizado, geralmente com a ajuda de frameworks (como AngularJS, Ember.js e Backbone.js).
Além disso, existem outras coisas interessantes do padrão WEB 2.0 geralmente aplicadas nas SPAs:

• maior expertise em termos de técnicas de front-end;
• desenvolvimento já pensando em termos de ambiente de execução, ou seja qual será o dispositivo onde a aplicação vai rodar (smartphone, tablet, pc, etc);
• não utilização de elementos de navegação convencionais como links (o que seria vantajoso em temos de SEOs) permitindo formas alternativas e mais mais fluidas de explorar e  percorrer a página, como scroll vertical, horizontal e o parallax effect;
• fazem uso do HTML 5;
• trafegam dados de forma assíncrona com o servidor (utilizando WebSockets, AJAX ou Comet);

Agora vem a dúvida: quando utilizar e quando não utilzar a técnica SPA?

Bom, algumas discuções tem sido feitas a respeito e há críticas e elogios. Na minha opinião vale o bom senso. Não dá para sair usando para todos os cenários, o que, diga-se de passagem, é muito comum na informática. Só porque uma tecnologia está na crista da onda é adotada a torto e direito por milhares de desenvolvedores e empresas que querem "andar na moda", sem critérios de aplicabilidade ao contexto.

Mas vamos ao que interessa!

Cenários onde SPAs são interessantes

• Aplicações que tenham uma interface rica e exijam bastante processamento e interação com o usuário (como jogos, processamento de texto, etc)
• Aplicações cujo processamento não exige recursos do servidor (como processamento de imagens)
• Aplicações que precisem funcionar de maneira offline (como mapas, sistemas acoplados ao GPS, etc)
• Aplicações onde seja necessário desenvolver front-ends específicos em função do dispositivo utilizado (como apps para Android, IOS ou Windows Phone)

São exemplos de aplicações que utilizam o padrão SPA: Gmail,  Google, Google Drive, Facebook, Twitter, FourSquare, Instagram, Blogger, LinkedIn e SoundCloud.

Cenários onde as SPAs não são interessantes

• Aplicações que tenham várias páginas e conteúdos diversos
• Conteúdo que precise ser indexado por mecanismos de pesquisa (páginas válidas, que possam ser rastreadas)
• Conteúdo que precise ser exibido quando o JavaScript estiver desabilitado no cliente

Há prós e contras em termos de adoção da tecnologia para a equipe de desenvolvimento.

Prós

• Padronização e modularização do código JavaScript
• Existência de APIs públicas prontas e testadas disponíveis para utilização
• Faz uso de práticas modernas de desenvolvimento
• Separação clara e equilíbro da carga de processamento entre cliente e servidor

Contras

• Inclusão de uma camada a mais na aplicação
• Necessidade de aprender uma ou mais técnicas (MVC e/ou MVVM) e frameworks de front-end
• Existem argumentos contra a utilização de SPA alegando que tanto a não adoção do padrão HTML como a criação de um aplicativo desktop no browser quebram o paradigma WEB. Leia mais em “Web Development: You’re Doing it Wrong”

Dúvidas, sugestões e questionamentos são bem vindos.