Kokemuksemme Edge Runtimen lisäämisestä Next.js SDK:han

Johdanto#

Edge Runtime on noussut muotisanaksi teknologiakentässä, tuottaen dynaamisia, pieniviiveisiä toimintoja alustoilla, kuten AWS Lambda@Edge ja Cloudflare Workers sekä Vercel Edge. Sen merkityksen korostamiseksi Vercel muutti äskettäin "experimental-edge" muotoon "edge", mikä merkitsee virallista tukea heidän suositussa Next.js -kehitysympäristössään.

Kun Next.js SDK:mme saavutti vakavaa vetovoimaa, me Logtossa ajattelimme, "Miksi emme lisäisi Edge Runtime -tukea?" Niinpä käärimme hihat ja ryhdyimme toimeen. Tässä artikkelissa jaamme seikkailumme, katsomme kohtaamiamme esteitä, miten ylitimme ne ja mitä siistejä juttuja opimme matkan varrella.

Modulien ja riippuvuuksien siirtäminen Edge Runtime -tueksi#

Työskentely Edge Runtimen kanssa asettaa ainutlaatuisia haasteita, pääasiassa siksi, että se ei tue kaikkia moduuleja ja riippuvuuksia, joita Node.js:ssä yleisesti käytetään. Kohtasimme tämän ongelman crypto-, lodash- ja iron-session-moduulien kanssa, mikä vaati innovatiivisia kiertotapoja.

Crypto#

Node.js-ympäristössä crypto-moduuli toimii OpenSSL-salaustoimintojen kääreenä. Valitettavasti Edge Runtime ei tue sitä. Älä kuitenkaan huoli - useimmat Edge Runtime -alustat tukevat Web Crypto API:a. Huolimatta pienistä eroista, se toimii mainiosti crypto-moduulin sijaan. Esimerkiksi satunnaisten tavujen tuottaminen:

Ja hajautus:

Lodash#

Lodash on monen kehittäjän suosikki käyttökelpoisuutensa vuoksi, mutta Edge Runtime ei ole sen fani. Ratkaisumme? Vaihdoimme Lodash-funktiot natiivilla JavaScript-menetelmillä, pitäen koodimme sekä tehokkaana että luettavana.

Vaikka useimpien Lodash-funktioiden korvaaminen ei ollutkaan Herculeuksen tehtävä, se vaati jonkin verran hienosäätöä. Katsotaanpa, kuinka loimme "once"-toiminnallisuuden uudelleen omalla tavallamme:

Iron Session#

iron-session-moduulin uusin versio on Edge Runtime -ystävällinen, joten meidän piti vain päivittää versiomme. Niin yksinkertaista!

"Response"-objektin vivahteiden hallitseminen Edge Runtimessa#

Toinen haaste, johon törmäsimme sovittaessamme SDK:mme Edge Runtimelle, oli erilaisten "Response"-objektien käsittely. Näin ylitimme nämä erot:

Vastauksen luominen manuaalisesti#

Toisin kuin Node.js:ssä, pyyntö Edge Runtimessa ei sisällä valmista vastausta. Tämä tarkoittaa, että meidän on luotava se kutsumalla new Response(), tässä on esimerkki datan palauttamisesta:

"withIronSessionApiRoute":sta luopuminen#

Edge Runtimessa Response.body on vain luku -ominaisuus. Tämä tarkoittaa, että emme voineet alustaa vastausta ennen datan valmiutta. Tästä syystä luotettu "withIronSessionApiRoute" (yhdessä muiden väliohjelmistojen kanssa) jouduttiin penkittämään.

Ymmärtääksemme, mitä korvasimme, puretaan ensin, mitä withIronSessionApiRoute todella tekee:

1. Se vilkaisee evästeitä, rakentaa istunto-objektin ja sitoo sen res:iin.
2. Se lisää automaattisesti "set-cookie"-otsikon res:iin, jos istunnossa tapahtuu muutoksia.

Joten, kuinka emuloimme tätä toiminnallisuutta uudessa Edge Runtime -ympäristössämme?

1. Lukeminen: Hyödynsimme olemassa olevaa getIronSession-funktiota. Antamalla sille tyhjän ja tekaistun "response":n, saimme istunnon tarpeen mukaan. Tämä korvasi "get"-menetelmän req.session-kohdasta.
2. Kirjoittaminen: Valmistimme "response":n tiedoilla etukäteen, sitten käytimme getIronSession:a tähän response-instanssiin saadaksemme istunto-objektin. Kun meillä oli tämä objekti käsissämme, voimme muokata istuntoa tarpeen mukaan.

Uudelleenohjaus#

Uudelleenohjaus Edge Runtimessa vaati meitä lisäämään manuaalisesti Location -otsikon vastauksiimme.

Yksi paketti, kaksi runtimea#

Tämän matkan aikana päätimme pitäytyä yhdessä paketissa tukemaan sekä Edge- että Node.js-runtimaa.

Tässä miksi#

Ajattelimme luoda erillisen paketin Edgelle, mutta nopeasti huomasimme sen olevan tarpeetonta. Suurin osa koodistamme jaettiin2 molempien runtimien välillä, ja vain muutama rivi tarvitsi hienosäätöä. Lisäksi SDK:n käyttö pysyy melko samana molemmissa runtimissa, joten yhtenäisen paketin ylläpito oli järkevintä.

Tässä mitä teimme#

Sen sijaan, että tekisimme päällekkäistä työtä, päätimme laajentaa olemassa olevaa pakettia. Lisäsimme "edge"-kansion suoraan paketin juureen, vanhan "src"-kansion viereen. Sitten päivitimme package.json -tiedoston, lisäsimme uuden polun "exports":iin. Näin sekä Edge- että Node.js-runtimet pystyivät elämään harmonisesti saman paketin sisällä, vaivattomasti.

Yhteenveto#

Voit tarkistaa koko lähdekoodin Next.js SDK-mme edge-osasta täältä.

Jakamalla matkamme Edge Runtimen omaksumisesta toivomme inspiroivamme ja opastavamme muita tutkimaan samankaltaisia reittejä. Pysy kuulolla saadaksesi lisää päivityksiä Next.js SDK:stamme.