Durante a produção de algum projeto, somos acompanhados por uma ferramenta que nos permite depositar a nossa genialidade e mão de obra. Uma boa ferramenta não só prova a sua adequação no mercado atual como também facilita na criação de…
Atualmente é comum nos depararmos com projetos desenvolvidos em vue, react, angular, ou construídos sobre o modelo de SPA, mas você já se perguntou o por quê? Para responder melhor essa pergunta, vamos entender melhor como as coisas funcionam:
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.
Vou te responder com duas outras perguntas:
Basicamente processamento é dinheiro, tanto no servidor, quanto no lado do cliente.
E como melhorar isso?
Construindo uma aplicação baseada em Single Page Application.
Mais 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 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.
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 problema de recarga de informações, quanto o de usabilidade.
*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.
Mais 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 nestes casos?” Sim! Existem várias abordagens para tornar uma aplicação SPA SEO Friendly, como SSR e pré renders. Porém lembre-se, enquanto SPA precisa de tempo e esforço para configurar SSR e então suportar SEO, MPA já possui este recurso “nativo”.
Quando se fala em SPA, o primeiro ponto que precisamos entender é: JavaScript. Tudo passa a tratar-se de javascript, é ele quem vai controlar suas rotas, fazer suas requests, trabalhar os seus dados e sua aplicação vai 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 trata-se 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 post aqui para o Blog da DB1.
E ai, deu pra entender os pontos fortes e fracos do SPA?
Vou ficando por aqui, até a próxima!
