Nuestra experiencia añadiendo Edge Runtime al SDK de Next.js
El SDK de Next.js de Logto ahora soporta Edge Runtime. En este artículo, vamos a compartir
uestra aventura, observando los obstáculos que enfrentamos, cómo los superamos, y las cosas interesantes que aprendimos en el camino.
SijieDeveloper
Deja de perder semanas en la autenticación de usuarios
Lanza aplicaciones seguras más rápido con Logto. Integra la autenticación de usuarios en minutos y concéntrate en tu producto principal.
Edge Runtime se ha convertido en una palabra de moda en el panorama tecnológico, impulsando funciones dinámicas y de baja latencia en plataformas como AWS Lambda@Edge y Cloudflare Workers a Vercel Edge. Subrayando su importancia, Vercel recientemente cambió "experimental-edge" a "edge", señalando el soporte oficial en su popular marco Next.js.
Con
uestro SDK de Next.js ganando tracción seria,
osotros en Logto pensamos, "¿Por qué
o agregar soporte para Edge Runtime?" Así que,
os remangamos y entramos directamente. En este artículo, vamos a compartir
uestra aventura, observando los obstáculos que enfrentamos, cómo los superamos, y las cosas interesantes que aprendimos en el camino.
Transformando módulos y dependencias para soporte de Edge Runtime#
Trabajar con Edge Runtime plantea algunos desafíos únicos, principalmente porque
o soporta todos los módulos y dependencias comúnmente utilizados en Node.js. Nos tropezamos con este problema con los módulos crypto, lodash, y iron-session,
ecesitando algunas soluciones innovadoras.
En un entorno Node.js, el módulo crypto sirve como un contenedor para las funciones criptográficas de OpenSSL. Desafortunadamente, Edge Runtime
o lo soporta. Pero
o te preocupes - la mayoría de los Edge Runtime vienen al rescate con soporte para el Web Crypto API. A pesar de algunas pequeñas diferencias, es un sustituto sólido para el módulo crypto. Por ejemplo, para generar bytes aleatorios:
Lodash es un favorito entre muchos desarrolladores por su utilidad, pero Edge Runtime
o es fan. ¿Nuestra solución? Cambiamos las funciones de Lodash por métodos
ativos de JavaScript, manteniendo
uestro código eficiente y legible.
Mientras que reemplazar la mayoría de las funciones de Lodash
o fue una tarea hercúlea, sí requirió cierta delicadeza. Echemos un vistazo a cómo recreamos la utilidad de "una vez" a
uestra manera:
La versión más reciente del módulo iron-session es compatible con Edge Runtime, así que todo lo que tuvimos que hacer fue actualizar
uestra versión. ¡Tan simple como eso!
Navegando las Intrincadas de "Response" en Edge Runtime#
Otro desafío al que
os enfrentamos al adaptar
uestro SDK para Edge Runtime fue manejar las diferencias en el objeto "Response". Aquí es cómo superamos estas diferencias:
A diferencia de en Node.js, una solicitud en Edge Runtime
o viene con una respuesta conmutable. Esto significa que tenemos que crearla llamando a new Response(), aquí hay un ejemplo de devolución de datos:
En Edge Runtime, el Response.body es un asunto de solo lectura. Esto significa que
o podíamos inicializar una respuesta antes de que los datos estuvieran preparados. Como resultado,
uestro fiel "withIronSessionApiRoute" (junto con otros middleware) tuvo que ser desplazado.
Para entender lo que reemplazamos, primero desempaquemos lo que withIronSessionApiRoute realmente hace:
Echa un vistazo a la cookie, construye un objeto de sesión, y lo liga a res.
Añade automáticamente el encabezado "set-cookie" a res si hay un cambio en la sesión.
Así que, ¿cómo emulamos esta funcionalidad en
uestro
uevo entorno de Edge Runtime?
Leer: Utilizamos la función getIronSession existente. Dándole una response vacía y falsa, recupera la sesión según sea
ecesario. Esto reemplazó el método "get" de req.session.
Escribir: Preparamos una response con datos por adelantado, luego usamos getIronSession en esta instancia de response para obtener el objeto de sesión. Una vez que tuvimos este objeto en
uestras manos, pudimos modificar la sesión según fuera
ecesario.
Pensamos en crear un paquete separado para Edge, pero rápidamente
os dimos cuenta de que era innecesario. La mayoría de
uestro código era compartido entre los dos runtimes, con sólo un puñado de líneas
ecesitando ajustes. Además, el uso del SDK sigue siendo más o menos el mismo en ambos runtimes, por lo que mantener un paquete unificado tenía más sentido.
En lugar de duplicar esfuerzos, decidimos expandir el paquete existente. Añadimos una carpeta "edge" justo en la raíz del paquete, acogedora junto a la antigua carpeta "src". Luego, actualizamos el archivo package.json, añadiendo una
ueva ruta a las "exportaciones". De esta manera, tanto Edge como Node.js runtimes podrían convivir en harmonía dentro del mismo paquete, con mínimo alboroto.
Al compartir
uestro viaje de abrazar Edge Runtime, esperamos inspirar y guiar a otros explorando caminos similares. Estén atentos para más actualizaciones con
uestro SDK de Next.js.
