3 coisas que sua ferramenta de deploy de frontend faz sem você saber

Vendo de fora, parece que plataformas de deploy de frontend (Vercel, Netlify, Amplify, etc) só executam código, mas a verdade é que, de CI/CD até distribuição de rede, elas fazem várias coisas que podem mudar como você mantém sua aplicação. Vamos ver o que acontece por baixo dos panos e de quebra deployar nossa própria aplicação do zero com AWS Amplify.

---

Como funcionam as ferramentas de deploy de frontend

Vercel, Netlify, Amplify... hoje em dia existem várias plataformas de nuvem focadas em frontend que auxiliam desenvolvedores a hospedar aplicações web.

Todas funcionam de maneira parecida: você conecta seu repositório de código, clica em deployar (ou algum botão equivalente) e em poucos minutinhos seu site está pronto... mágica!

Muito tranquilo, né? E se eu te contar que por baixo de toda essa simplicidade existem coisas complexas e importantes acontecendo, e que entender elas pode mudar o jeito que você constrói seu sistema...

1) A pipeline de build: o que acontece quando você clica em deploy

Quando você clica em "deployar", a plataforma não pega seu código e joga direto na internet. Antes disso, ela precisa transformar seu projeto naquilo que o navegador do usuário realmente consegue entender: HTML, CSS e JavaScript otimizados, imagens comprimidas, arquivos minificados, etc. Esse processo é o que chamamos de build.

Esse build é feito pelas ferramentas de deploy em um container (imagine como um computador virtual descartável) que a plataforma cria do zero. Quando termina, o container é destruído. No próximo deploy, outro container é criado, e o ciclo recomeça.

Esse processo todo faz parte do que chamamos de CI/CD (Continuous Integration / Continuous Deployment, ou Integração e Entrega Contínuas). Ela é a prática de automatizar os passos entre o código pronto e o código rodando em produção. A pipeline de build conecta tudo isso:

1. Você dá git push no seu repositório
2. A plataforma detecta a mudança
3. Um container novo é criado pra rodar seu build
4. Os arquivos gerados são enviados para os servidores que vão servir seu site
5. Se algo der errado no caminho, é possível reverter pra versão anterior que estava funcionando, chamamos isso de rollback

Por que isso importa?

O ambiente onde seu código é buildado não é o mesmo da sua máquina. E isso é a raiz de um dos bugs mais frustrantes que existem, o clássico "na minha máquina funciona".

O container de build tem sua própria versão de Node.js, seu próprio sistema operacional, suas próprias variáveis de ambiente. Se você estiver usando uma biblioteca que depende de algum pacote a nível de sistema ou se seu .env local tiver uma variável que não existe no ambiente de build, as coisas quebram de um jeito silencioso e confuso. Saber que todo build roda num ambiente limpo e isolado te economiza horas de debug.

Além disso, vale manter em mente que o tempo de build não é de graça. A maioria dessas plataformas cobra por minutos de build, e cada pull request que você abre costuma disparar um preview deployment (um ambiente isolado pra testar aquela mudança). Se seu time tem muitos PRs abertos ao mesmo tempo, isso pode elevar os custos. Entender como configurar cache de dependências (pra não baixar o node_modules inteiro do zero toda vez) pode te salvar de uma conta cabulosa no fim do mês.

2) Hospedagem e rede: onde seu site mora

Seu build rodou com sucesso e agora precisamos deixar os arquivos gerados disponíveis na internet, ou seja, hospedados em algum servidor para poder ser entregues ao usuário.

Como já vimos no artigo sobre como funciona um site na internet, essa entrega envolve várias peças trabalhando juntas:

• Servidor de origem: onde seus arquivos ficam armazenados originalmente
• DNS: para mapear o nome bonito do seu domínio no endereço IP do servidor
• CDN: para manter cópias dos seus arquivos em vários locais do mundo e entregar sempre do mais próximo do usuário
• TLS/HTTPS: para criptografar a comunicação entre o navegador e o servidor (aquele cadeadinho na barra de endereço)

