Descomplicando SPA’s

Um dossiê sobre o que é, para que serve e quando criar Single Page Applications

Published in

Training Center

15 min readMay 25, 2018

Gostaria de dizer que este é um artigo longo, não decidi dividir em partes, que seria o mais recomendável, pois eu com certeza demoraria para escrever a segunda parte e você não precisa ler tudo de uma vez, salva ai no seu Evernote ou Twitter e volta depois pra continuar lendo ;)

Não é bem esse tipo de SPA que eu estou me referindo

Nesta altura do campeonato, Single Page Applications e frameworks JavaScript são bastante comuns na comunidade, porém eu senti a necessidade de escrever esse “dossiê”, pois vi bastante dúvidas principalmente sobre os problemas que ele resolve e quando utilizá-los.

O objetivo deste artigo é desmistificar e ir bem devagar sobre esse assunto, chegando até pontos avançados do desenvolvimento front-end com Single Page Applications ou frameworks modernos de JavaScript. No final, espero que você entenda o que é, para que serve (qual problema resolve) e quando que devemos utilizar essa técnica. Não irei abordar implementações disso, pois varia de framework para framework (ou de código puro para código puro), e sobre isso você pode encontrar bastante conteúdo online, então citarei alguns livros e cursos que eu já fiz ou já li no final como referência.

O que é uma Single Page Application?

Um aplicativo de página única (em inglês “single-page application”, ou SPA) é uma aplicação web ou site que consiste de uma única página web com o objetivo de fornecer uma experiência do usuário similar à de um aplicativo desktop. Em um SPA, todo o código necessário (HTML, JavaScript, e CSS) ou é obtido com um único carregamento de página, ou os recursos apropriados são carregados dinamicamente e adicionados à página conforme necessário, geralmente em resposta a ações do usuário. A página não é recarregada em qualquer momento do processo, tampouco ocorre a transferência de controle para outra página, embora a URL no navegador ou a API de história do HTML5 possam ser usadas para fornecer a percepção e navegabilidade de páginas separadas ao aplicativo.

Para exemplificar melhor isso, vamos comparar um site convencional com uma SPA, para isso vamos utilizar o site da BBC vs LinkedIn.

O site da BBC é um portal comum, poderia muito bem utilizar o Wordpress (não sei se utiliza, é apenas um exemplo), enquanto que o LinkedIn utiliza o Ember (um framework JavaScript) para construção da sua aplicação.

Repare na suavidade ao navegar entre as páginas do LinkedIn, o mesmo não ocorre no site da BBC.

O primeiro ponto para perceber a diferença entre uma SPA e uma aplicação convencional, é como é feito o carregamento de suas páginas ao clicar em um link interno. Em uma SPA, esse carregamento é muito suave, simulando um app de celular, enquanto que em uma aplicação convencional, existe uma tela branca, isso ocorre pois ao clicar no link, o seu navegador faz uma nova requisição para o servidor, o servidor por sua vez retorna essa requisição com uma nova página web completa. O mesmo não ocorre na SPA, pois o conteúdo é carregado progressivamente (por meio das famosas API’s). Já o esqueleto das páginas, pode ocorrer de duas maneiras:

É carregado todo o esqueleto logo na primeira requisição (este é o caso mais comum). O problema desse caso é que dependendo do tamanho da sua aplicação, o arquivo que é baixado é muito grande, o que acaba deixando a aplicação um pouco lenta.
O esqueleto é carregado progressivamente (mais complexo). Nesse caso o problema anterior não existe, porém ele é um pouco mais avançado de ser executado e para quem está começando não vai ver isso sendo aplicado logo de cara.

Eu preciso fazer um disclaimer aqui antes de prosseguirmos: também é possível que uma aplicação convencional faça um carregamento semelhante ao de uma SPA. O YouTube é um ótimo exemplo disso. Entretanto, falarei mais sobre isso lá para o final do artigo, onde eu dou diversos exemplos e técnicas que são utilizadas tanto por SPA, como por aplicações comuns.

Na BBC, as tags do HTML são retornadas pelo servidor, enquanto que no LinkedIn as mesmas existem em menor quantidade (já que é o JavaScript quem faz essa manipulação)

