Resposta rápida: Edge Functions são a camada de backend que você usa quando uma ação do seu app Lovable não deve acontecer diretamente no navegador. Elas servem para chamar APIs com chaves privadas, processar pagamentos, enviar e-mails, receber webhooks, executar regras sensíveis e centralizar validações antes de gravar dados no Supabase.
A integração oficial entre Lovable e Supabase inclui Edge Functions serverless. Isso permite manter a interface no frontend e mover para o servidor tudo o que precisa de segredo, autorização forte ou integração com serviços externos. É uma das diferenças entre um protótipo que apenas funciona e uma aplicação preparada para produção.
Quando você realmente precisa de uma Edge Function
- Quando a chamada usa uma API key ou segredo que não pode chegar ao navegador.
- Quando você precisa validar permissões antes de executar uma ação sensível.
- Quando um serviço externo envia webhook para o seu sistema.
- Quando precisa assinar uma requisição, criar checkout ou confirmar pagamento.
- Quando a lógica precisa continuar funcionando mesmo com a página do usuário fechada.
- Quando quer padronizar uma integração usada por várias telas do app.
Operações simples de leitura e escrita que já estão protegidas corretamente por RLS podem continuar usando o cliente Supabase no frontend. A Edge Function não deve virar um intermediário obrigatório para tudo. Use-a onde existe uma fronteira de segurança ou uma lógica de backend real.
Arquitetura recomendada
Interface Lovable
↓ dados necessários
Edge Function
↓ autenticação + validação
API externa / banco / serviço
↓ resposta filtrada
Interface LovableNesse desenho, o usuário nunca recebe a credencial do provedor. A função busca o secret no ambiente do backend, valida o usuário e devolve somente os dados necessários. Se a integração chamar Stripe, Resend, OpenAI ou outra API privada, essa separação reduz bastante o risco de vazamento.
Como criar uma Edge Function na prática
1. Defina uma única responsabilidade
Dê à função um objetivo claro. Em vez de criar uma função chamada api-geral, prefira nomes como create-checkout, send-welcome-email, analyze-document ou sync-customer. Funções pequenas ficam mais fáceis de testar, monitorar e proteger.
2. Decida quem pode chamar a função
Pergunte se o endpoint deve ser público, restrito a usuários autenticados ou exclusivo de outro backend. Em fluxos de usuário, valide o token recebido e confirme a identidade antes de executar ações privadas. Em webhooks, use a estratégia de autenticação recomendada pelo provedor, como assinatura ou segredo próprio.
3. Valide os dados recebidos
Nunca confie que o payload do frontend está correto. Valide campos obrigatórios, tipos, limites e formatos no servidor. Se a função cria um pedido de R$ 10, por exemplo, o preço final não deve ser aceito cegamente do navegador; ele precisa ser derivado de dados confiáveis do backend.
Deno.serve(async (req) => {
if (req.method !== "POST") {
return new Response("Method not allowed", { status: 405 })
}
const body = await req.json()
if (!body.customerId) {
return Response.json({ error: "customerId obrigatório" }, { status: 400 })
}
return Response.json({ ok: true })
})4. Use Secrets para credenciais privadas
Se a função chama uma API autenticada, coloque a chave no armazenamento de Secrets do backend. Não escreva a chave em componentes React, arquivos públicos ou parâmetros enviados pelo frontend. A Lovable recomenda combinar Secrets com Edge Functions exatamente para manter credenciais privadas fora do código executado no navegador.
const apiKey = Deno.env.get("MINHA_API_KEY")
if (!apiKey) {
throw new Error("Secret não configurado")
}5. Faça a chamada externa e normalize a resposta
A função pode chamar o serviço externo, mas não precisa devolver a resposta bruta. Remova campos internos, tokens, headers e informações que a interface não usa. Um backend saudável funciona como uma camada de tradução entre o provedor e seu app.
6. Grave somente o necessário no banco
Quando a função também usa o Supabase, preserve a regra de menor privilégio. Se uma operação pode respeitar o usuário autenticado e as políticas de RLS, não use uma chave administrativa por comodidade. A service role deve ficar restrita a casos em que o bypass de RLS é realmente necessário e totalmente controlado no servidor.
Exemplo: enviar e-mail com Resend
Um formulário da Lovable coleta nome e e-mail. O frontend chama uma Edge Function chamada send-contact-email. A função valida os campos, lê a chave do Resend em Secrets, envia a mensagem e retorna apenas se o envio foi aceito. A chave nunca aparece no DevTools do visitante.
Frontend → send-contact-email
Edge Function → valida nome/e-mail
Edge Function → lê RESEND_API_KEY
Edge Function → chama Resend
Edge Function → retorna { ok: true }