As plataformas de deploy cuidam de tudo isso por você. Você faz push, e elas automaticamente distribuem seus arquivos pela CDN, configuram o certificado HTTPS, apontam o domínio para os servidores certos e ainda fazem balanceamento de carga (distribuir as requisições entre várias máquinas para não sobrecarregar nenhuma).

Por que isso importa?

Porque cache é a fonte número um de confusão em deploys de frontend.

Lembra que o CDN guarda cópias dos seus arquivos em vários pontos do mundo? Isso é ótimo pra velocidade, mas vira um problema quando você faz deploy de uma versão nova. O usuário entra no seu site, e o navegador dele (ou o CDN mais próximo) ainda tem a versão antiga armazenada no cache, portanto continua vendo a versão antiga.

As plataformas resolvem isso com umas técnicas bem específicas, tipo adicionar um hash no nome dos arquivos (app.a7b3f2.js em vez de só app.js), invalidar o cache do CDN a cada deploy e configurar cabeçalhos Cache-Control apropriados. Saber que esse mecanismo existe te ajuda a debugar na hora em que algo der errado e se prevenir de reclamações de usuário de madrugada!

3) Funções serverless: onde entra a lógica do sistema

Quando seu app vai além de páginas estáticas e precisa de lógica no servidor, as plataformas de deploy resolvem isso empacotando esse código em funções serverless.

Serverless (traduzido como sem servidor) é o conceito de subir o código em um ambiente que não terá um servidor sempre rodando, mas que será provisionado sob demanda quando requisitado. Isso traz várias vantagens como pagar apenas pelo tempo em que foi realmente usado, mas também traz seus desafios. Caso queira saber mais sobre serverless, aproveito para deixar meu artigo sobre a verdade oculta por trás do serverless 😉.

Muitas ferramentas, como AWS Amplify, Netlify e Vercel que já mencionamos, usam AWS Lambda, a plataforma de compute serverless da AWS, por baixo dos panos. Você escreve a função, faz push, e a plataforma cuida de todo o resto: provisionamento, escalabilidade automática, gerenciamento dos cold starts, desligamento quando não há requisições.

Por que isso importa?

Quando se desenvolve para um ambiente serverless, existem algumas coisas importantes a se manter em mente.

O primeiro ponto é que não existe estado compartilhado entre requisições. Se você salva alguma coisa numa variável global esperando reusar na próxima chamada, pode ser que funcione (se a mesma função ainda estiver "quente", ou seja, usando a mesma infraestrutura alocada), ou pode ser que simplesmente volte ao estado inicial (se a função estiver "fria" ou se outra instância foi acionada).

O segundo ponto é o cold start, que é justamente a primeira chamada feita em um período que exige que a função reprovisione seus recursos ou "esquente". Essa chamada pode levar alguns segundos a mais, principalmente se o código for pesado. Isso muda como você arquiteta sua aplicação, evitando inicializações pesadas, eliminando dependências desnecessárias e mantendo as funções pequenas.

Por último, é sempre uma boa ideia se atentar a limites de tempo de execução das suas funções assim como limite de memória da execução e payload de transferência de dados por API. Uma transferência de arquivo grande pode funcionar no seu ambiente local, mas pode ser mais lenta ou até falhar dependendo das configurações do ambiente de produção.

Deployando uma aplicação com Amplify

Mas afinal, fazendo tudo isso por baixo dos panos, será que é mesmo fácil e rápido como eu prometi no começo? Vamos pôr à prova...

O que vamos construir

Vamos construir um site para um jogo. Conhece o jogo da cobrinha? Vamos recriá-lo, mas fazendo ele ser multiplayer, porque nada como um pouco de competitividade pra aumentar a emoção e o caos!

Pra quem não conhece o jogo da cobrinha (onde vocês estavam nos anos 2000?), ele é um jogo onde você controla uma cobra formada por bloquinhos. A cobra passeia pela tela comendo maçãs e aumentando de tamanho a cada maçã. Quando a cobra bater no próprio corpo, acabou o jogo.