Outra técnica possível de ser utilizada para detectar uma Single Page Application ou não, é visualizar seu código fonte, você pode ver isso normalmente segurando as teclas CTRL + U , neste caso em um código de uma SPA, as tags do HTML possuem em menor quantidade e são adicionadas conforme a necessidade pelo Javascript, diferente de uma aplicação convencional, onde o HTML é renderizado pelo servidor e o Javascript tem menos peso nas mudanças da página.

Isso ocorre pois em uma aplicação convencional, o servidor retorna uma página HTML sempre que você navega de uma página para a outra, isso implica que ele vai de fato “buildar” (construir no bom e velho português) sua aplicação para renderizar o HTML. Já em uma SPA, quem controla tudo isso é o JavaScript, que “appenda”, isto é, adiciona o HTML a página inicial baseado no que foi programado.

Uma outra técnica um pouco mais simples é observar na guia Network do console do navegador. Se a cada troca de página houver uma requisição para um HTML então não é SPA.

As duas técnicas são boas, como tudo na vida, cada uma possui prós e contras e vamos falar agora sobre isso.

Para que servem as SPA’s?

“A macro shot of power lines in a cloudy white sky” by Cameron Kirby on Unsplash

Antes de tudo, ambos os métodos de desenvolvimento tem seus prós e contras, tentarei listar aqui alguns prós e contras e na próxima sessão falarei sobre o meu ponto de vista de quando você deve optar por uma SPA e quando você deve seguir modelos tradicionais.

Single Page Application

Prós:

Melhor experiência de usuário
Performance (pode ser uma vantagem e uma desvantagem, depende de vários fatores)
Responsabilidade maior para o front-end (possibilitando melhores otimizações e trabalho em cima da aplicação)

Contras:

Curva de aprendizado pode ser meio complexa no início
SEO não é tão simples de resolver como em uma aplicação convencional
Performance pode ser um problema se mal otimizado

Os prós se resumem a uma melhor experiência de usuário, pois com uma SPA o JavaScript ganha muito poder, isso facilita para entregar sempre interfaces mais agradáveis e uma usabilidade melhor. Outro ponto interessante é que dessa maneira existem pelo menos 2 projetos, o back-end e o front-end, que normalmente são administrados por pelo menos 2 profissionais diferentes, isso possibilita um foco melhor nas responsabilidades de cada um.

O principal contra é a questão de SEO (otimização para mecanismos de buscas), isso acontece pois como é o JavaScript quem cuida da renderização total da tela, os robôs não conseguem ler o que existe na tela (pois não existem as tags do HTML, como mostrado no exemplo da BBC vs LinkedIn). Dependendo de onde será utilizado seu sistema e por quem, isso é um grande problema. Voltaremos a falar melhor sobre isso mais abaixo.

Aplicações convencionais

Prós:

Tempo de carregamento da página normalmente é menor
SEO funciona bem desde sempre
Existe até mesmo DÉCADAS de conhecimento sobre o assunto (variando de linguagem para linguagem e de framework para framework)

Contras:

Muito fácil do projeto virar um monolito gigante que é muito difícil de dar manutenção, principalmente no front-end
Não possibilita um domínio completo do front-end, normalmente o projeto é feito por desenvolvedores full-stack, e o foco é grande no back-end, o que prejudica um pouco a usabilidade

Se for analisar cruamente, não faria o menor sentido haver essa divisão. E realmente em alguns casos não existe a necessidade mesmo. Esse é um ponto que francamente, não vejo muitas pessoas comentando (desenvolvedores front-end). Acredito que muito disso se deve ao hype que existe em torno do desenvolvimento front-end moderno.

O meu objetivo com esse artigo é de fato desmistificar esses pontos, porém só você pode dizer se vale a pena ou não utilizar essa técnica. E as vezes essa resposta não é fácil de se dar, e pode ser que você vai cometer o erro de adotar quando poderia não ter adotado e vice-versa.

Quando criar uma Single Page Application?

“Hora do show, porra!” - Photo by Eric Ward on Unsplash

Agora que já sabemos o que é e qual problema resolve, vamos falar dos momentos onde EU acho que deve ser desenvolvido uma SPA e quando não. Óbvio que eu não sou o senhor da razão, e podem haver Dev’s que vão discordar de mim. Porém, acredito que pode ser tomado como base para quem está começando, principalmente.

Nessa parte, eu decidi dividir por tópicos, onde vou dar um motivo para utilizar e explicar se eu acho ou não esse motivo de válido e o por que eu acho isso.

“Todo mundo desenvolve agora em SPA, não quero ficar para trás”

