Site estático, frontend e backend

Dois sites na tela. O primeiro é uma página com um jogo: campo, placar, botão "de novo". O segundo é a página de uma oficina com um formulário "deixar pedido". Os dois abrem no navegador, os dois são feitos de HTML, CSS e JavaScript, os dois parecem prontos. O primeiro é publicado em um minuto: a pasta vai para a hospedagem, o link já está pronto. No segundo, o agente provavelmente vai parar e perguntar onde vai ficar o servidor e onde salvar os pedidos.

A diferença não está na complexidade nem na beleza. Está em quem precisa fazer algo quando o visitante clica no botão, e onde os dados devem ficar depois disso. Vamos analisar três palavras - site estático, frontend e backend -, ver onde os dados moram e por que a forma de publicação depende disso. No final, vamos ver o que o agente pergunta sozinho antes mesmo de o(a) senhor(a) pedir "publique", e o que vale a pena perguntar a ele.

1. Site estático

Site estático é um site feito de arquivos prontos: index.html, style.css, scripts, imagens, fontes. O servidor os guarda e entrega os mesmos arquivos a cada visitante, sem calcular nada e sem guardar nada sobre os visitantes. Todo o trabalho - mostrar, calcular, reagir a um clique - é feito pelo navegador do visitante no computador dele.

Vamos pegar um portfólio de uma página só. Na pasta ficam o index.html com uma apresentação pessoal e a lista de trabalhos, o style.css, uma dezena de imagens e um pequeno script. O visitante abre o link, o navegador baixa os arquivos e monta a página a partir deles. Clicar num trabalho abre a imagem maior, o botão de tema escuro troca as cores: isso é feito pelo script no navegador. Depois de entregar os arquivos, o servidor não participa mais do que acontece: para ele, não importa quem veio nem o que clicou. Surgiu um novo trabalho - o(a) senhor(a) edita o index.html, coloca a imagem ao lado e publica a pasta de novo; não existe outra forma de mudar algo aqui, e quem muda o site é o(a) senhor(a), não o visitante.

Funcionam do mesmo jeito:

• o cartaz de um show ou encontro: data, local, programação, mapa de como chegar; o botão "comprar ingresso" leva ao site de quem vende os ingressos, o próprio cartaz não vende nada;
• a landing page de um produto ou serviço, se em vez de formulário ela tiver telefone e e-mail;
• a documentação de um projeto: dezenas de páginas com menu e links entre si, e mesmo assim continuam sendo arquivos;
• um blog sem comentários: cada post é um arquivo, e um novo é publicado do mesmo jeito que todo o resto;
• um jogo no navegador. Sim, o jogo também: jogadas, placar e animação são calculados no navegador, o servidor não tem nada a ver com isso.

Onde o site estático termina fica claro quando se divide o trabalho do site em duas metades: a que o navegador faz e a que o servidor faz. Essas duas metades têm nomes.

2. O frontend funciona no navegador

Frontend é tudo que roda no computador do visitante: marcação, estilos e scripts que o navegador recebeu e executou ali mesmo, nesse computador. A "parte da frente", a que se vê. (Muitas vezes chamam isso de "só o layout", mas na verdade é toda a parte do site com a qual a pessoa interage, e num site estático é o site inteiro.)

O frontend sabe fazer muita coisa: mostrar a página, calcular jogadas num jogo, verificar antes de enviar que um campo do formulário não está vazio, guardar algo até a próxima visita - para isso o navegador tem o seu próprio armazenamento, que o agente vai chamar de localStorage. O que ele não sabe fazer é compartilhar. O armazenamento existe naquele navegador, naquele dispositivo, e em nenhum outro lugar. Onde essa fronteira atrapalha e onde não atrapalha fica claro em dois exemplos.

O melhor placar do jogo. A partida terminou, o script comparou o resultado com o recorde anterior e gravou o novo no armazenamento do navegador. Amanhã o jogador vai abrir a página no mesmo navegador, no mesmo notebook - o recorde está lá. Vai abrir no celular - lá está vazio, o celular tem o seu próprio armazenamento. O(a) senhor(a), autor(a) do jogo, nunca vai ver esse recorde. E não tem problema: ele só interessa ao próprio jogador, e o site continua estático.

O pedido da oficina. O cliente descreveu o que precisa ser feito, deixou o telefone, apertou "enviar". O script pode verificar se os campos foram preenchidos, mas depois disso não tem para onde ir: se gravar o pedido no armazenamento do navegador, o pedido vai ficar no celular do cliente, e a oficina nunca vai saber dele. O pedido precisa ser lido por outra pessoa em outro dispositivo, então os dados precisam sair do computador do cliente, e do outro lado alguém precisa recebê-los e guardá-los. Um site feito só de arquivos não tem esse "alguém".

Tudo que diz respeito a um único visitante num único dispositivo, o frontend resolve sozinho. O resto é trabalho da outra metade.

