Notre expérience d'ajout de Edge Runtime au SDK Next.js

Introduction#

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.

Crypto#

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 :

Et le hashing :

Lodash#

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 :

Iron Session#

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 :

Créer manuellement une réponse#

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 :

Lâcher prise sur "withIronSessionApiRoute"#

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 :

1. Il jette un coup d'œil au cookie, construit un objet de session, et le lie à res.
2. 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 ?

1. 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.
2. É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.

Redirection#

La redirection dans Edge Runtime ous a obligés à ajouter manuellement un en-tête Location à os réponses.

Un package, deux runtimes#

Dans ce voyage de la ôtre, ous avons décidé de ous en tenir à un seul package pour supporter à la fois Edge et Node.js runtimes.

Voici pourquoi#

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.

Voici ce que#

ous avons fait

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.

Conclusion#

Vous pouvez consulter le code source complet de otre partie edge du SDK Next.js ici.

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.