Esse é um motivo bem interessante e bastante válido. O problema aqui é que muitos desenvolvedores não percebem que na realidade eles trabalham para uma empresa. E pode ser que a empresa não precise desse tipo de solução, pois ela não possui um problema que uma SPA resolve.

Temos sempre que ser profissionais, e pensar friamente como profissionais. Se a sua empresa estiver em um momento de refatoração e você encontrar motivos suficientes para utilizar uma SPA, vá em frente. Do contrário, sugiro ou mudar de empresa, ou desenvolver projetos pessoais para aprender sobre o conteúdo e se aprofundar. Mas não prejudique seu time por uma decisão pessoal sua :)

“A empresa/projeto onde trabalho está migrando códigos antigos, queria aproveitar e migrar para SPA”

Sempre que escuto afirmações minimamente parecidas com essas, eu sempre pergunto o que a empresa/projeto faz e quem ela atende.

Em via de regra e para facilitar aqui o artigo, eu costumo dizer que se a aplicação que você está desenvolvendo é um dashboard, ou seja, possui login e senha e é fechado para usuários internos. Pode usar SPA sem medo de ser feliz, lembre-se somente dos prós e contras.

Se a aplicação é um blog, ou uma loja virtual, ou algo que precise estar muito bem posicionado no Google (não apenas a página inicial, mas várias outras páginas). Ai nesse caso, eu não recomendo utilizar uma SPA. Pois isso pode te atrasar bastante, principalmente se estiver começando. Existem soluções para esse caso, e irei abordar mais para frente em tópicos um pouco mais avançados.

No caso anterior, também é possível fazer um misto, caso o seu site tenha até umas 20 páginas e seja estático, ou seja, não possui conteúdo carregado de um servidor back-end e também possua um dashboard com login e senha. Para esses casos, recomendo criar páginas estáticas de conteúdo para a parte do site que precisa estar no Google, e o dashboard pode ser feito como uma SPA. Um bom exemplo de site que aplica algo parecido com isso é o Sendgrid, ele possui um site normal que rankeia (fica em boas posições) no Google, porém a SPA em si, fica neste link.

“Sou o(a) único desenvolvedor(a), é melhor utilizar SPA ou métodos tradicionais?”

Este é um caso difícil. Honestamente, se você desenvolve sozinho(a), manter duas aplicações (uma API e uma SPA), vai te dar um trabalho bem grande. Para este caso, eu recomendo desenvolver utilizando PHP/Laravel, Ruby on Rails, Django (Python), Node (com Sails.js) e linguagens mais tradicionais mesmo. O motivo disso é que realmente vai te dar um certo trabalho manter essas duas aplicações, enquanto que em plataformas mais tradicionais é bem mais fácil gerar telas e CRUD’s (que são ações como adicionar, ler, excluir e editar informações e dados no banco de dados). Em uma SPA, você precisa fazer todas as interações uma a uma, porque a SPA não sabe como está sua API, então isso torna o trabalho mais demorado, além das configurações iniciais e otimizações que podem e devem ser feitas em SPA. Por isso, a necessidade de um desenvolvedor que cuide somente do Front-end.

“Gostaria de dividir as responsabilidades para back-end e front-end e uma aplicação SPA ajudaria bastante nisso”

Esse foi o meu motivo para iniciar. Acredito que é um bom motivo para utilizar uma SPA, pois dessa maneira você de fato mantém duas aplicações com desenvolvedores apenas trocando necessidades e conhecimento de regras de negócio. Aqui na Cotabox, mantemos dessa maneira, porém no nosso caso não utilizamos uma SPA, mas sim uma aplicação que utiliza um framework SPA, porém renderiza no servidor (explicarei sobre isso mais abaixo).

Um problema que esse motivo trás, é que a infraestrutura fica mais difícil de dar manutenção. Pois existem 2 deploys diferentes. Na maioria das vezes maquinas diferentes rodando as aplicações, e no caso específico da Cotabox, as duas maquinas rodam Node e são aplicações um tanto quanto complexas. Eu como desenvolvedor(a) front-end, tive que aprender a trabalhar bem com o Node e montar uma maquina e dar manutenção nela, já que o Léo, que é o desenvolvedor back-end, faz isso na parte dele e nossa equipe é somente nós dois e um estagiário.

Resumão

Então, apenas recapitulando alguns pontos. Na minha opinião, você deveria criar uma SPA, quando:

