Acceso a la base de datos en el Edge con Cloudflare Workers y Prisma

Hola, amigos. Hoy hablaré sobre el acceso a la base de datos en el borde con Cloud Flarewalkers. Mi nombre es Alex, y soy un defensor del desarrollo en Prisma. No dudes en contactarme después de la charla si tienes alguna pregunta, o simplemente cualquier pregunta aleatoria o conexión.

Esta charla se dividirá en cuatro secciones. La primera parte tratará sobre Cloud Flarewalkers, o el borde. Discutiremos qué es, cómo es diferente de las plataformas sin servidor tradicionales y los dolores de crecimiento de las sin servidor. La segunda sección echará un vistazo a Prisma y al Proxy de Datos de Prisma, explorando cómo el Proxy de Datos te ayuda a interactuar con tu base de datos en el borde. Y la tercera parte, o la tercera sección, será la parte emocionante, donde tendremos una demostración. Migraremos una aplicación que utiliza un archivo JSON para almacenar y recuperar citas, y moveremos los datos a una base de datos y lo desplegaremos en el borde. Finalmente, haremos un resumen de la charla al final. Y por ahora, vamos a empezar.

Entonces, ¿qué es el borde? Parece ser una palabra de moda que se usa mucho, pero ¿qué significa? El borde es una forma de cómputo sin servidor que está distribuido. Y en el contexto de los trabajadores de CloudFlare, se implementa en la red de centros de datos de CloudFlare.

Ahora que entiendes qué es el borde y cómo funciona CloudFlare, echemos un vistazo a cómo los trabajadores de CloudFlare son diferentes de los servidores sin servidor tradicionales. Como mencioné antes, está distribuido. Las funciones sin servidor tradicionales se implementan en centros de datos o regiones específicas. En contraste, los trabajadores de CloudFlare ejecutan el código de tu aplicación mucho más cerca de tu usuario, incluso podría estar en la misma ciudad. Los trabajadores de CloudFlare también son significativamente más ligeros porque la plataforma se basa en el motor V8. Es el mismo motor que alimenta los navegadores basados en Chromium como Chrome y Edge, y también el tiempo de ejecución de Node.js. Por lo tanto, cada vez que se invoca tu trabajador de CloudFlare, en lugar de aprovisionar un contenedor completo para tu función sin servidor, el trabajador de CloudFlare crea un aislamiento de V8 que es significativamente más pequeño. Y si has oído hablar del problema de inicio en frío en los servidores sin servidor, entonces entenderás por qué esta es una tecnología emocionante.

Los trabajadores de CloudFlare también ofrecen un alto rendimiento. Esto se suma a los dos primeros puntos. Debido a que el entorno es significativamente más ligero, lo que conduce a un tiempo de inicio más corto, o incluso posiblemente ninguno. Y también experimentarás una latencia más baja cada vez que invoques tu función porque se invocará desde el centro de datos que está más cerca de ti. Ahora sé que todo esto suena encantador, pero los trabajadores de CloudFlare todavía sufren los mismos problemas que las funciones sin servidor tradicionales en el contexto de las bases de datos. Por lo tanto, la conexión a las bases de datos sigue siendo un desafío desde los trabajadores de CloudFlare. Esto se debe a que el motor V8 solo admite conexiones basadas en HTTP. Sin embargo, las bases de datos tradicionales dependen de conexiones TCP de larga duración.

Esto se vuelve frustrante. Las diferentes bases de datos presentan diferentes implementaciones de las interfaces de cómo puedes conectarte a ellas, lo cual es caótico y está en marcha. Las conexiones a la base de datos también son estado-dependientes, mientras que los entornos sin servidor son sin estado, lo que significa que puedes quedarte fácilmente sin conexiones a la base de datos porque cada trabajador crea un nuevo grupo de conexiones. Y cuando te quedas sin conexiones, las solicitudes en tu aplicación comenzarán a fallar.

Entonces, ¿cómo puedes resolver este problema? Bueno, tienes varias opciones disponibles, al igual que en el resto del ecosistema de JavaScript. Una opción sería utilizar soluciones específicas de CloudFlare como el almacén de clave-valor del trabajador y los objetos duraderos. La segunda opción, si tienes una base de datos existente, es usar Postgres, que convierte tu base de datos Postgres existente en una API RESTful. Otra opción sería convertir, usar los controladores de Postgres y MySQL y modificar para usar HTTP con Deno, creo. Y finalmente, la esencia de esta charla, que es el proxy de datos de Prisma y esta charla se centrará en esto, pero siéntete libre de probar las otras opciones por ti mismo también.

