O Que É uma App Full-Stack? Explicação em Português Simples

Uma app full-stack é uma app que inclui todas as camadas de que precisa para funcionar: o frontend que as pessoas veem e clicam, o backend que corre num servidor e aplica as regras, e a base de dados que guarda tudo. Uma lista de tarefas que guarda as suas tarefas, lhe permite iniciar sessão a partir de qualquer dispositivo e não mostra a sua lista a mais ninguém é full-stack. Uma única página que apenas mostra o horário de funcionamento não é.

"Stack" significa apenas as camadas de tecnologia empilhadas umas sobre as outras. "Full" significa que todas estão presentes.

Porque é que importa quando cria com IA

Quando descreve uma app a um construtor de IA, as palavras que usa decidem que camadas ele constrói. "Crie uma página que mostre a nossa ementa" produz um frontend. "Deixe os clientes encomendarem a partir da nossa ementa e deixe a cozinha ver as novas encomendas" precisa das três camadas, porque as encomendas têm de ser guardadas, partilhadas entre dois tipos de utilizadores e mantidas privadas.

Perceber a diferença ajuda-o de três formas:

• Pede a coisa certa. Se quer que os dados fiquem guardados, diga-o. Um construtor que só faz o frontend parecerá acabado, mas esquecer-se-á de tudo ao atualizar.
• Deteta a falsa completude. Uma demonstração com dados de exemplo pode parecer idêntica a uma app a funcionar. Conhecer as camadas permite-lhe verificar que os dados realmente vão para algum lado.
• Percebe os custos de funcionamento. Um frontend sozinho pode ser servido como ficheiros estáticos. Um backend e uma base de dados são programas que correm em servidores, e é daí que vem a maior parte do custo de alojamento.

Uma analogia: um restaurante

Pense num restaurante.

• A sala de jantar é o frontend. Ementas, mesas e o bloco de notas do empregado. É o que os clientes veem, e deve ser agradável e fácil de usar.
• A cozinha é o backend. Os clientes nunca entram. Recebe as encomendas, verifica se o prato está disponível, cozinha-o e recusa pedidos estranhos. As regras vivem aqui.
• A despensa e o livro de encomendas são a base de dados. Guardam o que existe e o que foi encomendado, para que nada se perca quando muda o turno.

Um restaurante só com sala de jantar pode mostrar-lhe uma ementa bonita, mas não lhe consegue servir comida. É isso uma app só de frontend a fingir ser full-stack.

As três camadas em detalhe

As camadas comunicam numa ordem fixa. O frontend pede algo ao backend através de uma API — um conjunto definido de pedidos que o backend aceita. O backend verifica o pedido, lê ou escreve na base de dados e envia uma resposta. O frontend nunca fala diretamente com a base de dados.

Essa ordem é a ideia de segurança mais importante de toda a pilha. Tudo o que está no frontend pode ser lido e alterado pelo visitante, porque corre no dispositivo dele. Por isso, as regras — "só o proprietário pode ver esta fatura", "um cupão só pode ser usado uma vez" — têm de ser aplicadas no backend. Para mais sobre esta divisão, veja frontend vs backend.

Um exemplo prático: uma app de marcação de aulas

Imagine que dirige um estúdio de yoga e quer que as pessoas marquem aulas online.

O que o visitante faz: abre o site, vê as aulas desta semana, toca numa, inicia sessão e reserva um lugar.

O que acontece por baixo:

1. O frontend mostra o horário. Para o preencher, pede ao backend: "Que aulas há esta semana e quantos lugares ainda estão livres?"
2. O backend pede à base de dados as aulas e conta as marcações de cada uma, depois responde.
3. O visitante toca em Reservar. O frontend envia "reservar a aula 42 para esta pessoa com sessão iniciada".
4. O backend verifica: esta pessoa tem mesmo sessão iniciada? A aula está cheia? Já a reservou? Só se tudo estiver bem é que escreve uma nova linha de reserva na base de dados.
5. O backend responde "reservado", e o frontend mostra uma confirmação.
6. Mais tarde, a proprietária do estúdio inicia sessão e vê a lista de aulas. O backend verifica que ela é administradora antes de mostrar os nomes de todos.

