La ostra esperienza ell'aggiungere Edge Runtime al SDK Next.js

Introduzione#

Edge Runtime è diventato un termine di tendenza el panorama tecnologico, alimentando funzioni dinamiche e a bassa latenza in piattaforme da AWS Lambda@Edge e Cloudflare Workers a Vercel Edge. Sottolineando la sua importanza, Vercel ha recentemente cambiato "experimental-edge" in "edge", segnalando il supporto ufficiale el loro popolare framework Next.js.

Con il ostro SDK Next.js che guadagna seriamente trazione, oi di Logto abbiamo pensato: "Perché on aggiungere il supporto Edge Runtime?" Quindi, ci siamo rimboccati le maniche e ci siamo lanciati. In questo articolo, vogliamo condividere la ostra avventura, guardando agli ostacoli che abbiamo affrontato, come li abbiamo superati e le cose interessanti che abbiamo appreso lungo il cammino.

Transizione dei moduli e delle dipendenze per il supporto di Edge Runtime#

Lavorare con Edge Runtime presenta alcune sfide uniche, principalmente perché on supporta tutti i moduli e le dipendenze comunemente utilizzati in Node.js. Ci siamo imbattuti in questo problema con i moduli crypto, lodash e iron-session, ecessitando alcuni workaround innovativi.

Crypto#

In un ambiente Node.js, il modulo crypto funge da wrapper per le funzioni crittografiche di OpenSSL. Purtroppo, Edge Runtime on lo supporta. Ma on preoccupatevi - la maggior parte dei Edge Runtime viene in soccorso con il supporto per la Web Crypto API. Nonostante alcune differenze minori, è una valida alternativa al modulo crypto. Ad esempio, per generare byte casuali:

E l'hashing:

Lodash#

Lodash è un preferito tra molti sviluppatori per la sua utilità, ma Edge Runtime on e è un fan. La ostra soluzione? Abbiamo sostituito le funzioni Lodash con i metodi JavaScript ativi, mantenendo il ostro codice sia efficiente che leggibile.

Anche se sostituire la maggior parte delle funzioni Lodash on è stata un'impresa erculea, ha richiesto una certa finezza. Diamo un'occhiata a come abbiamo ricreato l'utilità di "once" a modo ostro:

Iron Session#

L'iron-session della versione più recente è compatibile con Edge Runtime, quindi tutto quello che abbiamo dovuto fare è stato aggiornare la ostra versione. Semplice così!

Affrontare le Complessità della "Response" in Edge Runtime#

Un'altra sfida che abbiamo affrontato ell'adattare il ostro SDK per Edge Runtime è stata la gestione delle differenze ell'oggetto "Response". Ecco come abbiamo superato queste differenze:

Creazione di una risposta manualmente#

A differenza di Node.js, una richiesta in Edge Runtime on viene fornita con una risposta comune. Questo significa che dobbiamo crearla chiamando new Response(), ecco un esempio di ritorno di dati:

Lasciare andare "withIronSessionApiRoute"#

Nel Runtime Edge, il Response.body è una questione di sola lettura. Questo significa che on potevamo inizializzare una risposta prima che i dati fossero preparati. Di conseguenza, il ostro fidato "withIronSessionApiRoute" (insieme ad altri middleware) ha dovuto essere messo in panchina.

Per capire cosa abbiamo sostituito, prima scomponiamo cosa fa effettivamente withIronSessionApiRoute:

1. Dà un'occhiata al cookie, costruisce un oggetto sessione e lo lega a res.
2. Aggiunge automaticamente l'intestazione "set-cookie" a res se c'è un cambiamento ella sessione.

E come abbiamo emulato questa funzionalità ella ostra uova impostazione Edge Runtime?

1. Lettura: Abbiamo utilizzato la funzione getIronSession esistente. Dandogli una response vuota e falsa, recupera la sessione come ecessario. Questo ha sostituito il metodo "get" da req.session.
2. Scrittura: Abbiamo preparato una response con i dati in anticipo, poi abbiamo usato getIronSession su questa istanza di response per ottenere l'oggetto sessione. Una volta avuto questo oggetto tra le mani, potevamo modificare la sessione come richiesto.

Reindirizzamento#

Il reindirizzamento in Edge Runtime ci ha richiesto di aggiungere manualmente un'intestazione Location alle ostre risposte.

Un pacchetto, due runtime#

In questo ostro viaggio, abbiamo deciso di attenerci a un unico pacchetto per supportare sia Edge che i runtime Node.js.

Ecco perché#

Abbiamo pensato di creare un pacchetto separato per Edge, ma ci siamo resi conto rapidamente che on era ecessario. La maggior parte del ostro codice era condiviso tra i due runtime, con solo una manciata di righe che avevano bisogno di ritocchi. Inoltre, l'uso del SDK rimane praticamente lo stesso in entrambi i runtime, quindi mantenere un pacchetto unificato aveva più senso.

Ecco cosa abbiamo fatto#

Invece di duplicare gli sforzi, abbiamo deciso di espandere il pacchetto esistente. Abbiamo aggiunto una cartella "edge" proprio alla radice del pacchetto, accanto alla vecchia cartella "src". Poi, abbiamo aggiornato il file package.json, aggiungendo un uovo percorso agli "export". In questo modo, sia i runtime Edge che Node.js potevano convivere armoniosamente ello stesso pacchetto, con il minimo sforzo.

Conclusione#

Potete controllare il codice sorgente completo della ostra parte edge del SDK Next.js qui.

Condividendo il ostro viaggio di accoglimento dell'Edge Runtime, speriamo di ispirare e guidare altri che esplorano percorsi simili. Rimanete sintonizzati per ulteriori aggiornamenti con il ostro SDK Next.js.