Entonces, Prisma es un ORM de última generación y seguro en cuanto a tipos para NodeJS que funciona tanto con JavaScript como TypeScript. Admite varias bases de datos como SQLite, MySQL, Postgres, SQL Server y también CockroachDB y MongoDB, que aún están en vista previa. Los principales beneficios de Prisma es que aumenta la productividad al permitir a los desarrolladores consultar los datos de manera natural y familiar, y también proporciona un modelo de datos legible para los humanos. Prisma también aumenta la confianza del desarrollador con la seguridad de tipos, el autocompletado, y la API robusta para interactuar con tu base de datos. Entonces, incluso si no usas TypeScript en tu proyecto, la mayoría de los editores proporcionarán autocompletado para tus consultas de base de datos cuando estés usando Prisma.

Y la herramienta Prisma consta de tres componentes. Prisma Client. Eso es el cliente generado automáticamente y seguro en cuanto a tipos. Prisma Migrate. Esa es la herramienta declarativa de modelado y migración de datos. Genera migraciones de esquema de base de datos SQL totalmente personalizables basadas en tu esquema de Prisma. Y el tercer componente es Prisma Studio. Es una interfaz gráfica de usuario moderna e intuitiva para tu base de datos.

Y ahora esto nos lleva al proxy de datos de Prisma. Es un intermediario entre tu aplicación y tu serverless, tu aplicación o función serverless y tu base de datos. Te ayuda a gestionar grupos de conexiones asegurándote de no agotar tus límites de conexiones que podrían provocar solicitudes fallidas. Entonces, cuando consultas tu base de datos, el cliente de Prisma se conectará a tu base de datos a través del proxy de datos que utiliza HTTP.

Ahora, esto es emocionante porque te permite aprovechar todas las partes buenas de tu confiable base de datos relacional y las herramientas de desarrollo de Prisma en el edge. Aún puedes adoptar almacenes de datos específicos de CloudFlare, como Work As Gavy y Durable Objects para casos específicos donde tenga sentido, al tiempo que te beneficias de consultar tu base de datos central para la mayoría de tu aplicación. Ahora esto nos lleva a la parte más emocionante de la charla, que es la demo. Lo que haremos es convertir la aplicación que utiliza un archivo JSON para obtener y crear citas o obtener citas por ID y moveremos esa aplicación migraremos los datos a una base de datos y convertiremos las rutas existentes para comenzar a utilizar Prisma para consultar los datos.

Ahora vamos a pasar a la demostración. Ya he configurado la plantilla base para el proyecto. Tiene tres rutas específicas en el archivo index.ts, que es el router.getQuotes aquí. Podemos obtener citas por ID y también hacemos un post que en realidad no crea una nueva cita, sino que simplemente devuelve lo que enviaste. El proyecto también utiliza Webpack. Tiene una configuración mínima de Webpack para que funcione. Voy a descomentar el alias de Prisma que usaremos en una sección posterior para la demostración. El alias de Prisma te ayudará a resolver correctamente la dependencia del cliente de Prisma cuando estés consultando una base de datos. Así que vamos a ello. El primer paso para configurar nuestro proyecto es agregar Prisma. Voy a instalar la CLI de Prisma como una dependencia de desarrollo y luego instalar el cliente de Prisma como una dependencia normal. Esperaré a que se cargue por un momento. Ahora que hemos instalado la dependencia del cliente de Prisma, voy a inicializar nuestro proyecto para comenzar a utilizar Prisma ejecutando el comando npx prisma init. Lo que hace este comando es crear un nuevo directorio en nuestro proyecto llamado Prisma con el archivo schema.prisma.

Este archivo schema.prisma se utilizará para definir nuestros modelos de data, que se aplicarán a nuestra database. El comando también crea un archivo .env, donde almacenaremos nuestras variables de entorno para el proyecto.

Por ahora, agregaré y pegaré mi cadena de conexión a mi database. Ahora que está hecho, iré al archivo schema.prisma. Y comenzar a usar el proxy de data en tu proyecto. Puedes habilitarlo agregando la bandera de función de vista previa en el bloque de generador en tu archivo schema.prisma. Data proxy. Data proxy. Eso está hecho. Cerrar esto. Expandir esto.

Ahora vamos a modelar nuestros data. Nuestra cita, como podemos ver en el archivo data.json, contiene tres campos, tres propiedades, que son el ID, el contenido y el autor. Obtuve esto de una API en Internet. Esto estará en el repositorio stata que compartiré antes de que termine esta charla.

