Vous avez peut-être entendu parler du “edge”, via les edge middlewares, le runtime edge, l’edge computing…
Mais ce mot peut paraître obscur pour les développeurs frontend ou fullstack. Il s’agit d’un terme qui concerne plutôt l’infrastructure et le réseau. Pourtant, ce concept est très utile pour les développeurs Next.js, nous allons voir pourquoi.
Le “edge”, c’est le bord du réseau, c’est-à-dire les serveurs qui sont géographiquement les plus proches des utilisateurs finaux. Ils sont généralement en charge de calculs légers, comme gérer des redirections.
Le edge s’oppose à l’infrastructure de serveurs sur laquelle vous allez faire tourner votre base de données et vos traitements backend complexes, que l’on pourrait appeler le “core”.
En traitant les requêtes à partir d’emplacements proches des utilisateurs, l’edge computing peut réduire considérablement la latence des applications web.
Les serveurs edge sont généralement :
Illustration d’une architecture fondée sur le edge : le “core” est entourée de répliques légères de la base de données qui aliment des proxy at-the-edge.
Les serveurs edge peuvent aller de simples proxies à des serveurs plus avancés capables d’exécuter une logique complexe et d’accéder à des bases de données.
C’est le cas de Next.js qui favorise l’utilisation de code JavaScript via les middlewares edge, avec un runtime spécifique léger.
Il est appelé Edge runtime chez Vercel. Mais Vercel supporte aussi depuis peu Node.js dans son réseau edge.
L’edge computing est particulièrement utile pour gérer les tâches liées au traitement et au routage des requêtes :
Rate limiting, sécurité et protection contre les bots : les serveurs edge peuvent protéger le “core” contre les surcharges et les requêtes malveillantes.
Feature flagging, A/B testing et personnalisation : on peut utiliser un middleware pour rediriger dynamiquement une requêtes vers différentes versions d’une application ou personnaliser le contenu, en fonction des caractéristiques de l’utilisateur. C’est une alternative au rendu dynamique que nous appelons le “Segmented Rendering”.
Découplage entre URL et route dans l’application ; optimisation pour le SEO : réécrire les URL permet de créer des URL publiques propres et optimisées pour le SEO, tout en maintenant une logique de routage interne complexe. C’est une forme d’utilisation avancée du routeur fondé sur les fichiers par Next.js.
La dernière partie de notre formation Fullstack avec Next.js est dédiée aux middlewares edge, car ils permettent d’implémenter des fonctionnalités avancées mais très impressionantes !
Le edge ne fait sens que dans le contexte d’un hébergeur qui supporte cette approche. On peut citer les Vercel Edge Handlers et Netlify Edge Functions, qui sont les implémentations sous-jacents aux edge middlewares de Next.js. On peut aussi les utiliser en dehors de Next.js, même si c’est un peu complexe.
Ces plateformes utilisent des runtimes légers basés sur le moteur JavaScript Chrome V8 pour garantir une exécution rapide, comme le Edge Runtime mentionné plus haut.
On peut d’ailleurs écrire des packages NPM spécifiquement pour ces runtimes, le site du WinterCG s’efforce de recenser les runtimes utilisables dans le champ export d’un fichier package.json.
Les middlewares edge de Next.js fournissent un moyen intégré de mettre en œuvre des fonctions Edge fournies par certains hébergeurs.
Cette fonctionnalité constitue une forme d‘“empowerment” des développeurs fullstack. Elles leurs permettent de gérer des fonctionnalités habituellement fournies par un proxy directement depuis le code d’une application Next.js et en utilisant JavaScript.
Vous avez apprécié cette ressource ?
Découvrez toutes nos formations Next.js, Astro.js et LangChain en présentiel ou en distanciel