Onze ervaring met het toevoegen van Edge Runtime aan Next.js SDK

Inleiding#

Edge Runtime is een modewoord geworden in het technologielandschap, omdat het dynamische, laag-latentie functies aandrijft op platforms van AWS Lambda@Edge en Cloudflare Workers tot Vercel Edge. Om het belang ervan te onderstrepen, heeft Vercel onlangs "experimental-edge" veranderd in "edge", wat officiële ondersteuning aangeeft in hun populaire Next.js framework.

Met onze Next.js SDK die serieuze tractie krijgt, dachten we bij Logto: "Waarom niet Edge Runtime-ondersteuning toevoegen?" Dus hebben we de mouwen opgestroopt en zijn we erin gedoken. In dit artikel gaan we ons avontuur delen, waarin we kijken naar de obstakels die we tegenkwamen, hoe we ze hebben overwonnen en de coole dingen die we onderweg hebben geleerd.

Modules en afhankelijkheden aanpassen voor Edge Runtime-ondersteuning#

Werken met Edge Runtime brengt enkele unieke uitdagingen met zich mee, voornamelijk omdat het niet alle modules en afhankelijkheden ondersteunt die veel in Node.js worden gebruikt. We liepen tegen dit probleem aan met de modules crypto, lodash en iron-session, waardoor enkele innovatieve oplossingen noodzakelijk waren.

Crypto#

In een Node.js-omgeving dient de crypto-module als een wrapper voor OpenSSL cryptografische functies. Helaas ondersteunt Edge Runtime het niet. Maar maak je geen zorgen - de meeste Edge Runtimes komen te hulp met ondersteuning voor de Web Crypto API. Ondanks enkele kleine verschillen is het een solide vervanging voor de crypto-module. Bijvoorbeeld, om willekeurige bytes te genereren:

En bij hashing:

Lodash#

Lodash is een favoriet bij veel ontwikkelaars vanwege de bruikbaarheid, maar Edge Runtime is geen fan. Onze oplossing? We vervingen Lodash-functies door native JavaScript-methoden, waardoor onze code zowel efficiënt als leesbaar bleef.

Hoewel het vervangen van de meeste Lodash-functies geen Herculeaanse taak was, vergde het wel enige finesse. Laten we eens kijken hoe we de functionaliteit van "once" op onze eigen manier opnieuw creëerden:

Iron Session#

De nieuwste versie van de iron-session module is Edge Runtime-vriendelijk, dus we hoefden alleen maar onze versie te updaten. Zo simpel is dat!

Navigeren door de complexiteit van "Response" in Edge Runtime#

Een andere uitdaging die we tegenkwamen bij het aanpassen van onze SDK voor Edge Runtime was het omgaan met de verschillen in het "Response"-object. Hier is hoe we deze verschillen overwonnen:

Een reactie handmatig maken#

In tegenstelling tot in Node.js, komt een verzoek in Edge Runtime niet met een bijgevoegde reactie. Dit betekent dat we het handmatig moeten maken door new Response() aan te roepen, hier is een voorbeeld van het retourneren van data:

Afstand doen van "withIronSessionApiRoute"#

In de Edge Runtime is Response.body een alleen-lezen aangelegenheid. Dit betekent dat we geen reactie konden initialiseren voordat de data was voorbereid. Hierdoor moesten we afstand doen van onze vertrouwde "withIronSessionApiRoute" (samen met andere middleware).

Om te begrijpen wat we vervingen, laten we eerst ontleden wat withIronSessionApiRoute eigenlijk doet:

1. Het werpt een blik op de cookie, creëert een sessieobject en koppelt het aan res.
2. Het voegt automatisch de "set-cookie" header toe aan res als er een verandering is in de sessie.

Dus, hoe hebben we deze functionaliteit nagebootst in onze nieuwe Edge Runtime-omgeving?

1. Lezen: We maakten gebruik van de bestaande getIronSession functie. Door het een lege en nep respons te geven, haalt het de sessie op zoals nodig. Dit verving de "get" methode van req.session.
2. Schrijven: We maakten een respons met data vooraf en gebruikten getIronSession op deze respons instantie om het sessieobject te verkrijgen. Zodra we dit object in handen hadden, konden we de sessie wijzigen zoals nodig.

Redirecties#

Bij het omleiden in Edge Runtime moesten we handmatig een Location header toevoegen aan onze reacties.

Eén pakket, twee runtimes#

In dit avontuur van ons hebben we besloten om vast te houden aan één enkel pakket om zowel Edge als Node.js runtimes te ondersteunen.

Hier is waarom#

We dachten eraan om een apart pakket voor Edge te maken, maar realiseerden ons snel dat dit niet nodig was. Het merendeel van onze code werd gedeeld tussen de twee runtimes, met slechts enkele regels die aanpassingen nodig hadden. Bovendien blijft het gebruik van de SDK vrijwel hetzelfde voor beide runtimes, dus het handhaven van een verenigd pakket was het meest logisch.

Hier is wat we deden#

In plaats van de inspanningen te verdubbelen, hebben we besloten om het bestaande pakket uit te breiden. We hebben een "edge" map toegevoegd direct in de hoofdmap van het pakket, naast de oude "src" map. Vervolgens hebben we het package.json bestand bijgewerkt met een nieuw pad naar de "exports". Op deze manier konden zowel Edge als Node.js runtimes harmonieus binnen hetzelfde pakket leven, met minimaal gedoe.

Afronding#

Je kunt de volledige broncode van ons Next.js SDK edge-onderdeel hier bekijken.

Door ons verhaal van het omarmen van Edge Runtime te delen, hopen we anderen te inspireren en te begeleiden die vergelijkbare wegen verkennen. Blijf op de hoogte voor meer updates met onze Next.js SDK.