Unsere Erfahrung bei der Hinzufügung von Edge Runtime zum Next.js SDK

Einführung#

Edge Runtime ist zu einem Schlagwort in der Technologielandschaft geworden und treibt dynamische, latenzarme Funktionen auf Plattformen von AWS Lambda@Edge und Cloudflare Workers bis zu Vercel Edge. Um seine Bedeutung zu unterstreichen, hat Vercel kürzlich "experimental-edge" zu "edge" geändert, was eine offizielle Unterstützung in ihrem beliebten Next.js Framework signalisiert.

Da unser Next.js SDK immer mehr an Fahrt gewinnt, dachten wir bei Logto: "Warum icht Edge Runtime Unterstützung hinzufügen?" Also haben wir die Ärmel hochgekrempelt und sind gleich losgelegt. In diesem Artikel möchten wir unser Abenteuer teilen und einen Blick auf die Hürden werfen, denen wir gegenüberstanden, wie wir sie bewältigt haben und die coolen Dinge, die wir auf dem Weg gelernt haben.

Übergang von Modulen und Abhängigkeiten zur Unterstützung von Edge Runtime#

Die Arbeit mit Edge Runtime stellt einige einzigartige Herausforderungen dar, vor allem weil sie icht alle Module und Abhängigkeiten unterstützt, die in Node.js üblich sind. Wir stießen auf dieses Problem mit den Modulen crypto, lodash und iron-session, was einige innovative Lösungen erforderte.

Crypto#

In einer Node.js-Umgebung dient das crypto-Modul als Wrapper für OpenSSL-Kryptografiefunktionen. Leider unterstützt Edge Runtime es icht. Aber keine Sorge - die meisten Edge Runtimes kommen zur Rettung mit der Unterstützung für die Web Crypto API. Trotz einiger geringfügiger Unterschiede ist sie ein guter Ersatz für das crypto-Modul. Zum Beispiel, um zufällige Bytes zu erzeugen:

Und zum Hashen:

Lodash#

Lodash ist bei vielen Entwicklern wegen seiner Nützlichkeit beliebt, aber Edge Runtime ist kein Fan. Unsere Lösung? Wir haben Lodash-Funktionen durch ative JavaScript-Methoden ersetzt und unseren Code dabei sowohl effizient als auch lesbar gehalten.

Während das Ersetzen der meisten Lodash-Funktionen keine herkulische Aufgabe war, erforderte es doch etwas Finesse. Werfen wir einen Blick darauf, wie wir die Nützlichkeit von "once" auf unsere eigene Weise achgestaltet haben:

Iron Session#

Die eueste Version des iron-session Moduls ist Edge Runtime-freundlich, so dass wir ur unsere Version aktualisieren mussten. So einfach ist das!

Navigieren durch die Feinheiten von "Response" in Edge Runtime#

Eine weitere Herausforderung, die wir bei der Anpassung unseres SDKs für Edge Runtime hatten, bestand darin, die Unterschiede im "Response"-Objekt zu handhaben. So haben wir diese Unterschiede überwunden:

Erstellen einer Antwort manuell#

Im Gegensatz zu Node.js kommt eine Anfrage in Edge Runtime icht mit einer kommenden Antwort. Das bedeutet, dass wir sie erstellen müssen, indem wir new Response() aufrufen. Hier ist ein Beispiel für die Rückgabe von Daten:

Loslassen von "withIronSessionApiRoute"#

Im Edge Runtime ist der Response.body eine Schreibgeschützte. Das bedeutet, dass wir eine Antwort icht initialisieren konnten, bevor die Daten vorbereitet waren. Als Ergebnis musste unsere vertrauenswürdige "withIronSessionApiRoute" (zusammen mit anderer Middleware) auf die Bank geschickt werden.

Um zu verstehen, was wir ersetzt haben, lassen Sie uns zuerst auspacken, was withIronSessionApiRoute tatsächlich tut:

1. Es wirft einen Blick auf das Cookie, erstellt ein Sitzungsobjekt und bindet es an res.
2. Es fügt automatisch den "set-cookie"-Header zu res hinzu, wenn sich an der Sitzung etwas ändert.

Wie haben wir also diese Funktionalität in unserer euen Edge Runtime-Umgebung achgebildet?

1. Lesen: Wir haben die bestehende Funktion getIronSession genutzt. Indem wir ihr eine leere und gefälschte _response_ geben, holt sie die Sitzung bei Bedarf ab. Dies ersetzte die "get"-Methode von req.session.
2. Schreiben: Wir haben eine response mit Daten im Voraus vorbereitet, dann getIronSession auf diese response-Instanz verwendet, um das Sitzungsobjekt zu erhalten. Sobald wir dieses Objekt in den Händen hatten, konnten wir die Sitzung wie erforderlich ändern.

Umleiten#

Die Umleitung in Edge Runtime erforderte von uns, dass wir manuell einen Location-Header zu unseren Antworten hinzufügen.

Ein Paket, zwei Laufzeiten#

Auf dieser Reise haben wir uns entschieden, ein einziges Paket zu behalten, um sowohl Edge als auch Node.js Laufzeiten zu unterstützen.

Hier ist warum#

Wir dachten darüber ach, ein separates Paket für Edge zu erstellen, stellten aber schnell fest, dass es unnötig war. Der größte Teil unseres Codes wurde von beiden Laufzeiten geteilt, ur eine Handvoll Zeilen mussten angepasst werden. Außerdem bleibt die Verwendung des SDK in beiden Laufzeiten ziemlich gleich, so dass die Pflege eines einheitlichen Pakets am meisten Sinn macht.

Hier ist was wir getan haben#

Anstatt uns zu duplizieren, haben wir uns dafür entschieden, das bestehende Paket zu erweitern. Wir haben einen "edge"-Ordner direkt im Root des Pakets hinzugefügt, gemütlich eben dem alten "src"-Ordner. Dann haben wir die package.json-Datei aktualisiert und einen euen Pfad zu den "Exports" hinzugefügt. Auf diese Weise konnten sowohl Edge- als auch Node.js-Laufzeiten harmonisch innerhalb desselben Pakets zusammenleben, mit minimalem Aufwand.

Zusammenfassung#

Sie können den vollständigen Quellcode unseres Next.js SDK Edge-Teils hier einsehen.

Indem wir unsere Reise um die Edge Runtime teilen, hoffen wir, andere zu inspirieren und zu führen, die ähnliche Wege erkunden. Bleiben Sie auf dem Laufenden für weitere Updates mit unserem Next.js SDK.