Edge Functions : Boostez votre site avec le Edge Computing

Pendant longtemps, le backend, c'était simple : un serveur quelque part (souvent aux US ou à Paris), et tous les utilisateurs du monde se connectaient à ce point unique. Si vous étiez à Tokyo et le serveur à Paris, tant pis pour la latence.

Puis est arrivé le CDN pour les fichiers statiques (images, CSS). C'était mieux. Maintenant, nous avons le Edge Computing : la possibilité d'exécuter du code dynamique directement sur le CDN, au plus près de l'utilisateur.

Voici comment Next.js et Vercel rendent cette technologie accessible, et pourquoi vous devriez vous y intéresser.

C'est quoi une Edge Function ?

Imaginez une fonction JavaScript standard. Au lieu de l'héberger sur un seul serveur Node.js (Serverless "classique"), elle est déployée simultanément sur des centaines de serveurs à travers le monde.

Quand un utilisateur appelle cette fonction, c'est le serveur le plus proche géographiquement qui répond.

• Utilisateur à Genève → Serveur à Zurich (latence : 10ms)
• Utilisateur à New York → Serveur à New York (latence : 10ms)

Contrairement au Serverless classique (AWS Lambda), les Edge Functions ont un démarrage à froid (cold start) quasi inexistant car elles utilisent souvent le V8 Engine (comme votre navigateur) au lieu d'un conteneur Node.js complet.

Les limitations importantes

Avant de vous emballer, sachez qu'il y a des contraintes. Les Edge Functions (chez Vercel ou Cloudflare) n'exécutent pas Node.js complet.

Ce que vous NE POUVEZ PAS faire :

• Utiliser des modules natifs Node.js (fs, child_process)
• Connecter à une base de données traditionnelle (MySQL, PostgreSQL) sans driver compatible HTTP/TCP spécifique (bien que Neon ou Supabase changent la donne)
• Exécuter des tâches très longues (timeout souvent limité à 30 secondes ou moins)

Ce que vous POUVEZ faire :

• Manipuler les requêtes et réponses HTTP
• Lire/écrire des cookies
• Appeler des API externes (fetch)
• Accéder à des bases de données compatibles edge (Redis, KV stores, Drizzle via HTTP)

Cas d'usage concrets avec Next.js

1. Middleware : Redirections et Réécritures

C'est l'usage le plus courant. Avant même que votre page ne soit rendue, vous pouvez intercepter la requête.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const country = request.geo?.country || 'CH';

  // Redirection basée sur la géolocalisation
  if (country === 'FR' && !request.nextUrl.pathname.startsWith('/fr')) {
    return NextResponse.redirect(new URL('/fr', request.url))
  }
  
  return NextResponse.next()
}

Ce code s'exécute à la volée, sans ralentir perceptiblement la requête.

2. A/B Testing côté serveur

Au lieu de faire clignoter la page côté client (flicker) pendant qu'un script JS décide quelle version afficher, faites le choix à la frontière (Edge).

// middleware.ts
import { NextResponse } from 'next/server'
import { getBucket } from '@utils/ab-testing' // votre logique de bucket

export function middleware(request: NextRequest) {
  const cookie = request.cookies.get('bucket')?.value;
  const bucket = cookie || getBucket();
  
  // Réécrire l'URL en interne sans changer l'URL du navigateur
  const response = NextResponse.rewrite(new URL(`/${bucket}`, request.url));
  
  if (!cookie) {
    response.cookies.set('bucket', bucket);
  }
  
  return response;
}

Le serveur renvoie directement la variante A ou B. Zéro impact sur les Core Web Vitals.

3. Authentification rapide

Vérifier un JWT (Json Web Token) à l'Edge est extrêmement rapide. Si le token est invalide, la requête est rejetée avant même d'atteindre votre serveur principal ou votre base de données.

Base de données à l'Edge : Le challenge

Le plus gros problème du Edge Computing a longtemps été les données. Si votre code est à Tokyo mais votre base de données en Virginie, vous ne gagnez rien (le code doit traverser le pacifique pour chercher la donnée).

La solution : Distributed Data.

• Redis (Upstash) : Répliqué globalement. Parfait pour les sessions, les caches, les compteurs.
• Postgres (Neon, Supabase) : Drivers serverless et pooling de connexion.
• Vercel KV / Blob : Solutions intégrées pour le stockage simple.

Exemple : Un compteur de vues performant

Voici comment implémenter un compteur de vues simple qui tourne entièrement à l'Edge avec Redis (via Upstash).

// app/api/views/[slug]/route.ts
import { Redis } from '@upstash/redis'
import { NextResponse } from 'next/server'

export const runtime = 'edge'; // Active le runtime Edge

const redis = Redis.fromEnv();

export async function POST(req: Request) {
  const { slug } = await req.json();
  
  // Incrémenter atomiquement
  const views = await redis.incr(`pageviews:projects:${slug}`);
  
  return NextResponse.json({ views });
}

Grâce à runtime: 'edge', cette API répondra en <50ms depuis n'importe où dans le monde (si Redis est bien configuré).

Quand NE PAS utiliser Edge ?

Si votre application a besoin d'une connexion lourde à une base de données SQL classique hébergée à un seul endroit, restez sur du Serverless classique (Node.js) déployé dans la même région que votre DB.

Faire Utilisateur (Tokyo) -> Edge (Tokyo) -> DB (Paris) -> Edge (Tokyo) -> Utilisateur (Tokyo) est plus lent que Utilisateur (Tokyo) -> Server (Paris) -> DB (Paris) -> Server (Paris) -> Utilisateur (Tokyo) à cause des multiples allers-retours (round-trips).

Conclusion

L'Edge Computing n'est pas une solution miracle qui remplace tout. C'est un outil puissant pour rapprocher la logique de l'utilisateur.

Commencez par l'utiliser pour :

1. Les middlewares (auth, geo, redirections)
2. Les APIs qui n'ont pas besoin de base de données lourde
3. Le contenu personnalisé à la volée

Avec Next.js, c'est aussi simple que de changer une ligne de config : export const runtime = 'edge'. Pourquoi s'en priver ?