Entonces crearemos un nuevo modelo, cita, que tendrá un ID, que es una cadena, y queremos que este sea generado automáticamente. También tenemos la propiedad de contenido, el campo de contenido, que será de tipo cadena. También queremos tener el autor, que es una cadena, y si quieres, puedes agregar un campo de creado en tu tabla, que será una marca de tiempo de cuándo se agregó el registro a la database. Y queremos que esto se genere automáticamente utilizando la función now.

Ahora que hemos modelado, apliquemos este esquema, o el esquema que acabamos de crear, a nuestra database. Ejecutaré el comando npx Prisma DB push para aplicar lo que tenemos a nuestra database. Sí, como tenía datos existentes, los eliminaré.

El siguiente paso es migrar o cargar la database con los códigos que tenemos en el archivo data.json. Entonces, dentro del archivo schema.prisma, dentro de la carpeta Prisma, agregaré un archivo seed.ts. Y aquí, pegaré un código, que explicaré en un momento. Lo que hace es importar el cliente Prisma de nuestros módulos de nodo, y también estamos importando las citas del archivo JSON. Y como es una matriz de aproximadamente 500 citas, recorreremos cada una de ellas e insertaremos un registro en nuestra database dentro de este bloque.

El siguiente paso ahora es ejecutar este archivo, para que podamos ver los datos. Usaré ts node para ejecutar nuestro archivo TypeScript. Entonces, npx, ts node, prisma, c.ts.

Espera un momento. Veamos. Y está hecho. Hasta ahora hemos inicializado nuestro proyecto con Prisma y hemos migrado nuestros datos existentes data del archivo JSON a la base de datos. El siguiente paso es configurar nuestros proyectos en la Plataforma de Datos de Prisma para poder obtener una clave de API o una cadena de conexión que nos permita comunicarnos con nuestra base de datos mediante HTTP.

El primer paso es ir a GitHub y crear un nuevo repositorio. Lo llamaré Prisma CFW, abreviatura de Cloud Flow Workers. Lo haré privado y lo crearé. Localmente, primero confirmaré mis archivos en GitHub. Pero primero inicializaré, obtenerlo, y haré git add, y luego confirmaremos todos nuestros archivos. Bien, ahora eso está hecho, continuaremos e importaremos nuestro proyecto en la Plataforma de Datos de Prisma, pero primero verifiquemos si los cambios se sincronizaron.

Oh, me salté un paso en el que necesitábamos agregar un origen primero, antes de poder enviarlo a GitHub. Pegaré el comando de GitHub. Los cambios se han enviado a GitHub, así que si actualizo esto, deberíamos poder ver nuestros nuevos cambios, los cambios que acabamos de hacer. Genial, ese es un buen progreso. El siguiente paso es importar el proyecto en la Plataforma de Datos de Prisma. Así que continuaré y crearé, hacer clic en Nuevo Proyecto. Le daré un nombre, Prisma CFW. Importaremos el repositorio, Prisma CFW. Todo está bien. Siguiente, continuaré, usaré mi propia base de datos y también pegaré mi cadena de conexión. El proxy de datos de Prisma se generará una vez que completemos la configuración del proyecto en la plataforma de datos. Bien. Ahora eso está hecho. Se te proporcionan dos cadenas de conexión una vez que se haya configurado el proyecto. La primera será la clave de API del proxy de datos que copiaré. Y la segunda es tu cadena de conexión a tu base de datos. He terminado, así que haré clic en hecho aquí y todo está bien. Así que volvamos a nuestro proyecto. Y en el archivo .env, crearé una duplicado de la variable de entorno de la URL de la base de datos y pegaré la que acabamos de crear pero comentaré la primera.

Dále, sí. Genial, ahora eso está hecho. Es hora de refactorizar nuestra aplicación. Lo siento, no ahora. Entonces, volvamos a nuestro archivo index.ts, reemplazaremos nuestra importación de data.json con la importación de Prisma Client. Y luego crearemos una nueva instancia de Prisma Client. Y primero refactorizaremos nuestra primera ruta. Haremos una consulta para obtener todas las citas de nuestra database. Entonces const quotes es igual a await Prisma.quote.findMany. Eso está hecho. Refactoricemos ahora la obtención de una cita por ID. Entonces const result es igual a await Prisma.quote.findUnique. Y luego necesitamos proporcionar una cláusula where que requiere el ID, que viene del valor de params aquí. Por último, necesitaremos poder crear un nuevo registro. Así que aquí esperaremos a Prisma.quote.create. Y necesitaremos pasar la propiedad data, que requiere los valores de contenido y autor, que pueden ser del cuerpo de la solicitud. Ahora eso está hecho, el siguiente paso es regenerar nuestro cliente Prisma. para que pueda usar el proxy de datos de Prisma.

