Notre expérience d'ajout de Edge Runtime au SDK Next.js
Le SDK Next.js de Logto supporte désormais Edge Runtime. Dans cet article,
ous allons partager
otre aventure, en regardant les obstacles que
ous avons rencontrés, comment
ous les avons surmontés et les choses intéressantes que
ous avons apprises en cours de route.
SijieDeveloper
Arrêtez de perdre des semaines sur l'authentification des utilisateurs
Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.
Edge Runtime est devenu un mot à la mode dans le paysage technologique, propulsant des fonctions dynamiques et à faible latence dans des plateformes allant d'AWS Lambda@Edge et de Cloudflare Workers à Vercel Edge. Soulignant son importance, Vercel a récemment changé "experimental-edge" en "edge", signalant un support officiel dans leur populaire framework Next.js.
Avec
otre SDK Next.js qui gagne sérieusement en traction,
ous chez Logto avons pensé, "Pourquoi
e pas ajouter le support de Edge Runtime ?" Alors,
ous avons retroussé
os manches et
ous sommes lancés. Dans cet article,
ous allons partager
otre aventure, en regardant les obstacles que
ous avons rencontrés, comment
ous les avons surmontés et les choses intéressantes que
ous avons apprises en cours de route.
Transition des modules et des dépendances pour le support de Edge Runtime#
Travailler avec Edge Runtime pose quelques défis uniques, principalement parce qu'il
e supporte pas tous les modules et dépendances couramment utilisés dans Node.js. Nous avons rencontré ce problème avec les modules crypto, lodash, et iron-session,
écessitant des solutions de contournement innovantes.
Dans un environnement Node.js, le module crypto sert de wrapper pour les fonctions cryptographiques d'OpenSSL. Malheureusement, Edge Runtime
e le supporte pas. Mais
e vous inquiétez pas - la plupart des Edge Runtimes viennent à la rescousse avec le support pour l'API Web Crypto. Malgré quelques différences mineures, c'est un bon substitut pour le module crypto. Par exemple, pour générer des octets aléatoires :
Lodash est un favori parmi de
ombreux développeurs pour sa utilité, mais Edge Runtime
'est pas fan. Notre solution de contournement ? Nous avons remplacé les fonctions Lodash par des méthodes JavaScript
atives, gardant
otre code à la fois efficient et lisible.
Bien que remplacer la plupart des fonctions Lodash
'ait pas été une tâche herculéenne, elle a
écessité un certain doigté. Jetons un coup d'oeil à comment
ous avons recréé l'utilité de "once" à
otre façon :
La dernière version du module iron-session est compatible avec Edge Runtime, donc tout ce que
ous avons dû faire était de mettre à jour
otre version. Aussi simple que ça !
Naviguer dans les subtilités de "Response" dans Edge Runtime#
Un autre défi que
ous avons eu à relever lors de l'adaptation de
otre SDK pour Edge Runtime a été de gérer les différences dans l'objet "Response". Voici comment
ous avons surmonté ces différences :
Contrairement à Node.js, une requête dans Edge Runtime
e vient pas avec une réponse comming. Cela signifie que
ous devons la créer en appelant new Response(), voici un exemple de retour de données :
Dans Edge Runtime, le Response.body est une affaire en lecture seule. Cela signifie que
ous
e pouvons pas initialiser une réponse avant que les données soient préparées. En conséquence,
otre fidèle "withIronSessionApiRoute" (ainsi que d'autres middleware) a dû être mis sur le banc.
Pour comprendre ce que
ous avons remplacé, déballons d'abord ce que withIronSessionApiRoute fait réellement :
Il jette un coup d'œil au cookie, construit un objet de session, et le lie à res.
Il ajoute automatiquement l'en-tête "set-cookie" à res s'il y a un changement dans la session.
Alors, comment avons-nous émulé cette fonctionnalité dans
otre
ouveau cadre de Edge Runtime ?
Lecture: Nous avons utilisé la fonction getIronSession existante. En lui donnant une response vide et fausse, elle récupère la session selon les besoins. Cela a remplacé la méthode "get" de req.session.
Écriture: Nous avons préparé une response avec les données dès le départ, puis utilisé getIronSession sur cette instance response pour obtenir l'objet de session. Une fois que
ous avions cet objet entre les mains,
ous pouvions modifier la session en conséquence.
Nous pensions à créer un package séparé pour Edge, mais
ous
ous sommes vite rendu compte que c'était inutile. La plupart de
otre code était partagé entre les deux runtimes, avec seulement une poignée de lignes
écessitant des ajustements. De plus, l'utilisation du SDK reste à peu près la même sur les deux runtimes, donc maintenir un package unifié a eu le plus de sens.
Au lieu de dupliquer les efforts,
ous avons décidé d'élargir le package existant. Nous avons ajouté un dossier "edge" directement à la racine du package, juste à côté du vieux dossier "src". Ensuite,
ous avons mis à jour le fichier package.json, en ajoutant un
ouveau chemin dans "exports". De cette façon, les runtimes Edge et Node.js pouvaient cohabiter harmonieusement dans le même package, avec un minimum de tracas.
En partageant
otre parcours d'embrassement de Edge Runtime,
ous espérons inspirer et guider ceux qui explorent des chemins similaires. Restez à l'écoute pour plus de mises à jour avec
otre SDK Next.js.