Quer criar uma aplicação moderna, que possui uma UX melhor e mais leve.
Possui um time que pode ou já é dividido entre pessoas exclusivas para back-end e front-end.
Quer dar mais performance no front-end, pois com a divisão de responsabilidades, os devs front-end podem dar mais ênfase nessa parte. Pois, vai de encontro com o primeiro motivo.

Você não deveria criar uma SPA, quando:

Trabalha com uma loja virtual, blog ou qualquer coisa que precisa de um bom posicionamento no Google e NÃO possui muita experiência com SPA.
É o único desenvolvedor do projeto
Não possui muita experiência com JS puro (recomendo aprender JS bem antes de criar uma aplicação que vá para produção, não precisa ser um Jedi, mas é sempre bom ter conhecimento da linguagem)

É claro, que cada caso é um caso. Não necessariamente você precisa de uma SPA para ter os benefícios citados acima. E para exemplificar melhor isso, vou listar empresas que utilizam SPA’s, que não utilizam SPA’s, porém possuem uma navegação e performance BEM semelhante a uma, e empresas que de fato, não utilizam nada parecido com uma SPA.

Exemplos de aplicações

SPA’s

Os exemplos para empresas que utilizam SPA’s são diversos:

Netflix: com exceção da página inicial e páginas externas, toda a aplicação da Netflix é feita utilizando React. O que faz total sentido, já que é um catálogo que fica depois de um login e senha e não precisa ser indexada no Google.
Airbnb: outro bom exemplo que utiliza também React. A aplicação da Airbnb é um pouco mais complexa que a da Netflix, pois algumas coisas eles precisam renderizar no servidor (por questão de SEO) e outras não.
Twitter: o Twitter para mim é uma incógnita, achei esse link no Quora, explicando um pouco sobre a stack front-end deles, minha opinião é que eles utilizam alguma técnicas semelhante a da Cotabox, Airbnb e tal, que mescla SPA com aplicações convencionais.
Gmail/Google: O Google possui uma das arquiteturas mais doidas, que também mescla tudo isso que eu já citei. Eles utilizando o framework próprio Closure na maior parte das aplicações deles. Também achei um link de uma talk com um desenvolvedor falando sobre desenvolvimento JavaScript gigantescas, iguais as dele.

Não são SPA’s, mas incorporam elementos de uma

Essas aplicações, não são totalmente SPA’s, mas incorporam muitos elementos de uma e fazem de certa maneira uma mescla:

Youtube: O Youtube é feito em Python, em uma estrutura MVC, porém o próprio Youtube criou um framework JavaScript chamado SPFJS, a ideia é a mesma utilizada na Cotabox, primeiro é renderizado o conteúdo do servidor, depois disso o JavaScript “hidrata” a tela, ou seja, quando navegar entre páginas, somente o que é mudado é solicitado ao servidor, que quando recebe o conteúdo, adiciona a tela da mesma maneira que um React/Vue.js/Angular fazem normalmente.
Facebook: Esse aqui já nem da pra perceber o que é, do que não é.
Github: O Github utiliza Ruby On Rails, e apenas utiliza JavaScript para melhorar a experiência do usuário.

Definitivamente não são SPA’s

Esse aqui foi até difícil de lembrar, são sites que utilizam poucos, ou quase nada de JavaScript:

The New York Times: Eu não vejo nenhum motivo para isso mudar.
G1
BBC
Sites que utilizam Wordpress no geral

Como desenvolver uma SPA

Como eu disse lá em cima, não irei criar um projeto e ensinar de fato como desenvolver uma SPA, a ideia aqui é falar sobre o que é mais utilizado atualmente para desenvolvimento de SPA’s.

Basicamente hoje (2018), existem 3 grandes frameworks para desenvolvimento de SPA’s, são eles: React, Vue.js e Angular.

Existem prós e contras em cada um deles, com guerras e mais guerras para decidir qual é o melhor. Eu recomendo ler artigos específicos de cada um deles e tirar suas próprias conclusões. Tem também essa live do Training Center com um bate papo sobre o assunto.

Aqui na Cotabox, nós escolhemos o Vue.js, o motivo para isso é que ele possui uma curva de aprendizado bem baixa. É extremamente performático. E como é conhecido, possui o melhor do React e o melhor do Angular.

Nem tudo são flores, o Vue.js possui diversos problemas que sua utilização também trouxe. Porém, não vem ao caso citar todos aqui.