Agora imagine que isto tinha sido construído apenas no frontend. O horário poderia aparecer, e o botão Reservar poderia mostrar um visto bonito, mas a reserva desapareceria ao atualizar, a contagem de "lugares livres" estaria errada para os outros, e a proprietária nunca a veria. O passo 4 — as verificações — estaria completamente em falta. Essa é a diferença prática.

Termos-chave

• Frontend (lado do cliente): a parte que corre no navegador.
• Backend (lado do servidor): a parte que corre num servidor. Também chamado servidor da API.
• Base de dados: onde os dados são guardados de forma organizada. Veja o que é uma base de dados.
• API: a lista de pedidos que o backend aceita do frontend ou de outros programas.
• Autenticação: verificar quem é alguém (início de sessão). Autorização: verificar o que essa pessoa pode fazer.
• Implementação (deployment): colocar todas as camadas em servidores para que o público as possa usar.
• Monólito vs serviços: um único programa que faz tudo, versus vários programas mais pequenos (por exemplo, um site e uma API separada). Ambos são full-stack.

Erros comuns e equívocos

• "Parece feito, por isso está feito." Dados de exemplo e um botão que parece funcionar não são o mesmo que dados guardados. Atualize a página, abra-a numa janela privada e confirme que os dados continuam lá.
• Pôr as regras no frontend. Esconder um botão não é segurança. Se o backend não verificar, qualquer pessoa que conheça o pedido o pode fazer.
• Pôr chaves secretas no frontend. Uma chave de pagamento ou de um fornecedor de IA no código do navegador é legível por cada visitante. As chaves pertencem ao backend, em variáveis de ambiente — veja variáveis de ambiente e segredos.
• Pensar que full-stack significa complicado. Uma pequena app full-stack pode ser alguns ecrãs, um punhado de rotas no backend e três tabelas na base de dados. É uma descrição das camadas, não do tamanho.
• Pensar que tem de escolher sozinho cada tecnologia. Qualquer pilha sensata e amplamente usada serve para uma primeira versão. Mais importante é uma descrição clara dos dados e das regras.

O que pedir ao seu construtor de IA

Descreva a app em termos das três camadas, mesmo que não as nomeie:

• Os dados: "Guarde as aulas (nome, hora, capacidade) e as reservas (aula, pessoa, hora da reserva) numa base de dados."
• As regras: "Não é possível reservar uma aula acima da capacidade. Uma pessoa só pode reservar uma aula uma vez. Só os administradores podem ver quem reservou."
• Os ecrãs: "Um horário semanal, uma confirmação de reserva, uma página de administração com as reservas por aula."
• As verificações: "Aplique estas regras no servidor, não apenas na página. Mantenha as chaves de API no servidor."

Depois, teste com ceticismo: atualize, inicie sessão com duas pessoas diferentes, tente ver dados que não deveria ver. O guia para criar uma app com IA percorre esse ciclo do início ao fim.

Apps full-stack na Mythex

A Mythex cria apps web full-stack a partir de uma descrição no chat. Por defeito, uma nova app recebe um frontend em React e TypeScript; quando a app precisa de guardar dados, a Mythex acrescenta ao projeto uma base de dados Postgres dedicada, e pode pedir um servidor de API separado (por exemplo, em Python, Node, C# ou Java) junto ao site. Tudo corre em conjunto numa pré-visualização em direto e é publicado num URL público. A página da documentação sobre apps com vários serviços mostra como um site e uma API são pré-visualizados e publicados em conjunto, e a página do construtor de apps full-stack tem pontos de partida.

Perguntas