Edge functions
Définition
Fonctions serveur exécutées sur le edge runtime. Chez Supabase, écrites en Deno/TypeScript. Pratiques pour la logique sensible qui ne doit pas tourner côté client.
Comment ça marche
Les edge functions sont des fonctions serveur déployées sur un réseau edge mondial et déclenchées par HTTP. Chez Supabase, elles s'écrivent en TypeScript et tournent sur Deno Deploy à proximité de la base. Chez Vercel, ce sont les routes Next.js déclarées en runtime edge, qui tournent sur Cloudflare Workers. Chez Cloudflare directement, ce sont les Workers. Dans tous les cas, une requête entrante est routée vers le PoP le plus proche, la fonction démarre en quelques millisecondes (V8 isolate, pas de cold start lourd), exécute sa logique et renvoie la réponse. Le déploiement se fait en quelques secondes depuis un commit Git.
À quoi ça sert
On utilise les edge functions pour la logique métier qui ne doit pas exposer ses secrets côté client. Appel à une API tierce avec une clé privée (OpenAI, Stripe, SendGrid). Validation et persistance d'un formulaire avec vérification serveur. Réception de webhooks entrants (Stripe, GitHub, Calendly). Modération de contenu utilisateur avant écriture en base. Génération de tokens d'accès temporaires (par exemple pour un upload direct vers un bucket). Toute opération où on ne veut ni faire confiance au client ni payer le coût d'un Node Lambda classique. Le déploiement edge garantit aussi une latence faible pour les utilisateurs mondiaux.
Supabase Edge Functions vs Vercel
Les deux solutions partagent la même philosophie mais ciblent des cas différents. Supabase Edge Functions tournent à côté de la base Supabase : latence ultra-faible vers PostgreSQL, accès direct à pgvector, au stockage et aux fonctions auth via le SDK. Idéal pour la logique métier qui touche directement à la base. Vercel Edge Functions sont les routes API d'un projet Next.js : intégrées au framework, parfaites pour les API publiques et les middleware. On combine souvent les deux : Vercel pour le front et les API publiques, Supabase Edge Functions pour les opérations sensibles côté données.
Les contraintes
Pas de Node.js complet : pas de fs, pas de child_process, pas de connexions TCP brutes. Les API Web (fetch, crypto, Request, Response) fonctionnent. La durée d'exécution est limitée (Supabase : jusqu'à 150 secondes en plan Pro, Vercel : 30 secondes en streaming). Les libs npm doivent être compatibles avec Deno (Supabase) ou avec le runtime Vercel edge. Pas de connexions persistantes : on ne tient pas un WebSocket côté serveur, on bascule alors sur un Realtime managé ou un serveur dédié. Pas de tâches programmées dans la fonction elle-même : on déclenche via un cron externe (Supabase pg_cron, Vercel Cron).
Quand l'utiliser
On choisit les edge functions pour : webhooks Stripe avec validation de signature, appels OpenAI ou Anthropic avec garde-fous côté serveur, validation d'un formulaire complexe avant écriture, génération d'un token signé pour un upload, géolocalisation et routing selon IP, A/B testing serveur. La latence faible et le pricing au token sont avantageux. Pour les charges constantes ou les jobs longs, on bascule vers un serveur classique ou des fonctions Node serverless. Pour les workflows orchestrés (n8n, Inngest, Trigger.dev), on délègue à ces outils plutôt qu'à des edge functions enchaînées à la main.
Les bonnes pratiques
On garde les fonctions courtes et focalisées sur une seule responsabilité. On valide systématiquement les entrées avec Zod ou un équivalent. On sécurise les webhooks avec une vérification de signature. On logge les erreurs vers Sentry ou un service équivalent (la console du dashboard ne suffit pas en prod). On stocke les secrets dans le dashboard des variables d'environnement, jamais en dur. On évite les imports lourds qui plombent le démarrage. On teste localement avec le CLI fourni (supabase functions serve, vercel dev). Et on monitore les invocations pour détecter les pics anormaux qui pourraient signaler un bug ou un abus.
Les pièges à éviter
Le piège classique : faire confiance au client. Une edge function exposée publiquement reçoit n'importe quel payload, y compris des tentatives d'injection. On valide tout. Autre piège : les boucles infinies ou les appels en cascade qui finissent par taper la limite CPU ou la limite de durée, sans message clair. On instrumente avec console.log et on surveille les timeouts. Les variables d'environnement ne se mettent pas à jour à chaud : il faut redéployer pour qu'un changement prenne effet. Les imports dynamiques peuvent casser au cold start si le module est lourd. Et on n'écrit jamais une edge function qui appelle une autre edge function du même projet : on factorise en code partagé.