Teste todos, pelo menos um projeto básico em cada um deles para sentir e escolher um favorito. Qualquer uma trará pontos bons e ruins. O importante é resolver da melhor maneira o problema que você está tentando resolver.

Como desenvolver uma aplicação que parece uma SPA, mas não é

Se o seu objetivo é apenas entregar uma melhor experiência de usuário para o seu usuário. Eu não acho que seja um motivo forte o suficiente para trocar uma stack inteira de tecnologia para uma SPA.

Para isso, eu recomendo a biblioteca que o próprio Youtube utiliza, para entregar uma experiência de quase SPA, porém, com renderização ainda do servidor.

Como eu disse ali em cima, essa biblioteca faz algo conhecimento como hidratação, a ideia é que o primeiro request é feito normalmente pelo servidor e quando o usuário navega na aplicação, o conteúdo é atualizado pelo Javascript, possibilitando uma experiência mais fluída e semelhante a uma SPA.

É possível também somente utilizar React e Vue.js em página específicas. Isso acontece pois ambos são apenas bibliotecas, ou seja, para se tornarem Single Page Applications precisa ser utilizado outras bibliotecas complementares, como o vue-router ou react-router, que são responsáveis por navegar entre páginas. Sem essas bibliotecas complementares, é possível utilizar essas bibliotecas para fazer manipulações em partes específicas da tela, por exemplo.

Como desenvolver uma aplicação Universal/Server-side Rendered

Aqui na Cotabox, uma parte do nosso sistema pode ser uma webapp SPA, enquanto que outra (o site), precisa ser renderizada no servidor por questões de SEO. Por conta disso e a equipe ser pequena. Decidimos utilizar uma aplicação universal.

Nós utilizamos Vue.js, mas tanto React, quanto Angular possuem técnicas equivalentes para se construir uma aplicação universal.

O que é uma aplicação universal?

Uma aplicação universal, server-side rendered ou isomórfica. Nada mais é que uma SPA que renderiza tanto no servidor, como no front-end.

Na primeira chamada ao servidor, os códigos são “compilados” para HTML, CSS e JS, padrão. Porém, ao navegar ou requisitar outras funções no browser, a tela é hidratada, ou seja, o conteúdo passa a ser administrado pelo framework, e não pelo servidor somente. Por isso é chamada de Universal, pois o mesmo código está rodando tanto no servidor, como no browser. Seu uso é bem parecido com o tópico anterior. Porém, aqui existem técnicas específicas para cada framework, onde você constrói uma infraestrutura que roda somente em cima do Vue.js, ou do React ou do Angular.

Geralmente, construir uma infraestrutura dessa era extremamente complicada. Porém, foram criados frameworks que facilitam isso. Esses frameworks são wrappers (utilizam a base do Vue.js, ou do React ou do Angular), para construir uma aplicação web.

Para o React, existe o Next.js, o Vue.js com sua ótima fama de copiar o que tem de melhor, possui o Nuxt.js (haha) e o Angular possui o Angular Universal.

É possível construir também a infraestrutura do zero, porém eu não recomendo para quem está começando porque é realmente bem complexo. Aqui tem um tutorial explicando o processo em Vue.js.

Considerações Finais

O objetivo desse artigo foi exemplificar e desmistificar as razões para se utilizar uma SPA. Servindo mais como uma reflexão do que propriamente um exemplo de como fazer, pois isso existe bastante.

Realmente acredito que as pessoas deveriam se perguntar mais o por que estar adotando tal tecnologia. E me incluo nessa lista. Pois nem tudo são flores, e as vezes esse monte de coisas pode acabar mais atrapalhando do que ajudando.

Qualquer feedback é bem vindo, caso eu tenha cometido algum erro, é só deixar nos comentários!

Se você tiver alguma dúvida e quiser que eu dê minha opinião ou te ajude com seus casos em específico, pode me chamar no Twitter, Facebook ou Telegram (@kavalcante), se quiser você pode me enviar um e-mail também: contato@kavalcante.com.

Além disso, deixarei algumas referências para estudos, são podcasts, livros e artigos interessantes sobre o assunto que eu já li/ouvi e me ajudou de alguma maneira:

Queria agradecer as pessoas que me ajudaram revisando e lendo este artigo previamente: Leonardo Turbiani, Bruno Agutoli, William Oliveira, Lucas Santos e Vinicius Rossi.

Obrigado, e até a próxima :)