Atualmente, é comum nos depararmos com projetos desenvolvidos em Vue, React, Angular, ou construídos sobre o modelo de SPA, mas você já se perguntou por quê? Para responder melhor essa pergunta, vamos entender melhor como as coisas funcionam:

MPA – Multiple Page Application

Modelo convencional de construção de software front-end. Sempre que abrimos uma página na internet, as informações apresentadas na tela são carregadas de algum lugar, seja uma imagem, um vídeo, ou um json. Tudo vem de algum lugar, tudo chega ao usuário através de uma request.

Se você quiser visualizar o impacto que isso gera, entre em um site qualquer, abra o devtools do seu navegador (tecla F12, geralmente), vá até a guia Network e atualize a página. Cada item presente nessa seção é uma request que foi processada e solicitada pelo browser.

Agora imagine que sua aplicação precisa exibir a informação do usuário logado em todas as páginas. A página é acessada, a solicitação é disparada, o banco de dados é consultado, o resultado é formatado e então exibido para o usuário.

Após isso, ele navega para outra página, e o fluxo descrito acima é executado novamente, e novamente para cada página que for carregada.

E por que isso é ruim? Vou te responder com duas outras perguntas:

Você está acessando um software pelo 3G/4G do seu celular. Você prefere que os dados sejam recarregados a cada nova operação que você faz, consumindo tempo e dados do seu pacote, ou que sejam carregados uma vez e recarregados apenas se necessário?

Você publicou um software na nuvem, e o mesmo possui um limite de 30GB de transferência de dados mensais. Você prefere gastar esses 30GB da melhor maneira possível, ou gradativamente com flood de informações repetidas?

Basicamente, processamento é dinheiro. Tanto no servidor, quanto no lado do cliente. E como melhorar isso? Construindo uma aplicação baseada em Single Page Application.

Single Page Application

Mas e se minha aplicação tiver mais de uma página?

Calma, não é bem assim que funciona. Single page application quer dizer que o browser vai renderizar o core da aplicação apenas uma vez – todas as outras informações serão carregadas por demanda, de acordo com a necessidade do usuário.

Além de gerar menos custos para renderizar a página, o modelo SPA ainda oferece uma melhor experiência para o usuário, pois o mesmo não terá que ver a página recarregando completamente inúmeras vezes.

Também podemos adotar estratégias de caching, como service workers (futuramente farei uma postagem abordando esse assunto), para otimizar ainda mais a performance da aplicação.

Ainda é possível compilar a mesma aplicação para Desktop ou Mobile utilizando ferramentas como Electron ou Cordova, tendo então uma aplicação multiplataforma com um único código fonte.

Quando falamos de front-end, naturalmente falamos de Javascript, e criar uma aplicação num modelo SPA é o melhor custo benefício. Existem excelentes frameworks SPA como, por exemplo: VueJs, React e Angular. E é muito mais fácil desenvolver uma aplicação utilizando tais frameworks.

Mas tome cuidado, SPA não é bala de prata. Não é uma solução que resolve qualquer problema – existem alguns pontos que você deve tomar cuidado:

Como o conteúdo da aplicação é carregado por demanda, isso quer dizer que tudo é carregado em tempo de execução: as famosas requests ajax. E qual o problema disso? Motores de busca captam apenas as informações de conteúdos estáticos, carregados pelo server side.

Ou seja, se a sua aplicação necessita de SEO, sugiro que esteja preparado para trabalhar com SPA SSR (Server Side Rendering*), ou trabalhar com MVC/MPA. Depende muito do seu conhecimento e do tamanho do projeto.

SSR é aquilo que é carregado previamente, antes de chegar até o navegador. Se você abrir um site e ir até o menu Exibir > Código Fonte, geralmente CTRL + U no seu navegador, o conteúdo que você verá nesse momento será aquilo que foi carregado pelo servidor, e é esse o código que os motores de busca enxergam.

Existem também aplicações “híbridas”. É comum encontrar e-commerces que tratam toda a parte de produto como MPA, e a parte de carrinho, cadastro e checkout como SPA. Isso é uma forma comum de resolver tanto o problema de recarga de informações, quanto o de usabilidade.

Mas então, quando usar SPA e quando não usar?

Comece avaliando o conhecimento tecnológico da sua equipe, pois o melhor modelo para construir um software é aquele que sua equipe domina, e não o que está mais no hype.

Porém, é sempre legal conhecer coisas novas, e a curva de aprendizado de SPA e seus frameworks é relativamente baixa. Seu projeto tem tempo para aprendizado? Se sim, pense em começar com SPA. Se não, siga pelo seguro.

Meu projeto é pequeno, tudo bem eu utilizar MPA? Sim, e não. Primeiro que um projeto pequeno pode rapidamente crescer e tornar-se um grande projeto, e segundo que, ainda que seja pequeno em números de funcionalidades, pode ser grande em fluxo e tráfego de acessos.

Devido a esses fatos, acredito que o tamanho do projeto não deva interferir nessa decisão, e sim o que é o projeto. Isso vai te ajudar a decidir se é melhor utilizar SPA ou MPA.

“Meu projeto precisa de um certo foco em SEO. É possível utilizar SPA nesses casos?” Sim! Existem várias abordagens para tornar uma aplicação SPA SEO Friendly, como SSR e pré renders. Porém, lembre-se do quanto o SPA precisa de tempo e esforço para configurar SSR e então suportar SEO. MPA já possui este recurso “nativo”.

E como começar a trabalhar com SPA?

Quando se fala em SPA, o primeiro ponto que precisamos entender é: JavaScript. Tudo passa a se tratar de JavaScript. É ele quem vai controlar suas rotas, fazer suas requests, trabalhar os seus dados e sua aplicação passará a ter mais poder e autonomia.

Embora SPA tenha suas desvantagens, existem muitas razões para querer usar. Não é à toa que é o modelo de aplicações front-end mais utilizado da atualidade. E o legal é que como se trata de JavaScript, a comunidade por trás disso é gigantesca.

Existem inúmeros frameworks destinados a trabalhar com SPA, porém, atualmente destacam-se três: VueJs, React e Angular.

A curva de aprendizado desses frameworks varia de acordo com seu conhecimento em JavaScript (ES5) e EcmaScript 6. Entre eles, eu particularmente recomendo o VueJs por possuir a menor curva de aprendizado e por outros motivos que irei abordar em outro artigo aqui no iMasters.