O que é um app full-stack? Uma explicação em linguagem simples

Um app full-stack é um app que inclui todas as camadas de que precisa para funcionar: o frontend que as pessoas veem e clicam, o backend que roda em um servidor e aplica as regras, e o banco de dados que guarda tudo. Uma lista de tarefas que salva suas tarefas, deixa você entrar de qualquer dispositivo e não mostra a sua lista a mais ninguém é full-stack. Uma única página que mostra apenas o horário de funcionamento de um negócio não é.

“Stack” (pilha) significa as camadas de tecnologia empilhadas umas sobre as outras. “Full” (completo) significa que todas estão presentes.

Por que isso importa ao construir com IA

Quando você descreve um app para um construtor de IA, as palavras que usa decidem quais camadas ele constrói. “Faça uma página que mostre o nosso cardápio” gera um frontend. “Deixe os clientes fazerem pedidos pelo cardápio e deixe a cozinha ver os novos pedidos” exige as três camadas, porque os pedidos precisam ser salvos, compartilhados entre dois tipos de usuários e mantidos privados.

Conhecer a diferença ajuda de três formas:

• Você pede a coisa certa. Se quer que os dados sejam salvos, diga isso. Um construtor que faz apenas o frontend vai parecer pronto, mas vai esquecer tudo ao atualizar a página.
• Você identifica a falsa completude. Uma demonstração com dados de exemplo pode parecer idêntica a um app funcionando. Conhecer as camadas permite verificar se os dados realmente vão para algum lugar.
• Você entende os custos de operação. Um frontend sozinho pode ser servido como arquivos estáticos. Um backend e um banco de dados são programas que rodam em servidores, e é daí que vem a maior parte do custo de hospedagem.

Uma analogia do dia a dia: um restaurante

Pense em um restaurante.

• O salão é o frontend. Cardápios, mesas e o bloco do garçom. É o que os clientes veem, e deve ser agradável e fácil de usar.
• A cozinha é o backend. Os clientes nunca entram ali. Ela recebe os pedidos, verifica se o prato está disponível, prepara e recusa pedidos estranhos. As regras moram ali.
• A despensa e o livro de pedidos são o banco de dados. Eles guardam o que existe e o que foi pedido, para que nada se perca na troca de turno.

Um restaurante só com salão pode mostrar um cardápio bonito, mas você não consegue comer. É isso que um app só com frontend faz quando finge ser full-stack.

As três camadas em detalhe

As camadas se comunicam em uma ordem fixa. O frontend pede algo ao backend por meio de uma API — um conjunto definido de requisições que o backend aceita. O backend verifica a requisição, lê ou escreve no banco de dados e devolve uma resposta. O frontend nunca fala diretamente com o banco de dados.

Essa ordem é a ideia de segurança mais importante de toda a pilha. Qualquer coisa no frontend pode ser lida e alterada pelo visitante, porque roda no dispositivo dele. Por isso, as regras — “só o dono pode ver esta fatura”, “um cupom pode ser usado uma única vez” — precisam ser aplicadas no backend. Para mais sobre essa divisão, veja frontend vs. backend.

Um exemplo prático: um app de reservas de aulas

Suponha que você tem um estúdio de yoga e quer que as pessoas reservem aulas online.

O que o visitante faz: abre o site, vê os horários desta semana, toca em uma aula, faz login e reserva uma vaga.

O que acontece por baixo:

1. O frontend mostra a grade de horários. Para preenchê-la, pede ao backend: “Quais aulas há nesta semana e quantas vagas restam?”
2. O backend pede ao banco de dados as aulas e conta as reservas de cada uma, e então responde.
3. O visitante toca em Reservar. O frontend envia “reservar a aula 42 para esta pessoa logada”.
4. O backend verifica: esta pessoa está mesmo logada? A aula está lotada? Ela já reservou esta aula? Somente se tudo estiver correto ele grava uma nova linha de reserva no banco de dados.
5. O backend responde “reservado”, e o frontend mostra uma confirmação.
6. Depois, a dona do estúdio faz login e vê a lista de aulas. O backend confirma que ela é administradora antes de mostrar os nomes de todos.

Agora imagine que isso tivesse sido construído apenas com frontend. A grade poderia aparecer, e o botão Reservar poderia mostrar um belo visto, mas a reserva sumiria ao atualizar a página, a contagem de “vagas restantes” ficaria errada para os outros, e a dona nunca veria nada. A etapa 4 — as verificações — estaria totalmente ausente. Essa é a diferença prática.

Termos-chave

• Frontend (lado do cliente): a parte que roda no navegador.
• Backend (lado do servidor): a parte que roda em um servidor. Também chamado de servidor de API.
• Banco de dados: onde os dados são guardados de forma organizada. Veja o que é um banco de dados.
• API: a lista de requisições que o backend aceita do frontend ou de outros programas.
• Autenticação: verificar quem é a pessoa (login). Autorização: verificar o que ela pode fazer.
• Deploy (implantação): colocar todas as camadas em servidores para que o público possa usar.
• Monólito vs. serviços: um programa que faz tudo, versus vários programas menores (por exemplo, um site e uma API separada). Ambos são full-stack.

Erros comuns e ideias erradas

• “Parece pronto, então está pronto.” Dados de exemplo e um botão que parece funcionar não são a mesma coisa que dados salvos. Atualize a página, abra o app em uma janela privada e confira se os dados continuam lá.
• Colocar as regras no frontend. Esconder um botão não é segurança. Se o backend não verificar, qualquer pessoa que conheça a requisição pode fazê-la.
• Colocar chaves secretas no frontend. Uma chave de pagamento ou de IA no código do navegador é legível por todos os visitantes. As chaves pertencem ao backend, em variáveis de ambiente — veja variáveis de ambiente e secrets.
• Achar que full-stack significa complicado. Um pequeno app full-stack pode ter algumas telas, um punhado de rotas no backend e três tabelas no banco. É uma descrição das camadas, não do tamanho.
• Achar que você precisa escolher cada tecnologia sozinho. Qualquer stack sensata e amplamente usada serve para uma primeira versão. O que pesa mais é uma descrição clara dos dados e das regras.

O que pedir ao seu construtor de IA

Descreva o app em termos das três camadas, mesmo que você não use os nomes:

• Os dados: “Salve as aulas (nome, horário, capacidade) e as reservas (aula, pessoa, horário da reserva) em um banco de dados.”
• As regras: “Uma aula não pode ser reservada além da capacidade. Uma pessoa pode reservar uma aula apenas uma vez. Somente administradores podem ver quem reservou.”
• As telas: “Uma grade semanal de horários, uma confirmação de reserva, uma página de administração listando as reservas por aula.”
• As verificações: “Aplique essas regras no servidor, não apenas na página. Mantenha quaisquer chaves de API no servidor.”

Depois, teste com desconfiança: atualize a página, entre com duas pessoas diferentes, tente ver dados que você não deveria. O guia para construir um app com IA percorre esse ciclo do início ao fim.

Apps full-stack no Mythex

O Mythex constrói apps web full-stack a partir de uma descrição no chat. Por padrão, um novo app recebe um frontend em React e TypeScript; quando o app precisa salvar dados, o Mythex adiciona um banco Postgres dedicado ao projeto, e você pode pedir um servidor de API separado (por exemplo, em Python, Node, C# ou Java) junto com o site. Tudo roda junto em uma prévia ao vivo e é publicado em uma URL pública. A página da documentação sobre apps com múltiplos serviços mostra como um site e uma API são visualizados e publicados juntos, e a página do construtor de apps full-stack traz pontos de partida.

Perguntas