3. O backend funciona no servidor

Backend é um programa que roda no servidor e responde às requisições dos navegadores. Receber um pedido e salvá-lo. Verificar login e senha. Entregar a lista de produtos. Ele funciona mesmo quando o visitante já fechou a aba, e precisa ficar rodando o tempo todo, assim como o próprio servidor - um computador que não se desliga.

No esquema, dois caminhos com a mesma forma: clique, trabalho, resultado. Eles se diferenciam pela plaquinha do meio - quem faz o trabalho e o quê exatamente. Em cima, depois de uma jogada, o JavaScript no navegador calcula o placar, salva o recorde e redesenha o campo, tudo isso no computador do visitante. Embaixo, o clique em "enviar" vira uma requisição, a requisição vai para o servidor, o programa a recebe, salva o pedido ali mesmo, no servidor, e responde ao navegador, e é essa resposta que aparece na tela. Onde exatamente o pedido fica guardado no servidor é assunto da próxima seção. A pergunta "quem faz o trabalho" é justamente a fronteira entre os dois tipos de site.

Três sinais claros de que não dá para passar sem backend:

• login por senha: alguém precisa guardar as senhas e verificá-las, e isso não pode ser o navegador do visitante;
• dados que outras pessoas precisam ver: comentários, pedidos, uma lista compartilhada;
• uma ação em nome do(a) senhor(a): enviar um e-mail, processar um pagamento, gravar algo num serviço de terceiros usando a sua chave.

A linguagem do backend pode ser qualquer uma: JavaScript (aí é Node.js), Python, Java, mais uma dezena de outras. Para este material o importante não é isso, e sim que o programa precisa rodar em algum lugar de forma constante, e esse "algum lugar" não é o navegador. O endereço do site leva a um ponto no servidor, assim como no site estático, só que nesse ponto agora não há um arquivo, e sim um programa que monta a resposta na hora.

4. Onde os dados moram

São os dados que decidem quem deve fazer o trabalho depois do clique: onde eles ficam e quem deve vê-los. Não é a aparência do site nem a sua complexidade. São três lugares.

Nos arquivos do projeto. O texto da página, as imagens, as regras do jogo. São iguais para todos os visitantes e só mudam com um novo deploy: corrigiu o arquivo, publicou de novo.

No navegador do visitante. Configurações, melhor placar, rascunho de formulário que não se quer perder ao recarregar. Só aquele visitante, naquele dispositivo, vê esses dados. Eles desaparecem ao limpar os dados do site, não existem numa janela anônima, nem em outro navegador ou dispositivo, e o(a) senhor(a) não fica sabendo de nada disso.

No banco de dados do servidor. Pedidos, comentários, contas. Veem todos que devem ver, e o(a) senhor(a) também. Existem independentemente de alguém ter uma aba aberta. Para algo chegar lá, é preciso um programa no servidor que receba os dados e os grave.

No esquema estão os mesmos dois mundos de antes, só que agora dentro deles há dados, e não quem faz o trabalho. Os arquivos do site viajam como cópia para cada visitante, por isso a página é a mesma para todos. O armazenamento do navegador é a única plaquinha sem setas: os dados estão lá, mas não saem do dispositivo, e o(a) senhor(a) nunca vai vê-los. No banco de dados, os dados só entram através do programa, mas lá eles ficam visíveis para todos que devem vê-los.

Em vez de teoria, faça uma única pergunta: outra pessoa precisa ver o que este visitante digitou? "Guardar o melhor placar" - não, então é armazenamento do navegador, e o site continua estático. "Salvar um pedido" - sim, então é banco de dados e um programa que grava nele. Essa pergunta tem uma exceção, e ela não é sobre dados: a chave de um serviço de terceiros. Se existe uma chave, a resposta "não" não resolve: a chave não pode ficar nos arquivos, então é preciso um programa no servidor que acesse o serviço de terceiros em nome do(a) senhor(a), ou um serviço intermediário de terceiros que faça isso no seu lugar.

Existe um meio-termo. Um serviço de terceiros pode receber o formulário de pedido no lugar do(a) senhor(a): o visitante clica em "enviar", os dados não vão para o seu servidor, e sim para esse serviço, e de lá chegam ao(à) senhor(a) por e-mail. Isso continua sendo backend, só que não é o seu. O agente indica um serviço assim se o(a) senhor(a) perguntar; por enquanto o importante é entender que um formulário não funciona sem o programa de alguém rodando num servidor.

5. Por que as formas de deploy são diferentes

Um site estático é publicado por cópia: a pasta vai para a hospedagem (um servidor de terceiros que entrega os seus arquivos a quem quiser), o link já está pronto, para atualizar basta copiar de novo. Só isso.

