Vår erfarenhet av att lägga till Edge Runtime i Next.js SDK

Introduktion#

Edge Runtime har blivit ett modeord inom teknologilandskapet, vilket driver dynamiska, låglatensfunktioner på plattformar från AWS Lambda@Edge och Cloudflare Workers till Vercel Edge. För att understryka dess betydelse ändrade Vercel nyligen "experimental-edge" till "edge", vilket signalerar officiellt stöd i deras populära Next.js ramverk.

Med vårt Next.js SDK i kraftig tillväxt tänkte vi på Logto, "Varför inte lägga till stöd för Edge Runtime?" Så vi kavlade upp ärmarna och kastade oss in. I den här artikeln kommer vi att dela med oss av vår äventyr, titta på de hinder vi stötte på, hur vi övervann dem och de coola saker vi lärde oss längs vägen.

Övergång av moduler och beroenden för stöd av Edge Runtime#

Att arbeta med Edge Runtime innebär vissa unika utmaningar, främst eftersom det inte stöder alla moduler och beroenden som ofta används i Node.js. Vi stötte på detta problem med modulerna crypto, lodash och iron-session, vilket krävde vissa innovativa lösningar.

Crypto#

I en Node.js-miljö fungerar crypto-modulen som ett omslag för OpenSSL-kryptografiska funktioner. Tyvärr stöds det inte av Edge Runtime. Men oroa dig inte - de flesta Edge Runtimes kommer till undsättning med stöd för Web Crypto API. Trots några mindre skillnader är det ett stabilt alternativ till crypto-modulen. Till exempel, för att generera slumpmässiga byte:

Och hashing:

Lodash#

Lodash är en favorit bland många utvecklare för sina verktyg, men Edge Runtime är inte ett fan. Vår lösning? Vi bytte ut Lodash-funktioner med inbyggda JavaScript-metoder, vilket höll vår kod både effektiv och läsbar.

Även om ersättningen av de flesta Lodash-funktioner inte var en jätteuppgift, krävde det lite finess. Låt oss ta en titt på hur vi återskapade verktyget "once" på vårt eget sätt:

Iron Session#

Den senaste versionen av iron-session-modulen är Edge Runtime-vänlig, så allt vi behövde göra var att uppdatera vår version. Så enkelt var det!

Navigering i Intricacies of "Response" i Edge Runtime#

En annan utmaning som vi stötte på när vi anpassade vårt SDK för Edge Runtime var att hantera skillnaderna i "Response"-objektet. Så här övervann vi dessa skillnader:

Skapa ett svar manuellt#

Till skillnad från i Node.js kommer en förfrågan i Edge Runtime inte med ett kommande svar. Detta innebär att vi måste skapa det genom att anropa new Response(), här är ett exempel på att returnera data:

Släppa "withIronSessionApiRoute"#

I Edge Runtime är Response.body en skrivskyddad angelägenhet. Detta innebär att vi inte kunde initiera ett svar innan data var förberett. Som ett resultat fick vår pålitliga "withIronSessionApiRoute" (tillsammans med annan mellankod) bänkas.

För att förstå vad vi ersatte, låt oss först packa upp vad withIronSessionApiRoute faktiskt gör:

1. Den tittar på kakan, konstruerar ett session-objekt och binder det till res.
2. Den lägger automatiskt till "set-cookie"-rubriken i res om det sker en förändring i sessionen.

Så, hur emulerade vi denna funktionalitet i vår nya Edge Runtime-inställning?

1. Läsa: Vi utnyttjade den befintliga getIronSession-funktionen. Genom att ge den ett tomt och falskt response, hämtar sessionen vid behov. Detta ersatte "get"-metoden från req.session.
2. Skrivning: Vi förberedde ett response med data i förväg och använde sedan getIronSession på denna response-instans för att få sessionobjektet. När vi hade detta objekt i våra händer kunde vi modifiera sessionen efter behov.

Omdirigering#

Omdirigering i Edge Runtime krävde att vi manuellt lade till en Location-rubrik till våra svar.

Ett paket, två miljöer#

I denna vår resa bestämde vi oss för att hålla oss till ett enda paket för att stödja både Edge och Node.js-miljöer.

Här är varför#

Vi funderade på att skapa ett separat paket för Edge, men insåg snabbt att det var onödigt. Det mesta av vår kod delades mellan de två miljöerna, med endast ett fåtal rader som behövde anpassas. Dessutom förblir användningen av SDK:et i stort sett densamma över båda miljöerna, så att bibehålla ett enhetligt paket var det mest meningsfulla.

Här är vad vi gjorde#

Istället för att duplicera insatser, bestämde vi oss för att utöka det befintliga paketet. Vi lade till en "edge"-mapp direkt i paketets rot, intill den gamla "src"-mappen. Sedan uppdaterade vi package.json-filen, och lade till en ny sökväg till "exports". På så sätt kunde både Edge och Node.js-miljöerna leva harmoniskt inom samma paket, med minimalt krångel.

Avslutning#

Du kan kolla in den fullständiga källkoden för vår Next.js SDK edge-del här.

Genom att dela vår resa med att omfamna Edge Runtime hoppas vi kunna inspirera och vägleda andra som utforskar liknande vägar. Håll utkik efter fler uppdateringar med vårt Next.js SDK.