Nem tudo precisa ser servidor, concorda?
Quando falamos em criar uma aplicação front end nova, principalmente SEO friendly, algumas ferramentas já nos vem a cabeça. Geralmente, para os devs React, é o Next.JS.
O Next.JS em sua configuração padrão, é um framework no qual utiliza Server Side Rendering (SSR) para a criação do site. Disponibilizando de forma fácil a criação de um servidor que serve sua aplicação visualmente.
Além da facilidade da criação de aplicações, hoje nós temos inúmeras plataformas que facilitam a hospedagem de servidores na web. Deixando ainda mais fácil o trabalho de colocar nossos sites (servidores) no ar.
Como no mencionei, no Next.JS a configuração padrão é que seu site seja renderizado no servidor para que todo o conteúdo do HTML seja entregue no navegador na hora do acesso e não dependa apenas do Javascript para exibir o conteúdo. Assim os bots indexadores, como o do google, consegue ler o conteúdo corretamente.
Assim criamos, quase sempre, uma dependência para os sites que precisam entregar um bom nível SEO com um servidor (normalmente em Node.JS). Pois se não entregarmos os conteúdos já renderizados em HTML no acesso do bot e construirmos de forma dinâmica no lado do client (Client Side Rendering), nosso site não terá um bom ranqueamento no google (ou em outras plataformas de busca).
Porém, apesar de simples o ferramental apresentado por esses frameworks, a hospedagem de um servidor hoje não é muito barato, dependendo de onde você queira colocar seu site. Principalmente se estiver procurando por deploys de forma simples e fácil (sem muito desenvolvimento de infraestrutura).
Começamos a falar um pouco em arquitetura do front end.
Muitas vezes quando falamos em arquitetura, pensamos em separação de arquivos ou em como nossa aplicação irá distribuir e consumir dados, como arquitetura Flux ou React Hooks + Zustand. Porém, para mim, o começo de uma discussão da arquitetura do projeto precisa começar pelo modo que iremos exibir a aplicação ao usuário final (+ bots).
Caso a aplicação necessite de ser otimizada para SEO, temos apenas um caminho à seguir, que é entregar um HTML com o conteúdo e não criar o conteúdo dinamicamente. Porém isso não quer dizer que precisamos de um servidor !!!
Antes de mais nada, essa arquitetura que vou descrever a seguir, como sendo menos custosa e mais performática, não se encaixa em alguns cenários, como:
Sites que possuem muitas páginas (com muitas, quero dizer mais de milhares).
Sites que as páginas são criadas dinamicamente a todo momento durante o dia. Exemplo dos e-commerces, onde são cadastrados produtos a todo momento.
No entanto, se seu site não entra em nenhum dos cenários anteriores (exemplo de sites constitucionais com blogs), vai se beneficiar financeiramente (deixando de hospedar um servidor) e irá ganhar em performance!
O nosso objetivo final, para uma aplicação SEO friendly é termos páginas renderizadas como HTML, portanto, não importa se ela for gerada no servidor ou em momento de build. E para isso, o Next.JS possui features para facilitar nossa vida, principalmente para rotas dinâmicas.
Primeiro de tudo é que sua aplicação Next.JS precisará ser "exportável".
.js
module.exports = {
output: 'export'
}Assim, ao gerar um build final, não teremos um servidor Node.js e sim apenas uma aplicação estática (html + JS).
Seguindo o padrão do Next.js, para o framework entender quais página ele precisa construir em build time, temos os seguites métodos para a página ler os possíveis paths e buscar os dados necessários:
No final, o que queremos é que o build da sua aplicação seja algo parecido com isso:
.shell
|--out/
|--_next/
|--static/
|--chunks/ // JS bundle!
|--blog/
|--some-post.html
|--index.html
|--assets
Assim, ao subir em alguma CDN e configurar os rewrites corretamente, teremos uma aplicação 100% estática, de baixo custo,
performática e SEO friendly utilizando as mesmas ferramentas de antes!
Um dos problemas dessa arquitetura, que deve ser considerada como tradeoff é que, para gerar uma nova página, será preciso um novo processo de build & deploy.
Portanto, podemos concluir que antes de pensarmos na arquitetura interna de nosso código (no fluxo dos dados, distribuição das pastas e framewors), devemos pensar em:
Em breve irei escrever sobre como construi este blog e ele custa apenas R$ 40 por ano e como podemos usar outra arquitetura, pensando em custo, para aplicações com páginas dinâmicas com Next.js, porém sem a preocupação com SEO.