Como o VULK Gera Backends Automaticamente

Atualizado a 17 de julho de 2026 — refrescado com dados verificados da plataforma sobre quantas apps geradas por IA recebem realmente backends reais.

Como é que o VULK gera um backend automaticamente?

A resposta completa: o VULK lê o teu prompt à procura de sinais de backend — contas, dados guardados, painéis de administração, APIs — e quando os encontra, gera uma aplicação server-side completa ao lado do teu frontend: um schema de base de dados relacional (tabelas, chaves estrangeiras, índices, constraints), endpoints CRUD RESTful para cada entidade, autenticação baseada em JWT com hashing de passwords bcrypt, e um frontend já ligado a esses endpoints com tokens, estados de carregamento e tratamento de erros. Sem conta Supabase, sem projeto Firebase, sem configuração externa — o backend faz deploy na infraestrutura do VULK com a tua app (plano Builder e superiores).

Isto importa porque "os construtores de apps com IA fazem brinquedos de UI" é agora um mito, e os dados provam-no: 62% de todas as apps geradas no VULK incluem um schema SQL de base de dados, e 27% recebem um backend provisionado — uma API viva mais base de dados alojada. O SQL é o tipo de ficheiro #3 mais gerado na plataforma, com 6,1% de 124.755 ficheiros, atrás apenas do TypeScript e do JSON (dados da plataforma VULK, julho de 2026, N = 11.355 projetos). A maioria das apps "vibe-coded" são aplicações de dados, não páginas estáticas.

O que está errado nos construtores de IA só de frontend?

A maioria dos geradores de código com IA dá-te uma app React com dados hardcoded. O formulário de login é bonito, mas não autentica ninguém. O dashboard mostra gráficos com JSON estático que nunca muda. O botão "Guardar" dispara uma notificação toast, mas não guarda nada.

Construí a geração de backend do VULK porque estava farto de ver este padrão. Um frontend sem backend é um protótipo, não uma aplicação. E se estás a pagar por um construtor de código com IA, deves receber algo que realmente funciona.

Quando o teu prompt descreve funcionalidade que exige um backend — contas de utilizador, dados guardados, endpoints de API, painéis de administração — o VULK gera o backend automaticamente. Não é um mock. É um backend real com base de dados relacional, rotas de API, autenticação e migrações de schema. O formulário de login autentica-te mesmo. Os dados persistem mesmo. Os endpoints de API respondem mesmo.

Como funciona a deteção de backend?

Não precisas de dizer "gera um backend". Descreves o que queres, e o VULK determina se um backend é necessário com base em sinais no teu prompt.

A deteção é intencionalmente conservadora. O VULK não acrescenta um backend a uma simples landing page ou a um portefólio estático. Só ativa quando o teu prompt exige genuinamente funcionalidade server-side. A divisão em toda a plataforma reflete isto: 62% das apps recebem um schema, enquanto as restantes — portefólios, landing pages, jogos — ficam genuinamente frontend-only (dados da plataforma VULK, julho de 2026).

Porquê PostgreSQL e não Supabase, Firebase ou MongoDB?

Perguntam-me muito sobre esta decisão, e quero ser transparente quanto ao raciocínio.

Porque não Supabase ou Firebase? Porque são serviços de terceiros que criam dependências externas. Se eu gerasse código que exige um projeto Supabase, terias de criar uma conta Supabase, montar um projeto, configurar variáveis de ambiente e gerir mais um serviço. Isso quebra a experiência de "um prompt, uma app a funcionar". O backend do VULK corre na nossa infraestrutura com zero configuração externa. (Se quiseres o teu próprio Supabase, isso existe como integração opt-in no Pro+ — ligas as tuas chaves e o agente trabalha contra o teu projeto real. Só nunca te é imposto.)

Porque não MongoDB? Porque a maioria das aplicações que os utilizadores do VULK constroem são relacionais. Tarefas pertencem a projetos. Projetos pertencem a utilizadores. Encomendas contêm itens de encomenda. Produtos têm categorias. Estas relações exprimem-se naturalmente como tabelas com chaves estrangeiras, não como coleções de documentos. O MongoDB é ótimo para casos de uso específicos, mas para a amplitude de aplicações que o VULK gera, as bases de dados relacionais produzem código mais limpo e mais fácil de manter.

Porquê PostgreSQL especificamente? É a base de dados relacional open-source mais capaz. Conformidade ACID completa, excelente suporte JSON para quando precisas de flexibilidade, indexação robusta e um ecossistema massivo. É o que eu escolheria para uma aplicação de produção, por isso é o que o VULK gera.

O que é gerado exatamente?

Quando a geração de backend dispara, o VULK produz uma aplicação server-side completa ao lado do teu frontend. Eis o que inclui cada camada.

Schema de base de dados. Tabelas SQL completas com colunas, tipos, constraints, índices e relações. Uma tabela de utilizadores recebe id, email, password_hash, name, created_at e updated_at. Os posts recebem uma chave estrangeira para os utilizadores. Cada tabela recebe uma chave primária, timestamps e índices nas colunas usadas em queries.

A coluna chama-se password_hash — nunca password. É uma decisão de segurança deliberada que imponho na engenharia do prompt. As passwords são hasheadas com bcrypt no registo e comparadas no login. O próprio nome da coluna torna a intenção inequívoca.