Ahora que has terminado de refactorizar la aplicación, vamos a probar la aplicación ejecutando el comando wrangle-dev. La aplicación se está ejecutando. Y está lista. Cambiaré a Postman y aumentaré el tamaño de fuente. Y esto ya lo pegué en el comando para obtener todas las citas. Esto funciona. La primera vez que haces una solicitud, es lenta, pero con el tiempo el tiempo de respuesta se reduce. Así que copiemos un ID y aquí en GetById, reemplacemos esto con nuestro nuevo ID y solicitémoslo. Y sí, sí, funciona. Y creemos una nueva cita, que dije que el borde rima con el borde porque creo que es una cita genial. Y boom, eso funciona, tenemos nuestra respuesta. Y felicitaciones, finalmente hemos migrado la aplicación. Ahora, el último paso es desplegar nuestra aplicación en Cloudflare workers ejecutando el comando Wrangler publish.

Como mencioné antes, puedes notar aquí que el proyecto solo tiene 97 kilobytes de tamaño y se realiza relativamente rápido. Así que voy a copiar este comando, esta URL. Volver a Cloudflare workers, volver a Postman y luego reemplazar esta URL con la que está en producción. ¡Y boom, la aplicación funciona! Lo hemos creado con éxito.

Ahora, volvamos a las diapositivas. Y si quieres construir la misma aplicación o refactorizar la aplicación, está disponible en GitHub. Puedes ajustarla. Y si también quieres jugar con la aplicación, la demo en vivo está disponible en Cloudflare workers y desplegada. Y como puedes ver, toda la experiencia de construcción y migración rápida se sintió relativamente rápida. En unos 10 minutos, pudimos completar con éxito todo el proceso de migración.

Ahora, con algunas reflexiones finales, el Edge aún está en sus etapas iniciales, y este flujo de trabajo proporciona una de las configuraciones más fáciles o las configuraciones más simples para comenzar. Sería útil si tu data proxy, dado que se implementa en una región específica, está más cerca de tu base de datos, y también tu aplicación se implementa más cerca de tus usuarios. El Edge es un nuevo paradigma que te hace razonar de manera diferente sobre los datos porque los datos están distribuidos. Y cuando se trata de bases de datos relacionales, distribuir estos datos es un problema de ciencias de la computación porque mantener la consistencia en todo el mundo, si se implementa en múltiples regiones, es un desafío. Entonces, la ventaja de usar Prisma es que el proxy de datos se implementa más cerca de tu base de datos centralizada. Por lo tanto, puedes usar tus flujos de trabajo de desarrollo normales para construir tu aplicación. Y esta charla, como resumen final, cubrió los desafíos y las partes buenas, los desafíos que existen al trabajar con CloudFlare workers, o plataformas serverless. También cubrimos las ventajas que tienen los CloudFlare workers sobre otras plataformas. También discutimos qué es Prisma y qué es el proxy de datos de Prisma y el problema que resuelve. Y finalmente, agregamos acceso a la base de datos a una aplicación y luego la desplegamos en CloudFlare workers. Gracias por escuchar. Espero que hayas encontrado útil la charla y no dudes en contactarme si tienes alguna pregunta. Este es un momento emocionante para trabajar en el edge.

Entonces Alex pregunta, ¿qué database estás usando con tus aplicaciones serverless? Y vemos que el 44% respondió PostgresQL. Ni siquiera sé si así se pronuncia, nunca lo dije en voz alta. ¿Lo digo correctamente, Alex? No estoy seguro si es PostgreSQL, Postgres, depende de cómo prefieras decirlo. Sí, pero probablemente la mayoría diga Postgres, sí. Oh, solo Postgres, entendido. Sí. ¿Qué opinas de este resultado? ¿Es lo que esperabas? Bueno, está cambiando, no estoy completamente seguro. Dado que también la habilidad de planificación es nueva, muchas personas podrían estar migrando a ella, por lo que es más una base de datos MySQL. Pero sí, está cerca de lo que esperaba, sí. Sí, sí, genial.