Nossa versão vai ser inspirada nesse clássico, mas teremos duas cobras em jogo ao mesmo tempo. Uma controlada pelas teclas de seta do teclado e a outra controlada pelas teclas A, S, W, D.

Criando o jogo

Para a parte de código, pedi ajuda para o Kiro para acelerar o processo. Aqui está o prompt que passei para ele:

Quero construir minha própria versão do jogo da cobrinha, criando ele para ser jogado de forma multiplayer. A base do jogo deve funcionar da mesma forma que o jogo tradicional, onde o jogador controla uma cobra na tela, porém com duas cobras representando os dois jogadores que jogam entre si, uma controlada pelas teclas de seta e a outra pelas teclas A (para a esquerda), D (para a direita), W (para cima) e S (para baixo). O jogo acaba quando uma das duas cobras bate a cabeça em uma das paredes da tela, no corpo da outra cobra ou no próprio corpo. O jogador que não sofreu a batida vence. Crie esse projeto com Vite e React no meu diretório CobrinhaMultiplayer.

Note que eu falo com o Kiro em português mesmo, pode ficar tranquilo que ele é poliglota. Note também que apesar de confiar nele para fazer o código, eu tenho domínio sobre o que quero construir e deixo claros os meus requisitos. Além disso, gosto de revisar o código que foi produzido. Sim, linha por linha como faziam os maias e os incas.

Com tudo criado, segui os comandos que o próprio Kiro escreveu no README para rodar localmente

cd CobrinhaMultiplayer
npm install
npm run dev

Note que o caminho na barra de endereço do navegador no print acima diz "localhost", ou seja, está rodando localmente.

Deploy: a hora da verdade

Subi o código para um repositório no GitHub: https://github.com/gi-armani/CobrinhaMultiplayer

Então usei minha conta Free Tier da AWS para fazer deploy com AWS Amplify. Ao criar esse tipo de conta, você ganha 100 dólares em créditos para usar em vários serviços AWS e pode ganhar até 100 dólares em créditos extra à medida que constrói na nuvem. Se quiser saber mais sobre como criar sua conta e as melhores configurações de segurança veja esse artigo.

Segui os seguintes passos para o deploy:

1. Na conta Free Tier, naveguei até o AWS Amplify pela barra de pesquisa
2. Cliquei em "Criar nova aplicação"
3. Embaixo do título "Implante seu aplicativo", selecionei GitHub e cliquei em "Próximo"
4. É preciso dar permissão ao Amplify para acessar o repositório do GitHub. Para isso, cliquei em "Atualizar permissões do GitHub". Isso me redirecionou para a página do GitHub onde dei permissão ao Amplify no repositório do jogo, como na imagem abaixo. Após selecionar o repositório, cliquei em "Save" para salvar

1. De volta na página de criação do Amplify, selecionei o repositório e sua branch principal e cliquei em "Próximo"
2. Chamei minha aplicação de CobrinhaMultiplayer e declarei o comando de build (npm run build) e o diretório de saída (dist) como mostra a imagem abaixo. Cliquei em "Próximo" para seguir

1. Na última página, cliquei em "Salvar e implementar"

Em um minuto, o site estava implementado e acessível de qualquer lugar do mundo com acesso à internet.

Agora o print acima não diz mais "localhost" na barra de endereço, mas aponta para um domínio do Amplify, indicando que a aplicação está deployada!

Conclusão

Agora você já sabe deployar uma aplicação frontend rapidamente e ainda sabe o que acontece por baixo dos panos. Hoje em dia ganhamos muita agilidade com abstrações e as ferramentas de arquitetura e deploy em nuvem são uma parte importante disso, mas saber o que acontece no fundo é o que faz um engenheiro preparado para qualquer problema.

Agora é sua vez! Construa seus jogos nostálgicos preferidos, dê seu toque especial e deploye para acessar de qualquer lugar no mundo!