Les edge functions ne sont plus une curiosité de startups : c'est devenu l'infrastructure standard pour les applications modernes. Contrairement aux serveurs centralisés où chaque requête traverse des milliers de kilomètres, les edge functions s'exécutent dans des data centers distribués mondialement. Pour une application Angular, cela signifie réduire le Time to First Byte (TTFB) de 200–500 ms à 10–50 ms, transformer les en-têtes de sécurité en temps réel, et même implémenter de la logique métier sans serveur. Vercel, Netlify et Cloudflare Workers dominent ce marché, mais chacun impose ses contraintes : taille des bundles, durée d'exécution, modèle de facturation.
Pourquoi les edge functions changent la donne pour Angular
Les applications Angular modernes ne sont pas juste des bundles JavaScript : elles nécessitent du contexte serveur (authentification, géolocalisation, A/B testing, gestion de cookies). Traditionnellement, vous aviez deux choix : exécuter Angular Universal sur un serveur Node.js centralisé (latence élevée), ou servir du statique et gérer la logique côté client (pas de contrôle serveur). Les edge functions offrent un tiers chemin : du code JavaScript exécuté immédiatement, au plus proche de l'utilisateur, avec accès aux en-têtes HTTP et aux cookies. Imaginez une route /api/personalized-content : au lieu d'attendre une réponse depuis la Côte Ouest américaine, la fonction s'exécute en France si l'utilisateur est français. Pour Angular, cela signifie aussi pouvoir injecter du contexte dans le HTML avant que le navigateur n'exécute le bundle principal—un avantage crucial pour le SEO et la performance perçue.
L'approche Vercel : Edge Middleware et API Routes
Vercel propose deux abstractions : les Edge Middleware (pour l'interception des requêtes) et les Edge Functions (pour les API). Les middleware s'exécutent sur chaque requête vers votre site Angular et peuvent rediriger, modifier les en-têtes, ou injecter des données. Voici un exemple concret : rediriger les utilisateurs francophones vers /fr et les autres vers /en , sans que Angular n'ait besoin de gérer cette logique.
// middleware.ts (à la racine du projet Vercel)
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const locale = request.geo?.country === 'FR' ? 'fr' : 'en';
const response = NextResponse.next();
response.cookies.set('locale', locale, { maxAge: 31536000 });
return response;
}
export const config = {
matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
}; Pour les API Routes, vous créez des fichiers dans /api qui deviennent automatiquement des edge functions. Exemple : un endpoint qui récupère les données utilisateur depuis une base de données Postgres et retourne du JSON enrichi, le tout exécuté au bord du réseau.
// /api/user.ts
export const config = { runtime: 'edge' };
export default async function handler(req) {
const userId = req.nextUrl.searchParams.get('id');
const user = await fetch(`https://db.example.com/users/${userId}`).then(r => r.json());
return new Response(JSON.stringify({ ...user, timestamp: Date.now() }), {
headers: { 'Content-Type': 'application/json' },
});
}L'avantage : zéro configuration serveur, facturation à l'exécution, et une latence quasi garantie. Le piège : Vercel impose un timeout de 25 secondes (insuffisant pour les tâches longues) et la taille du bundle d'une fonction est limitée à 1 MB après minification.
Netlify Edge Functions et Deno : une alternative solide
Netlify a adopté Deno pour ses edge functions, ce qui change la donne en termes de sécurité et de performance. Contrairement à Vercel qui utilise Node.js (et ses dépendances npm), Deno offre un environnement plus léger, plus rapide au cold start, et avec un modèle de permissions explicites. Pour une application Angular, cela signifie moins de latence et une surface d'attaque réduite.
Voici comment intégrer une edge function Netlify qui valide un token JWT avant de servir du contenu protégé :
// netlify/edge-functions/auth.ts
import { verify } from 'https://cdn.jsdelivr.net/gh/timonson/djwt@v2.8/mod.ts';
const secret = new TextEncoder().encode(Deno.env.get('JWT_SECRET'));
export default async (req, ctx) => {
const token = req.headers.get('authorization')?.split(' ')[1];
try {
await verify(token, secret, 'HS256');
return ctx.next();
} catch {
return new Response('Unauthorized', { status: 401 });
}
}; La configuration est simple : déclarer la fonction dans netlify.toml et elle s'exécute avant votre Angular app. Netlify impose un timeout de 30 secondes et permet jusqu'à 500 MB de code. La facturation est également généreuse pour les petits projets. L'inconvénient majeur : l'écosystème Deno est moins mature que Node.js, et vous aurez besoin de dépendances spécialisées.
Cloudflare Workers : puissance maximale, mais complexité accrue
Cloudflare Workers est la solution la plus puissante mais exige une compréhension plus fine de votre architecture. Au lieu de déployer sur un serveur unique, votre code s'exécute sur 300+ data centers Cloudflare, avec accès à Durable Objects (une base de données distribuée), KV (cache distribué), et D1 (SQLite au edge). Pour une application Angular avec beaucoup de logique stateful, c'est un game-changer.
Exemple : servir une version Angular pré-rendue stockée en KV, avec fallback sur une version fraîche depuis origin si le cache a expiré.
// src/index.ts (Worker)
export default {
async fetch(request, env) {
const url = new URL(request.url);
const cacheKey = `html:${url.pathname}`;
let html = await env.CACHE.get(cacheKey);
if (!html) {
const res = await fetch(`https://origin.example.com${url.pathname}`);
html = await res.text();
await env.CACHE.put(cacheKey, html, { expirationTtl: 3600 });
}
return new Response(html, { headers: { 'Content-Type': 'text/html' } });
}
};Le coût : Cloudflare facture par millions de requêtes (très bon marché), mais la courbe d'apprentissage est raide. Vous devez comprendre les Workers, les Bindings, et comment structurer votre code pour éviter les blocages.
Intégration concrète avec Angular
Pour que votre application Angular tire vraiment parti des edge functions, pensez à trois niveaux : le pré-rendu, l'authentification, et la personnalisation. Avec Angular 17+, utilisez @angular/ssr pour pré-rendre vos routes statiques, puis déployez le résultat sur votre plateforme edge. Les routes dynamiques ( /product/:id , /user/:username ) restent côté client, mais les données peuvent être pré-chargées par une edge function qui injecte du JSON dans le HTML initial. Cela réduit le CLS et améliore le Largest Contentful Paint.
Pour l'authentification, ne jamais stocker de tokens en localStorage si vous utilisez des edge functions : exploitez les cookies httpOnly avec SameSite=Strict, que la fonction peut valider directement. Cela élimine une classe entière de vulnérabilités XSS. Enfin, pour la personnalisation (thème sombre, langue, région), stockez les préférences en cookie au lieu d'une API call : une seule requête edge pour lire le contexte et servir le bon HTML.
Les pièges courants
Le premier piège : oublier que les edge functions ne sont pas des serveurs complets. Vous ne pouvez pas y déployer une base de données, faire des opérations CPU-intensives pendant 30 secondes, ou servir des fichiers volumineux. Si votre logique dépasse 1 MB ou 25 secondes, vous avez besoin d'un serveur classique en origin. Deuxièmement, ignorer les coûts cachés : les edge functions sont facturées à l'exécution, et une fonction mal écrite (boucle infinie, appels API en cascade) peut devenir coûteuse. Testez toujours le cold start et la durée d'exécution en production, pas juste en local. Troisièmement, confondre edge functions et CDN : un CDN met en cache du contenu statique, les edge functions exécutent du code. Vous avez besoin des deux.
Conclusion : choisir la bonne plateforme
Les edge functions ne sont pas une solution universelle, mais elles sont incontournables pour les applications Angular modernes. Vercel est le meilleur choix si vous avez déjà un écosystème Next.js ; Netlify edge functions brillent si vous cherchez la latence minimale et la sécurité ; Cloudflare Workers dominent si vous avez besoin de vraie puissance distribuée. Commencez par une seule edge function—par exemple, une middleware d'authentification—mesurez l'impact sur votre TTFB et votre Core Web Vitals, puis étendez progressivement. Ne visez pas 100% edge : une architecture hybride (statique + edge + origin) est plus robuste et maintenable qu'une dépendance totale au edge computing.