[Staging] O que são aplicações SPA?

Neste artigo, vamos abordar o que são as aplicações baseadas em tecnologias SPA e o porquê de estas fazerem tanto sucesso nos dias atuais.

A sigla SPA vem de Single Page Applications, ou Aplicações de Página Única. Apesar de o nome permitir a dedução, isso não significa que a aplicação terá apenas uma única página.

Curso JavaScript Básico

Conhecer o curso

O que muda na verdade é a forma com que a página irá ser carregada. Estamos acostumados com aplicações onde as páginas são renderizadas do lado do servidor, independente da tecnologia utilizada. Isso traz um efeito: cada nova página que precisa ser carregada se traduz em uma nova requisição para o servidor, requisição esta para que o browser consiga carregar o HTML, o CSS e o JavaScript da nova página requisitada. Por isso, em várias aplicações web, vemos o browser levando um “tempinho” para carregar a nova página, ou vemos a nova página ficar em branco inicialmente para ser carregada em seguida. Estes comportamentos ocorrem por causa do tempo entre o browser fazer a requisição para carregar a nova página e o servidor responder com as novas estruturas a serem renderizadas.

Aplicações baseadas em frameworks SPA funcionam de maneira diferente, pois nelas não há a necessidade de se fazer requisições para carregamento de novas páginas. A aplicação seria “carregada” por inteiro na primeira requisição, onde todo o HTML, CSS e JavaScript necessários seriam carregados de uma vez. A partir deste momento, quando novas páginas precisassem ser carregadas, estas seriam carregadas através de rotinas JavaScript, retirando a necessidade de requisições para o servidor com a finalidade de obter o novo conteúdo a ser renderizado.

Aplicações SPA de maneira geral nos permitem obter algumas vantagens. Uma delas é a possibilidade de otimização em geral da performance da aplicação ao deslocar todo o esforço de renderização para o cliente e permitir um tráfego de dados mais leve entre cliente e servidor. Outra é o reaproveitamento de código através de tecnologias como React/React Native e Angular/Ionic, o que possibilita o desenvolvimento com menor esforço e mais padronizado até mesmo de aplicações mobile. Porém, aplicações SPA têm a tendência de possuírem alguns pontos fracos, como justamente o deslocamento do esforço de renderização para o cliente e, em alguns casos, questões de SEO.

Como aplicações SPA funcionam?

De maneira geral, em uma aplicação SPA, o carregamento dos recursos (como CSS, JavaScript e HTML das páginas) ocorre apenas uma única vez: na primeira vez em que o usuário acessa a aplicação. Nesse primeiro acesso, todo o conteúdo HTML, CSS e JavaScript já é transferido para o cliente. A partir deste momento, quando o usuário transitar pelas páginas da aplicação, não será necessário mais fazer requisições para o servidor para a carga dessas novas páginas: o conteúdo relacionado a elas já foi baixado no primeiro acesso. O que acontece nesse momento é que o conteúdo da página é carregado via JavaScript, código este que é justamente gerado com base nos frameworks SPA, como Angular, React e Vue.js. Por isso, dizemos que o processamento do carregamento das páginas e seus respectivos recursos passa para o cliente, já que JavaScript é uma linguagem majoritariamente client side (existem algumas exceções, como quando trabalhamos com Node.js).

Curso JavaScript Intermediário

Conhecer o curso

Neste momento, o servidor fica responsável não mais por renderizar e processar a renderização do conteúdo, mas sim por lidar com os dados a serem manipulados pela aplicação. As operações de persistência em bancos de dados ou a devolução de conteúdo para ser renderizado (como uma lista de clientes, por exemplo) passam a ser exclusivamente da aplicação hospedada do lado do servidor. Atualmente, o que é comum é que o servidor exponha uma API RESTful para ser consumida por uma aplicação SPA. A aplicação SPA se comunica com essa API RESTful através de chamadas HTTP, trafegando dados em formatos como XML e JSON. A aplicação do lado do servidor fica responsável por responder a estas chamadas HTTP, realizando os processos de negócio e de persistência que sejam pertinentes na situação. Essa arquitetura traz uma vantagem muito clara: a separação e isolamento completos do back-end e do front-end. Isso possibilita que duas equipes trabalhem nas duas frentes em paralelo por exemplo, além de permitir esforços mais focados: uma pessoa que lida melhor com aspectos ligados ao front-end pode direcionar todo o seu esforço para tarefas relacionadas ao front-end. O mesmo vale para quem tem mais aptidão ao back-end.

Como e onde utilizar?

Atualmente, aplicações SPA podem ser utilizadas em praticamente todas as situações, o que explica bastante a popularização de frameworks SPA como Angular, React, Vue.js e Ember na atualidade. Porém, existem algumas situações onde frameworks SPA podem não ser tão adequados hoje:

• Aplicações que precisem de SEO extremo podem ter problemas se forem desenvolvidas com frameworks SPA. A maioria dos indexadores hoje conseguem entender aplicações SPA, além de dispormos de uma grande quantidade de meta-tags para melhorar este ponto. Porém, é um trabalho adicional frente à clássica renderização de páginas múltiplas no servidor (também chamado de multi-page application). Esse “probleminha” acontece justamente porque o conteúdo não é renderizado no servidor,, sendo renderizado completamente no cliente. Por isso, os mecanismos de busca podem encontrar dificuldade para indexar o conteúdo das páginas, tendo em vista que eles não podem indexar conteúdo gerado do lado do cliente. Isso explica porque a maioria dos frameworks SPA hoje contam com soluções SSR (Server-Side Rendering), onde pelo menos uma parte do conteúdo é carregado do lado do servidor para favorecer os mecanismos de indexação;

• Aplicações SPA podem ser um pouco mais lentas, principalmente na inicialização. Isso ocorre porque todo o conteúdo precisa ser baixado de uma vez para o cliente no primeiro acesso. Além disso, como todo o processo de renderização passa a ser de responsabilidade do cliente, a aplicação passa a sofrer um pouco com possíveis limitações de hardware de quem a acessa. Porém, obviamente, existem técnicas para mitigar este ponto, como o lazy loading;

• De maneira geral, aplicações SPA precisam que o JavaScript no browser esteja habilitado, embora não seja tão comum hoje em dia que o mesmo seja desabilitado. Também existem técnicas que podem mitigar este ponto, como o próprio SSR;

• Há uma ligeira tendência a aplicações SPA serem menos seguras do que aplicações multi-page renderizadas no servidor, principalmente no que diz respeito a ataques XSS. Porém, de fato, isso na verdade está mais atrelado ao conhecimento do desenvolvedor sobre técnicas para evitar estes tipos de ataques; precauções estas que deveriam ser tomadas inclusive em aplicações renderizadas do lado do servidor;

• Atenção à fragilidade do ecossistema JavaScript. Esse é um ponto bem polêmico, mas é fato que a “instabilidade” de frameworks JavaScript é algo a se considerar. É relativamente comum que você desenvolva uma aplicação com uma determinada versão de um framework SPA, mas seja obrigado a reescrever uma quantidade considerável de código quando precisar atualizar a versão do framework utilizada inicialmente no projeto. Esse é, sem sombra de dúvidas, um fator importante a ser colocado na balança; não só no que diz respeito a utilizar um framework SPA ou um framework MPA, mas também no que diz respeito à decisão sobre qual framework SPA deverá ser utilizado, se for o caso.