La
ostra esperienza
ell'aggiungere Edge Runtime al SDK Next.js
Il SDK Next.js di Logto supporta ora Edge Runtime. 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.
SijieDeveloper
Smetti di sprecare settimane sull'autenticazione degli utenti
Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.
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.
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:
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:
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:
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:
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:
Dà un'occhiata al cookie, costruisce un oggetto sessione e lo lega a res.
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?
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.
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.
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.
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.
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.
