Unsere Erfahrung bei der Hinzufügung von Edge Runtime zum Next.js SDK
Logtos Next.js SDK unterstützt
un Edge Runtime. 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.
SijieDeveloper
Verschwenden Sie keine Wochen mit Benutzerauthentifizierung
Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.
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.
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:
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:
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:
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:
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:
Es wirft einen Blick auf das Cookie, erstellt ein Sitzungsobjekt und bindet es an res.
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?
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.
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.
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.
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.
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.