Endpoints de API. Rotas RESTful para cada entidade do teu schema. Uma tabela posts gera GET /api/posts (listagem com paginação), GET /api/posts/:id (registo único), POST /api/posts (criação), PUT /api/posts/:id (atualização) e DELETE /api/posts/:id (eliminação). Cada endpoint inclui validação de input, tratamento de erros e códigos de estado HTTP apropriados.

Sistema de autenticação. Registo (POST /api/auth/register) e login (POST /api/auth/login). O registo faz hash da password com bcrypt e guarda-a. O login compara contra o hash e devolve um JWT. As rotas protegidas verificam o JWT via middleware.

Integração com o frontend. Esta é a parte que faz tudo parecer completo. O frontend React é gerado com as chamadas de API já ligadas. Os fetch apontam para os endpoints corretos. Os tokens de auth são guardados e anexados aos pedidos. Estados de carregamento e tratamento de erros estão incluídos. O formulário de login autentica de verdade. O formulário de registo cria mesmo uma conta. Os dados guardados persistem mesmo entre sessões.

Como são as gerações de backend reais?

App de gestão de tarefas: "Constrói uma app de gestão de tarefas em que os utilizadores podem criar conta, iniciar sessão, criar projetos e adicionar tarefas aos projetos. As tarefas têm título, descrição, prioridade, data-limite e estado. Os utilizadores só veem os seus próprios projetos."

Isto gera: tabela users, tabela projects com chave estrangeira user_id, tabela tasks com chave estrangeira project_id, endpoints de auth, CRUD para projetos e tarefas, middleware de autorização que filtra por user_id.

Loja de e-commerce: "Cria uma loja online para vender cerâmica artesanal. O admin pode adicionar produtos. Os clientes podem navegar, adicionar ao carrinho e fazer encomendas. O histórico de encomendas fica guardado na conta do utilizador."

Isto gera: tabela users com coluna role, tabela products, tabela orders, tabela de junção order_items, controlo de acesso baseado em papéis, endpoints só de admin para gestão de produtos, endpoints de cliente para navegar e encomendar.

Estes dois exemplos não são raridades escolhidas a dedo — dashboards/painéis de administração (12,5%), e-commerce (4,5%) e sistemas de reservas (3,4%) são as principais categorias com forma de backend que as pessoas realmente geram (dados da plataforma VULK, julho de 2026).

Quão bom é o schema de base de dados gerado?

Preocupo-me com a qualidade do schema porque schemas maus criam aplicações más. Eis o que o VULK impõe:

Chaves primárias usam inteiros autoincrementais por simplicidade. UUID está disponível para casos de uso específicos.

Chaves estrangeiras incluem ON DELETE CASCADE onde apropriado (apagar um utilizador apaga os seus posts) e ON DELETE SET NULL onde os registos órfãos devem sobreviver (apagar uma categoria não apaga os produtos).

Índices são criados nas colunas de chaves estrangeiras, nas colunas de email (para lookups de login) e em qualquer coluna usada em cláusulas WHERE ou ORDER BY. Não é um detalhe posterior — os índices gerados correspondem às queries geradas.

Timestamps (created_at, updated_at) estão em todas as tabelas.

Enums e constraints são usados para valores limitados. O estado de uma tarefa está restringido a valores específicos, não a strings arbitrárias.

Que padrões de segurança vêm incluídos?

Eis o que a maioria das pessoas assume mal sobre código gerado: publicam-no sem pensar em segurança. A geração de backend do VULK inclui padrões de segurança por defeito, porque publicar sem eles cria vulnerabilidades reais:

• Hashing de passwords com bcrypt (nunca em texto simples)
• Queries parametrizadas (nunca concatenação de strings em SQL)
• Middleware de verificação JWT nas rotas protegidas
• Validação de input em todos os endpoints (verificação de tipos, campos obrigatórios, limites de comprimento)
• Configuração CORS limitando as origens ao domínio do frontend
• Rate limiting nos endpoints de auth para prevenir força bruta
• Queries com escopo de utilizador garantindo que os utilizadores só acedem aos seus próprios dados

Não são extras opcionais que ativas. Fazem parte do output por defeito, porque acredito que código gerado deve ser seguro por defeito.

Quando é que a geração automática de backend é a escolha certa?

Funciona melhor para aplicações standard orientadas a dados: gestores de tarefas, ferramentas de CRM, sistemas de inventário, blogs, lojas de e-commerce, plataformas de reservas, dashboards. Estas seguem padrões que os modelos de IA dominam bem, e o código gerado é limpo, legível e fácil de manter.

Adequa-se menos a aplicações com requisitos exóticos: colaboração em tempo real com operational transforms, cálculos financeiros complexos ou integração com APIs de terceiros obscuras. Para esses casos, gera as partes standard com o VULK e implementa as partes especializadas manualmente.

Todos os ficheiros gerados são legíveis e modificáveis. Sem runtime proprietário escondido de ti, sem lock-in de framework no código contra o qual escreves. Se ultrapassares o backend gerado, exportas o código e refatoras como qualquer outra aplicação.

É esse o princípio à volta do qual construo: o VULK deve acelerar o teu desenvolvimento, não prender-te num jardim murado.