Nuestra experiencia añadiendo Edge Runtime al SDK de Next.js

Introducción#

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.

Crypto#

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:

Y hashing:

Lodash#

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:

Iron Session#

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:

Creando una respuesta manualmente#

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:

Dejando ir "withIronSessionApiRoute"#

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:

1. Echa un vistazo a la cookie, construye un objeto de sesión, y lo liga a res.
2. 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?

1. 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.
2. 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.

Redirigiendo#

La redirección en Edge Runtime os obligó a añadir manualmente un encabezado Location a uestras respuestas.

Un paquete, dos runtimes#

En este viaje uestro, decidimos mantenernos en un solo paquete para soportar tanto Edge como Node.js runtimes.

Aquí está por qué#

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.

Aquí está lo que hicimos#

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.

Finalizando#

Puedes echar un vistazo al código fuente completo de uestra parte edge del SDK de Next.js aquí.

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.