Vamos fazer um site para a minha esposa?
Minha esposa tem um perfil no Instagram onde vende produtos de beleza, principalmente produtos do O Boticário.
O processo de venda dela hoje é relativamente simples: ela posta nos stories do Instagram e no WhatsApp os produtos que tem em estoque e as promoções disponíveis.
O cliente vê alguma coisa que gosta, entra em contato e começa aquela sequência de perguntas:
- Qual o preço?
- Tem pronta entrega?
- Quais são as formas de pagamento?
- Esse produto está em estoque?
- Precisa encomendar?
E foi daí que surgiu o pedido:
"Não dá para fazer um site onde eu consiga colocar os produtos que tenho?"
Dá.
E, como bom desenvolvedor, obviamente eu transformei uma pergunta simples em uma discussão sobre arquitetura.
O que o projeto precisava?
Antes de escolher framework, CMS, hospedagem ou qualquer outra tecnologia, tentei entender o que realmente precisava ser resolvido.
O objetivo não era criar um e-commerce.
O cliente não precisava criar uma conta, adicionar produtos ao carrinho ou realizar um pagamento dentro do site.
O site precisava funcionar principalmente como uma vitrine.
Minha esposa deveria conseguir cadastrar e atualizar produtos sem depender de mim, e o cliente deveria conseguir visualizar o catálogo e, caso tivesse interesse, iniciar uma conversa pelo WhatsApp.
Além disso, eu tinha alguns requisitos:
- carregar rápido;
- funcionar bem no celular;
- ter páginas facilmente indexáveis pelos mecanismos de busca;
- permitir que uma pessoa não técnica alterasse o conteúdo;
- manter os produtos atualizados;
- permitir contato pelo WhatsApp;
- e, principalmente, custar o mínimo possível.
A expectativa inicial era de algumas dezenas de acessos por dia e talvez uma ou duas alterações de conteúdo diariamente.
Nada muito assustador.
A solução mais óbvia
Um WordPress.
Sinceramente, um WordPress com um template pronto provavelmente resolveria praticamente todos esses problemas.
Eu precisaria basicamente de um domínio e algum lugar para hospedar o WordPress.
Minha esposa teria um painel administrativo pronto, poderia cadastrar os produtos e o WordPress geraria as páginas.
Fim.
E não teria absolutamente nada de errado com essa solução.
Mas eu queria experimentar uma abordagem diferente.
Principalmente porque nosso site tinha uma característica muito interessante: quase todo o conteúdo muda pouco e não existe necessidade de processamento no servidor a cada acesso.
Foi aí que decidi utilizar uma arquitetura baseada em JAMStack.
A solução que escolhi
A ideia é relativamente simples.
Vamos separar o gerenciamento do conteúdo da aplicação responsável por apresentar esse conteúdo.
Para isso, precisamos basicamente de três coisas:
- um CMS para gerenciar os produtos;
- uma aplicação responsável por gerar o site;
- algum lugar para hospedar os arquivos gerados.
No meu caso, a arquitetura ficou mais ou menos assim:
Prismic → Webhook → Vercel → Build da aplicação → Site estático → CDN
Quando minha esposa cadastra ou altera um produto no CMS, o Prismic dispara um webhook.
Esse webhook inicia um novo deploy na Vercel.
Durante o build, minha aplicação consulta o Prismic, busca os produtos cadastrados e gera as páginas do site.
Depois disso, essas páginas são publicadas e distribuídas pela infraestrutura da Vercel.
Ou seja: quando alguém acessa o site, grande parte do trabalho pesado já foi feito anteriormente durante o build.
O CMS: Prismic
Para permitir que minha esposa gerencie os produtos sem precisar alterar código, eu precisava de um CMS.
Escolhi o Prismic.
Para esse projeto, dois pontos pesaram bastante na decisão.
O primeiro é o plano gratuito, que atende tranquilamente a escala que esperamos ter neste primeiro momento.
O segundo é a possibilidade de configurar webhooks.
Isso significa que consigo dizer:
"Sempre que um conteúdo for publicado, avise a Vercel para gerar uma nova versão do site."
Dessa forma, minha esposa não precisa entender absolutamente nada sobre Git, build, deploy ou qualquer outra coisa relacionada ao desenvolvimento.
Ela altera um produto, publica e pronto.
Claro que existem alguns pontos negativos.
O Prismic não possui um aplicativo mobile dedicado, então o gerenciamento é feito pelo navegador. Além disso, o plano gratuito possui algumas limitações, como a quantidade de usuários.
Para o nosso cenário, isso não é um problema. Temos basicamente uma pessoa administrando o conteúdo.
Se amanhã isso mudar, provavelmente será necessário reavaliar essa escolha.
E o front-end?
Aqui eu não precisava de nada muito mirabolante.
Minha principal necessidade era conseguir gerar páginas estáticas a partir do conteúdo cadastrado no CMS.
Vários frameworks conseguem fazer isso hoje.
Next.js, Astro e Angular são alguns exemplos.
Inclusive, existe um site chamado JAMstack Generators que mantém uma lista enorme de ferramentas que podem ser utilizadas para geração de sites.
Para esse projeto eu escolhi Angular.
Não necessariamente porque Angular seja a melhor ferramenta possível para esse cenário, mas porque é uma tecnologia com a qual já tenho bastante familiaridade.
Se eu estivesse começando esse mesmo projeto hoje com o único objetivo de criar um site estático simples, provavelmente consideraria seriamente utilizar Astro.
Mas esse é justamente um ponto que considero importante em projetos pequenos: nem sempre precisamos escolher a tecnologia teoricamente perfeita.
Às vezes utilizar uma ferramenta que você conhece muito bem permite entregar o projeto mais rápido e com menos problemas.
Onde hospedar?
Agora temos um CMS e uma aplicação capaz de gerar nosso site.
Falta colocar isso em algum lugar.
Como o resultado do nosso build é composto principalmente por arquivos estáticos, nossas opções são enormes.
Eu escolhi a Vercel.
Mesmo o projeto não sendo Next.js, publicar nele continua sendo extremamente simples.
Além disso, consigo integrar facilmente o repositório e configurar o deploy automático.
O fluxo de desenvolvimento ficou assim:
commit na main → Vercel detecta → build → deploy
E o fluxo de conteúdo:
produto alterado no Prismic → webhook → Vercel → build → deploy
São dois caminhos diferentes que terminam exatamente no mesmo lugar: uma nova versão do site publicada.
Por que gerar tudo antes?
Essa é provavelmente a parte que mais gosto dessa arquitetura.
Imagine uma página de um produto.
Nome, descrição, imagem, preço e algumas informações adicionais.
Por que eu precisaria consultar um banco de dados e montar essa página novamente toda vez que alguém acessasse?
Se essas informações mudam poucas vezes por dia, posso fazer esse trabalho uma vez quando o conteúdo mudar.
Durante o build, gero o HTML necessário e publico o resultado.
Depois disso, os arquivos estáticos podem ser distribuídos por uma CDN.
Isso reduz bastante a quantidade de processamento necessário para servir o site e permite entregar o conteúdo a partir de uma infraestrutura geograficamente próxima do usuário.
Isso não significa que SSR seja lento ou que uma SPA necessariamente tenha performance ruim.
Existem caches, CDN, ISR, renderização híbrida e diversas outras estratégias que podem entregar resultados excelentes.
A diferença é que, para esse projeto, eu simplesmente não precisava dessa complexidade.
E o SEO?
Outro benefício importante é ter o conteúdo das páginas disponível de maneira amigável para indexação.
Como o HTML pode ser gerado previamente, mecanismos de busca conseguem encontrar o conteúdo dos produtos sem depender exclusivamente da execução de JavaScript no navegador.
Isso, junto com boa performance, URLs bem estruturadas, metadados corretos e conteúdo relevante, ajuda bastante na construção de um site amigável para SEO.
Claro: utilizar SSG não coloca automaticamente seu site na primeira página do Google.
Se fosse tão fácil, SEO seria uma profissão bem mais tranquila.
Quanto custa?
Essa talvez seja a parte mais interessante.
Hoje, Prismic e Vercel atendem esse projeto dentro dos planos gratuitos que estamos utilizando.
Então nosso único custo recorrente relevante é o domínio.
Eu pago aproximadamente R$ 40 por ano.
É claro que "grátis" sempre precisa vir acompanhado de um asterisco.
Se o projeto crescer, ultrapassar os limites dos planos gratuitos ou começar a exigir funcionalidades diferentes, esses custos podem mudar.
Mas arquitetura também é sobre resolver o problema que você tem hoje sem impedir completamente o crescimento amanhã.
E para algumas dezenas de acessos por dia, eu não tenho motivo para pagar uma infraestrutura preparada para milhões.
O resultado
No final, chegamos a uma arquitetura relativamente simples:
Prismic → Angular → Vercel → CDN
Minha esposa consegue administrar os produtos sem precisar falar comigo.
O cliente consegue visualizar o catálogo e entrar em contato diretamente pelo WhatsApp.
Não temos banco de dados próprio.
Não temos um backend rodando 24 horas.
Não precisamos administrar servidor.
E praticamente não temos custo de infraestrutura neste momento.
Da criação do repositório até a primeira versão publicada, levei algo entre uma e duas horas.
Na verdade, passei mais tempo insistindo para minha esposa cadastrar as informações no CMS do que desenvolvendo, testando, integrando e configurando o deploy.
Talvez essa seja a melhor métrica de sucesso desse projeto.
Quando eu usaria essa arquitetura novamente?
Depois dessa experiência, acho que JAMStack funciona muito bem quando algumas características aparecem juntas.
1. Quando eu não preciso de um backend complexo
Esse é provavelmente o principal ponto.
Perceba que durante todo o projeto eu não falei sobre autenticação, carrinho de compras, processamento de pagamentos ou emissão de nota fiscal.
Isso foi proposital.
O objetivo é apresentar os produtos e levar o cliente para o WhatsApp.
Se amanhã decidirmos transformar isso em um e-commerce completo, provavelmente precisaremos reconsiderar parte da arquitetura.
Pagamentos, usuários, pedidos e dados sensíveis trazem outras responsabilidades.
Principalmente segurança.
E acho que esse ponto merece cada vez mais atenção. Com IA acelerando absurdamente o desenvolvimento de software, ficou muito fácil colocar alguma coisa funcionando no ar.
Mas colocar alguma coisa funcionando não significa necessariamente colocar alguma coisa segura no ar.
2. Quando volume e orçamento fazem sentido
Essa arquitetura é especialmente interessante enquanto conseguimos aproveitar os planos gratuitos ou baratos dos serviços utilizados.
Tráfego alto, isoladamente, não significa necessariamente um problema para um site estático distribuído por CDN.
O problema começa a mudar quando outras necessidades crescem.
Mais pessoas precisam editar o conteúdo?
Temos milhares de páginas sendo geradas?
O build está demorando demais?
Estamos armazenando e entregando uma quantidade enorme de imagens?
Precisamos atualizar informações a cada poucos segundos?
Nesse momento, precisamos fazer novamente aquilo que deveríamos ter feito no começo:
olhar para os requisitos.
Talvez continue fazendo sentido utilizar JAMStack, mas trocar o CMS.
Podemos utilizar algo self-hosted, como Strapi.
Talvez WordPress passe a fazer mais sentido.
Talvez seja hora de desenvolver um backend.
A arquitetura não precisa ser uma decisão eterna.
3. Quando performance e SEO são importantes
Sites institucionais, blogs, portfólios, landing pages e catálogos normalmente possuem uma característica em comum:
a maior parte do conteúdo não muda a cada segundo.
Nesses casos, gerar as páginas antecipadamente pode ser extremamente interessante.
O servidor não precisa reconstruir aquela mesma página do zero para cada visitante.
O trabalho pesado pode acontecer durante o build e o resultado pode ser distribuído como arquivos estáticos.
Além de simplificar bastante a infraestrutura, isso cria uma excelente base para trabalhar performance.
Principalmente quando combinado com ferramentas que evitam enviar JavaScript desnecessário para o navegador.
4. Quando preciso entregar rápido
Esse é outro cenário onde eu colocaria essa arquitetura na minha caixa de ferramentas.
Se preciso publicar rapidamente um site relativamente simples, gosto bastante dessa abordagem.
Não preciso provisionar servidor.
Não preciso configurar banco de dados.
Não preciso desenvolver painel administrativo.
Não preciso manter um processo Node rodando 24/7.
Crio o projeto, conecto o CMS, configuro o deploy e publico.
Nesse projeto, todo esse processo levou poucas horas.
Então JAMStack é melhor que WordPress?
Não.
E talvez essa seja a principal conclusão que tirei desse projeto.
Tecnologia não existe fora de contexto.
Eu poderia ter utilizado WordPress e provavelmente minha esposa estaria igualmente satisfeita com o resultado.
Poderia ter utilizado Astro em vez de Angular.
Poderia ter utilizado outro CMS.
Poderia ter hospedado tudo em outro provedor.
O interessante não é exatamente a combinação Angular + Prismic + Vercel.
O interessante é o raciocínio que levou até ela.
Eu tinha um projeto pequeno, poucas atualizações por dia, pouco tráfego esperado, uma pessoa não técnica administrando o conteúdo e praticamente nenhum orçamento para infraestrutura.
Para esse problema, essa arquitetura fez bastante sentido.
E, no final das contas, arquitetura de software deveria ser justamente isso:
entender o problema antes de escolher a solução.
Outros projetos
Gostei tanto desse modelo que acabei utilizando uma abordagem parecida em outros projetos.
Se tiver curiosidade, também escrevi sobre o processo de desenvolvimento deles:
- Meu site pessoal;
- site do Esporte Clube Vila Ferreira;
- site da Venus Store.
Em cada um deles existem necessidades um pouco diferentes, mas a ideia é a mesma: entender o problema, escolher a arquitetura mais simples que consiga resolvê-lo e evitar adicionar complexidade antes de realmente precisar dela.