Com o backend é diferente. No servidor precisa haver um ambiente para a linguagem do programa - o próprio Python ou Node.js, sem os quais não há como rodar o código. O programa precisa estar em execução e reiniciar se cair. Junto com ele precisa funcionar um banco de dados. As chaves do banco e de serviços de terceiros precisam ficar guardadas de um jeito que o programa consiga ler e os visitantes não. Cada uma dessas partes é atualizada separadamente e quebra do seu próprio jeito.

Daí uma hospedagem diferente: uma que roda programas, e não só entrega arquivos. Nela normalmente se paga pelo tempo em que o programa fica rodando e pelo espaço do banco de dados. Existem opções gratuitas, mas com ressalvas que mudam com mais frequência do que este material.

Uma ressalva sobre a linha dos segredos. Um site estático também tem uma chave, a da hospedagem, se o(a) senhor(a) criou uma para ter um link permanente, mas fica separada da pasta do site e não é colocada nela.

"Subir um servidor", na resposta do agente, soa corriqueiro, como "criar um arquivo". Por trás dessa frase está toda a coluna da direita da tabela, e quase todas as linhas vão precisar de manutenção depois.

6. Onde publicar um site estático

Como um site estático é publicado por cópia, existem muitas hospedagens para ele, e a maioria é gratuita para uma página pequena. Aqui estão cinco das mais comuns. Na tabela vai aparecer a palavra "repositório": por enquanto basta entendê-la como uma pasta de projeto sob controle de versão, mais detalhes ficam para depois.

Como escolher. Para mostrar e discutir - aquela onde o link aparece sem cadastro. Para deixar por muito tempo - qualquer uma onde o(a) senhor(a) criou uma conta. O projeto está num repositório - a que se conecta ao repositório e atualiza sozinha a cada mudança. A escolha não influencia a aparência da página publicada: os arquivos são os mesmos.

Se o site tem backend

O programa precisa de uma hospedagem que saiba não só entregar arquivos, mas rodar o seu código e mantê-lo em execução: ela recebe não uma pasta, e sim um programa, e providencia sozinha o ambiente para ele. Parte dos serviços da tabela acima também tem esse modo, mas normalmente se começa com dois feitos justamente para programas:

O backend gratuito sempre tem o seu preço: num serviço o programa hiberna, e o primeiro visitante depois de uma pausa espera ele acordar; no outro, o crédito acaba. Quando o número de visitantes cresce, o funcionamento contínuo começa a ser pago. Um site estático não tem esse problema: arquivos não hibernam.

As condições e os limites de todos os serviços mudam, e os produtos são renomeados e fundidos: a Cloudflare, por exemplo, já sugere começar novos projetos não no Pages, mas no Workers, onde os arquivos estáticos são publicados do mesmo jeito. Números não entraram de propósito em nenhuma das duas tabelas: antes de escolher, dê uma olhada na página de planos.

7. O que perguntar ao agente antes de publicar

O agente olha para a pasta e geralmente já nomeia o tipo de projeto sozinho. Arquivos sem programa - vai propor hospedagem para site estático, mesmo que entre os arquivos haja um formulário sem para onde enviar: isso ele nem sempre percebe. Existe um server.js ou app.py - vai dizer que precisa de servidor e perguntar onde ele vai ficar. Se ele não disse o tipo, ou disse rápido demais, pergunte:

Veja o projeto e me diga se é um site estático ou se ele precisa de servidor.
Liste, item por item, o que exatamente exige servidor.
Para cada item, sugira se dá para funcionar sem servidor ou adiar.

A resposta depende do projeto, por isso ela não está aqui. Mas há algumas coisas que vale a pena observar em qualquer resposta.

• Não concorde de olhos fechados com "precisa de servidor". Pergunte o que exatamente exige isso e se dá para fazer no navegador ou adiar - por exemplo, lançar a primeira versão sem o formulário. O agente constrói backend de bom grado onde bastaria o armazenamento do navegador.
• E o contrário também: se os dados precisam ser compartilhados, o agente provavelmente vai dizer que um site estático não basta. Isso não é complicar as coisas, é chamá-las pelo nome certo. Não há o que discutir aqui.
• Sobre a chave de um serviço de terceiros, o agente vai perguntar onde colocá-la. A resposta "no arquivo do site" está errada, e um bom agente vai dizer isso sozinho. Essas chaves têm um lugar fora dos arquivos do site, e o agente deve nomeá-lo por conta própria, não sugerir escrever a chave na página.
• Antes do deploy de um site estático, o agente precisa de uma pasta. Antes do deploy do backend, também precisa de respostas sobre banco de dados, ambiente e segredos. Se não houve perguntas e o servidor "subiu" assim mesmo, veja o que exatamente foi feito e onde.

As palavras "estática" e "backend" descrevem não a complexidade, mas o lugar: onde o trabalho acontece e onde os dados moram. Quando esse lugar é conhecido, a forma de publicação se escolhe sozinha.

As condições das hospedagens mudam com o tempo, verifique nas páginas de planos.