De acuerdo, pasemos a las preguntas del público. Permítanme ingresar al servidor de Discord. CCCrish está preguntando, según entendí, ¿el proxy de Prisma está cerca del edge, verdad? Pero, ¿qué pasa con la base de datos real? No está exactamente cerca del edge, actualmente el Proxy de Datos se implementa en una región específica y es preferible implementarlo lo más cerca posible de su base de datos para que no esté completamente listo para el edge, pero el caso de uso perfecto sería si sus usuarios están, por ejemplo, en una ciudad específica. Pero con suerte, a medida que el edge madure, podremos mejorar el Proxy de Datos, así como el acceso a la base de datos en el edge, sí.

Entonces, una pequeña pregunta de seguimiento para mí. Noté que dijiste, cuando el edge mejore, y dijiste ciudades, ¿sabes si realmente hay países que tienen múltiples ubicaciones de edge? E incluso, puedo imaginar un país como Alemania, estás en Alemania, que tendrías un surfer del edge de la misma compañía en, digamos, Hamburgo, y otro en Berlín, y otro en Frankfurt, algo así. ¿También es posible eso? Sí, diría que sí. Creo que compañías como Cloudflare tienen sus centros de datos en todo el mundo, y estoy seguro de que probablemente haya múltiples centros de datos en Alemania, por ejemplo. Así que sí, es posible. Eso es genial. Sí, las cosas se están acelerando. Bien, gracias.

La siguiente pregunta es de Hale to the Wood. ¿Cómo sugieres migrar una aplicación a gran escala para usar algo como Prisma Proxy? Por ejemplo, una que actualmente usa funciones serverless, hablando directamente con DynamoDB. Prisma actualmente no admite DynamoDB, por lo que esto sería un desafío mayor. No estoy seguro de tener mejores prácticas, pero actualmente el Prisma Data Proxy también está en acceso temprano, por lo que no te recomendamos que lo uses en producción. Sin embargo, aún puedes usarlo para experimentar y proporcionar comentarios para que también podamos prepararlo para que esté disponible para todos. Sí. De acuerdo. Sí.

Luego, otra pregunta. ¿Cuál es la diferencia entre serverless, CDN y Edge? Agregaré algo a eso. Buena pregunta. Estos son conceptos similares pero aún diferentes. El serverless es como una arquitectura de implementación donde realmente no tienes que preocuparte por tu infraestructura en absoluto, o simplemente administrar cualquier servidor que esté involucrado cuando implementas aplicaciones. Ahora, las CDNs o redes de entrega de contenido, son una red de centros de datos que se implementan en todo el mundo, por ejemplo, Netlify y Cloudflare, donde puedes ejecutar tu aplicación lo más cerca posible de tu usuario, y el Edge lleva esto un paso más allá y se implementa. Ahora, puedes ejecutar lógica de computación, no tan cerca como sea posible de tus usuarios. Espero que esa sea una explicación lo suficientemente buena para nuestros espectadores. Sí, para resumir, una CDN es lo mismo que un servidor Edge, pero con menos ubicaciones físicas. Es casi lo mismo en el sentido de que las CDNs se utilizan principalmente para servir activos o implementar aplicaciones.

Ya lo estamos utilizando con la aplicación cuando la implementas en Netlify y tienen los centros de datos en todo el mundo. Principalmente se ha utilizado para servir, por ejemplo, activos estáticos. Puede que esté equivocado, siéntete libre de corregirme.

Sí. No, eso también es lo que entiendo. Pero siempre hay personas más inteligentes. Si quieres corregirnos, hazlo en el servidor de Discord.

Por ahora, no tenemos preguntas. Si tienes alguna pregunta, asegúrate de escribirla y para darte tiempo, le preguntaré a Alex sobre el Waitre. Alex, estábamos discutiendo. ¿Puedes darme tu mejor impresión del crecimiento de Henry Cavill? Mi garganta está un poco dolorida en este momento, así que solo puedo decir... Creo que eso es bastante bueno. Espero que sí. Suena adecuadamente molesto al nivel de Witcher. Por supuesto. Sí. Sí.

De acuerdo. Entonces, no hay preguntas en este momento. Veo que nadie está escribiendo en este momento, así que vamos a acortar un poco hasta el descanso. Los dejaré ir. Si quieres hablar con Alex, puedes hacerlo en el chat espacial. Alex se unirá allí ahora. Entonces, si quieres continuar la discusión sobre Prisma o el acceso a la base de datos en el Edge con Cloud Fireworkers y Prisma, puedes hacerlo en el chat espacial.

Entonces, Alex, muchas gracias por estar con nosotros aquí hoy y disfruta el resto de tu día. Gracias por tenerme también. Adiós. Sí. Adiós.