Middleware et serverless

Tu sais déjà qu'une requête HTTP voyage du navigateur vers un serveur et revient avec une réponse. Mais entre les deux, il se passe souvent bien plus que tu ne le crois. Ce code invisible - qui vérifie ton identité, redirige les vieux URLs, ajoute des headers de sécurité - s'appelle du middleware. Et depuis quelques années, ce middleware tourne sur des plateformes qui n'ont plus rien à voir avec un serveur traditionnel.

Qu'est-ce qu'un middleware ?

"Middleware" vient de l'anglais : logiciel du milieu. C'est du code qui s'exécute entre la requête entrante et la réponse finale. Il intercepte, transforme, ou redirige sans être lui-même la destination finale.

Des exemples concrets de ce qu'un middleware fait :

• Authentification : vérifier le cookie de session avant d'autoriser l'accès à /dashboard.
• Redirections : www.exemple.com vers exemple.com, ou /old-url vers /new-url.
• CORS : ajouter les headers Access-Control-Allow-Origin sur toutes les réponses d'API.
• Logging : enregistrer chaque requête avec son URL, son code de statut, et son temps de réponse.
• Rate limiting : bloquer les IPs qui envoient trop de requêtes en peu de temps.

Le middleware est intentionnellement générique : il ne connaît pas le contenu d'une page spécifique, il applique une règle à toutes les requêtes qui correspondent à un certain pattern.

La chaîne de traitement d'une requête

Voici comment une requête typique traverse un middleware, une API route, et une base de données :

Flux : navigateur → middleware Edge → API Route → base de données.

Le middleware est la première couche à répondre. Si le cookie est absent, il redirige vers /login sans même que l'API Route soit appelée. Cela évite une requête inutile vers la base de données.

Serverless : une fonction, pas un serveur

Le modèle traditionnel : tu loues un serveur (un VPS, une VM), tu y déploies ton code, et ce serveur tourne 24h/24 en attendant les requêtes. Tu paies l'inactivité. Si le trafic monte brutalement, tu dois scaler manuellement.

Le modèle serverless renverse ça. Tu écris une fonction. La plateforme la déploie, la met en veille quand personne ne l'appelle, et la réveille à la demande. Tu paies uniquement les invocations qui ont lieu.

Il existe trois variantes principales en 2026 :

Edge Functions (Vercel Edge, Cloudflare Workers) : s'exécutent au point de présence le plus proche de l'utilisateur dans un réseau mondial de datacenters. Basées sur les V8 isolates - pas Node.js complet, mais un runtime restreint. Avantage majeur : démarrage quasi-instantané (moins de 10 ms en général), aucun cold start perceptible. Contrainte : pas d'accès au système de fichiers, pas toutes les APIs Node.js disponibles.

Serverless Functions (AWS Lambda, Vercel Functions sans le flag Edge) : Node.js complet, accès à toutes les libs npm. Démarrage plus lent car la plateforme doit initialiser un conteneur - c'est le cold start, qui peut prendre entre 100 ms et 500 ms sur la première invocation après une période d'inactivité. Ensuite, le conteneur reste "chaud" quelques minutes.

Edge Database Functions (Supabase Edge Functions, Cloudflare Workers + D1) : fonctions déployées plus près de la base de données que le code client. Les Supabase Edge Functions tournent sur des edge nodes Deno distribués, mais sont gérées dans le projet Supabase à côté de la BDD. Cloudflare Workers + D1 vont plus loin avec une BDD réellement co-localisée sur les workers. Avantage commun : moins de latence réseau entre fonction et BDD qu'un serveur tiers, mais le détail varie selon le provider.

Middleware Next.js : le code réel

Dans un projet Next.js App Router, le middleware se pose dans un seul fichier : middleware.ts à la racine du projet (au même niveau que app/).

// middleware.ts (à la racine du projet)
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  const token = request.cookies.get("session")?.value;

  if (!token && request.nextUrl.pathname.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url));
  }
}

export const config = {
  matcher: ["/dashboard/:path*"],
};

Trois éléments à retenir :

1. La fonction middleware reçoit un objet NextRequest (l'URL, les headers, les cookies) et peut renvoyer une NextResponse (redirection, modification des headers, ou undefined pour laisser passer).
2. NextResponse.redirect renvoie un 307 Temporary Redirect vers l'URL passée en argument.
3. config.matcher limite les URLs sur lesquelles le middleware s'exécute. Sans matcher, il tournerait sur chaque requête, y compris les fichiers statiques - ce qui serait inutilement coûteux.

Ce middleware tourne sur l'Edge runtime de Vercel : déployé dans tous les datacenters, démarrage quasi-instantané, la vérification du cookie n'ajoute pas de latence perceptible pour l'utilisateur.

API Routes, Edge Functions et Server Components : les trois niveaux

En 2026 avec Next.js App Router, trois mécanismes permettent d'exécuter du code côté serveur. Ils ne font pas la même chose :

Server Components (app/page.tsx sans "use client") : composants React qui s'exécutent sur le serveur au moment du rendu. Ils peuvent lire une base de données directement, mais ce ne sont pas des "fonctions HTTP" au sens propre. Pas d'URL d'API, pas de verbe HTTP.

API Routes (app/api/mon-endpoint/route.ts) : endpoints HTTP classiques. Tu définis des exports GET, POST, etc. C'est là que tu mets la logique métier accessible depuis le frontend ou des services tiers.

Edge Functions : quand tu ajoutes export const runtime = 'edge' dans une API Route (ou dans le middleware), Vercel la déploie sur le réseau Edge au lieu de serveurs Node.js classiques.

// app/api/geo/route.ts - une API Route déployée sur l'Edge
export const runtime = 'edge';

export async function GET(request: Request) {
  const country = request.headers.get('x-vercel-ip-country') ?? 'FR';
  return Response.json({ country });
}

Utilise l'Edge runtime pour des routes légères et latence-sensibles (géolocalisation, A/B testing, personnalisation). Garde le runtime Node.js pour les routes qui ont besoin de libs npm lourdes ou d'accès au système de fichiers.

Anti-pattern : les jobs longs dans une Edge Function