Acceso a la Base de Datos en el Edge con Cloudflare Workers & Prisma

Hola, amigos. Hoy hablaré sobre el acceso a bases de datos en el edge con Cloud Flarewalkers. Mi nombre es Alex, y soy un defensor de desarrolladores en Prisma. No dudes en contactarme después de la charla si tienes alguna pregunta, o simplemente cualquier pregunta o para conectar.

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

Entonces, ¿qué es el edge? Parece ser una palabra de moda que se usa mucho, pero ¿qué significa? El edge es una forma de computación serverless que está distribuida. Y en el contexto de los trabajadores de CloudFlare, se despliega en la red de datos de CloudFlare centros.

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

Así que los trabajadores de CloudFlare también ofrecen un alto rendimiento. Esto se suma a los dos primeros puntos. Porque el entorno es significativamente más ligero, lo que lleva a un tiempo de inicio más corto, o incluso posiblemente ninguno. Y también experimentarías una menor latencia cada vez que invoques tu función porque se invocaría desde el centro de datos más cercano a ti. Ahora sé que todo esto suena encantador, pero los trabajadores de CloudFlare todavía sufren los mismos problemas que las funciones serverless tradicionales en el contexto de las bases de datos. Así que conectarse a bases de datos sigue siendo un desafío desde los trabajadores de CloudFlare. Esto se debe a que el motor V8 solo admite el envío de conexiones basadas en HTTP.

Esto se convierte en un problema. Las diferentes bases de datos presentan diferentes implementaciones de las interfaces de cómo puedes conectarte a ellas, lo cual es todo caótico y está en marcha. Las conexiones a bases de datos también son con estado, mientras que los entornos serverless son sin estado, lo que significa que puedes agotar fácilmente las conexiones a bases de datos porque cada trabajador crea un nuevo grupo de conexiones. Y cuando te quedas sin conexiones, las solicitudes en tu aplicación comenzarían 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 optar por soluciones específicas de CloudFlare, como el almacén de valores clave de los trabajadores y los objetos duraderos. La segunda opción, si tienes una base de datos existente, podrías 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 modificarlos para usar HTTP con Deno, creo. Y finalmente, el núcleo 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.

Así que Prisma es un ORM de próxima generación con seguridad de tipos para NodeJS que funciona con JavaScript y TypeScript. Soporta 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 beneficios principales de Prisma son que aumenta la productividad al permitir a los desarrolladores consultar datos de maneras naturales y familiares, y también proporcionando un modelo de datos legible para humanos. Prisma también aumenta la confianza del desarrollador con la seguridad de tipos, la autocompletación, y la API robusta para interactuar con tu base de datos. Así que incluso si no usas TypeScript en tu proyecto, la mayoría de los editores proporcionarán autocompletación para tus consultas de base de datos cuando estés usando Prisma.

Y el conjunto de herramientas de Prisma consta de tres herramientas. Prisma Client. Son los clientes autogenerados y con seguridad de tipos. Prisma Migrate. Es la herramienta de modelado de datos declarativo y migración de datos. Genera migraciones de esquemas de bases 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 función serverless, tu aplicación o función serverless y tu base de datos. Te ayuda a gestionar los grupos de conexiones asegurando que no agotes tus límites de conexión que llevarían a fallos en las solicitudes. Así que cuando consultas tu base de datos, el cliente de Prisma se conectaría a tu base de datos a través del proxy de datos que usaría HTTP.

Ahora, esto es emocionante porque te permite llevar todas las buenas partes de tu confiable base de datos relacional y las herramientas de desarrollo de Prisma al 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, mientras 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 demostración. Lo que haremos es convertir la aplicación que está usando un archivo JSON para recuperar y crear citas o obtener citas por ids y moveremos esa aplicación, migraremos los datos a una base de datos y convertiremos sus rutas existentes para comenzar a usar Prisma para consultar los datos.

Ahora vamos a la demostración. Ya he configurado la plantilla base para la línea base del proyecto. Tiene tres rutas específicas en el index to TS, que es el router.getQuotes aquí. Podemos obtener citas por ID y también hacemos un post que realmente no crea una nueva cita, pero solo devuelve lo que enviaste. El proyecto también está usando Webpack. Tiene una configuración mínima de Webpack para que esto funcione. Procederé 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 configurarlo añadiendo Prisma. Procederé a instalar el CLI de Prisma como una dependencia de desarrollo y luego instalar el cliente de Prisma como una dependencia normal. Esperaré a que eso cargue por un momento. Ahora que hemos instalado la dependencia del cliente de Prisma, procederé a inicializar nuestro proyecto para comenzar a usar Prisma ejecutando el comando npx prisma init. Así que 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 usará para definir nuestros modelos de datos, que se aplicarán a nuestra base de datos. El comando también crea un archivo .env, donde almacenaremos nuestras variables de entorno para el proyecto.

Así que por ahora, procederé a añadir, pegar mi cadena de conexión a mi base de datos. Ahora que eso está hecho, iré al archivo schema.prisma. Y comenzar a usar el proxy de datos en tu proyecto. Puedes habilitarlo añadiendo la bandera de función de vista previa en el bloque del generador en tu archivo schema.prisma. Proxy de datos. Proxy de datos. Eso está hecho. Cierra esto. Expande esto.

Ahora vamos a modelar nuestros datos. Nuestra cita, como podemos ver en el 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 de stata que compartiré antes de que termine esta charla.

Así que crearemos un nuevo modelo, quote, que tendrá un ID, que es una cadena, y es un valor de ID, y por defecto queremos que esto se genere. 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 deseas puedes añadir un campo de creado en tu tabla, que será una marca de tiempo de cuando el registro fue añadido a la base de datos. Y queremos que esto se genere automáticamente usando la función now.

Así que ahora que hemos modelado, apliquemos este esquema, o el esquema que acabamos de crear a nuestra base de datos. Ejecutaré un comando npx Prisma DB push para aplicar lo que tenemos a nuestra base de datos. Sí, dado que tenía datos existentes, procederé a eliminarlos.

El siguiente paso es migrar o poblar la base de datos con los códigos que tenemos en el archivo data.json. Así que dentro del schema.prisma, dentro de la carpeta Prisma, añadiré un archivo seed.ts. Y aquí, pegaré algo de código, que explicaré en un momento. Así que lo que hace esto es importar el cliente de Prisma desde nuestros node modules, y también estamos importando las citas del archivo JSON. Y dado que es un array de aproximadamente 500 citas, recorreremos cada una de las citas, e insertaremos un registro en nuestra base de datos dentro de este bloque.

El siguiente paso ahora es ejecutar este archivo contra, para que realmente podamos ver los datos. Así que usaré ts node para ejecutar nuestro archivo TypeScript. Así que npx, ts node, prisma, c.ts.

Dale un momento. Veamos. Y está hecho. Hasta ahora hemos inicializado nuestro proyecto con Prisma y hemos migrado nuestros datos existentes del archivo JSON a la base de datos. Así que el siguiente paso es configurar nuestros proyectos en la Prisma Data Platform para que podamos obtener una clave API o una cadena de conexión que nos permita comunicarnos con nuestra base de datos usando HTTP.

Así que el primer paso es ir a GitHub y crear un nuevo repositorio. Lo llamaré Prisma CFW, forma abreviada de Cloud Flow Workers. Lo haré privado, créalo. Así que localmente, primero comprometeré mis archivos a GitHub. Pero primero comenzaré inicializándolo, obteniéndolo, y haré git add, y luego comprometeremos todos nuestros archivos. Bien, ahora que eso está hecho, seguiremos adelante e importaremos nuestro proyecto en la Prisma data platform, pero primero verifiquemos si los cambios fueron sincronizados.

Oh, me perdí un paso donde necesitábamos añadir un origen primero para, así que antes de que realmente podamos empujarlo a GitHub. Así que pegaré el comando de GitHub. Los cambios han sido empujados a GitHub, así que si actualizo esto, deberíamos poder ver nuestros nuevos cambios, los cambios que acabamos de hacer. Genial, eso es un buen progreso. Así que el siguiente paso es importar el proyecto en la Prisma data platform. Así que seguiré adelante y crearé, haré clic en Nuevo Proyecto. Le daré un nombre, Prisma CFW. Importaremos el repositorio, Prisma CFW. Todo está bien. A continuación, continuaré, usaré mi propia base de datos y también pegaré mi cadena de conexión. Así que 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. Así que se te dan dos cadenas de conexión una vez que el proyecto está configurado. Así que la primera será la clave 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é un 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.

Dale que sí. Genial, ahora eso está hecho. Es hora de refactorizar nuestra aplicación. Lo siento, no ahora. Así que de vuelta en 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 refactoricemos nuestra primera ruta. Así que haremos una consulta para obtener todas las citas de nuestra base de datos. Así que const quotes es igual a await Prisma.quote.findMany. Eso está hecho. Refactoricemos la obtención de una cita por ID. Así que const result es igual a await Prisma.quote.findUnique. Y luego necesitamos proporcionar una cláusula where que requiera el ID, que es del valor de params aquí. Por último, necesitaremos poder crear un nuevo registro. Así que aquí esperaremos Prisma.quote.create. Y nosotros, necesitamos 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 Prisma client 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 está en ejecución. Y eso está listo. Cambiaré a Postman y aumentaré mi fuente. Y esto ya lo pegué en el comando para obtener todas las citas. Esto funciona. La última vez que haces una solicitud, es lenta, pero con el tiempo el tiempo de solicitud se reduce. Así que copiemos un ID y aquí en el GetById, reemplacemos esto con nuestro nuevo ID y solicitemoslo. Y sí, sí, funciona. Y creemos una nueva cita, que dije que el edge rima con el ledge porque creo que es una cita genial. Y boom, eso funciona, obtuvimos 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 y relativamente toma poco tiempo. Así que, voy a copiar este comando, esta URL. Regresa a Cloudflare workers, regresa a Postman y luego reemplaza 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 te gustaría construir la misma aplicación o refactorizar la aplicación, está disponible en GitHub. Puedes ajustarla. Y si también te gustaría jugar con la aplicación, la demo en vivo está disponible en Cloudflare workers y desplegada. Y como puedes ver, toda la experiencia de construir y migrar rápidamente se sintió relativamente rápida. En unos 10 minutos, pudimos completar con éxito todo el proceso de migración.

Ahora, con algunos pensamientos finales, el Edge todavía está en sus etapas relativamente, todavía está relativamente en sus etapas tempranas, y este flujo de trabajo proporciona una de las configuraciones más fáciles o las más simples para comenzar. Sería útil si tu proxy de datos, dado que está desplegado en una región específica, está más cerca de tu base de datos, y también tu aplicación desplegada 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 una especie de problema de ciencia de la computación porque mantener la consistencia en todo el mundo, si lo tienes desplegado en múltiples regiones es un desafío. Así que la ventaja de usar Prisma es que el proxy de datos se despliega más cerca de tu base de datos centralizada. Así que puedes usar tus flujos de trabajo de desarrollo normales para construir tu aplicación. Y esta charla, como un resumen final, cubre los desafíos y las buenas partes de, los desafíos que existen al trabajar con CloudFlare workers, o plataformas serverless. También cubrimos las ventajas que CloudFlare workers tiene 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 la charla útil y siéntete libre de contactarme si tienes alguna pregunta. Este es un momento emocionante para estar trabajando en el edge.

Entonces Alex pregunta, ¿qué base de datos 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 más Postgres, sí. Oh, solo Postgres, está bien. Sí. ¿Qué piensas sobre este resultado? ¿Es esto lo que esperabas? Bueno, está cambiando, no estoy completamente seguro. Dado que también la habilidad de planificación es nueva, mucha gente podría estar cambiándose a ella, así que es más una base de datos MySQL. Pero sí, es cercano a lo que esperaba, sí. Sí, sí, bien.

Bien, así que vamos a las preguntas de la audiencia. Déjame entrar al servidor de Discord. CCCrish está preguntando, por lo que entendí, el Prisma proxy está cerca del edge, ¿verdad? Pero, ¿qué pasa con la base de datos real? No está exactamente cerca del edge, ahora mismo el Data Proxy se despliega en una región específica, y preferirías desplegarlo lo más cerca posible de tu base de datos para que no esté completamente listo para el edge, pero el caso de uso perfecto sería si tus usuarios están, por ejemplo, en una ciudad específica. Pero con suerte, a medida que el edge madura, podemos mejorar el Data Proxy así como el acceso a la base de datos en el edge, sí.

Así que, una pequeña pregunta de seguimiento de mi parte. Así que noté que dijiste, cuando el edge mejoró, y dijiste ciudades, ¿sabes si hay realmente, como, países que tienen múltiples ubicaciones edge? E incluso, como, puedo imaginar un país como Alemania, estás en Alemania, que tendrías un servidor edge de la misma compañía en, digamos, Hamburgo, y uno en Berlín, y uno en Frankfurt, algo así. ¿Eso también es una cosa? ¿O es como si hubiera un servidor alemán? Sí, diría que sí. Creo que compañías como Cloudflare tienen sus centros de datos por todo el mundo, y estoy seguro de que probablemente hay múltiples centros de datos en Alemania, por ejemplo. Así que, sí, es posible. Eso es súper genial. Sí, las cosas están acelerándose. Genial, gracias.

La siguiente pregunta es de Hale to the Wood. ¿Cómo sugerirías proceder con la migración de una aplicación a mayor escala hacia el uso de algo como Prisma Proxy? Por ejemplo, una que actualmente está usando funciones serverless, hablando directamente con DynamoDB. Prisma actualmente no soporta DynamoDB, así que esto sería un desafío mayor. No estoy seguro de tener las mejores prácticas, pero ahora mismo el Prisma Dataproxy también está en acceso temprano, así que no recomendaríamos usarlo en producción. Sin embargo, aún puedes usarlo para experimentar, proporcionar retroalimentación para que también podamos prepararlo para estar generalmente disponible para todos. Sí. Bien. Sí.

Entonces, otra pregunta. ¿Cuál es la diferencia entre serverless, CDN y el Edge? Añadiré a eso. Buena pregunta. Así que estos son conceptos similares pero aún diferentes. El serverless es como una arquitectura de despliegue donde realmente no tienes que preocuparte por tu infraestructura en absoluto, o simplemente gestionar cualquier servidor que esté involucrado cuando despliegas aplicaciones. Ahora, los CDNs o redes de entrega de contenido, es una red de centros de datos que están desplegados por 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 despliega. Ahora, puedes ejecutar lógica de computación, no tan cerca como sea posible de tus usuarios. Espero que sea una explicación lo suficientemente buena para nuestros espectadores. Sí, así que para resumir, CDN es lo mismo que un servidor Edge, pero con menos ubicaciones físicas. Es casi lo mismo en que los CDNs se usan principalmente para servir activos o desplegar aplicaciones.

Ya lo estamos usando con la aplicación cuando la despliegas en Netlify y tienen los centros de datos por todas partes. Se ha utilizado principalmente para servir, por ejemplo, activos estáticos. Podría estar equivocado y siéntete libre de corregirme en eso.

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 escribirlas y para darte algo de 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 irritada en este momento, así que solo puedo decir… Creo que eso es bastante bueno. Espero que sí. Suenas adecuadamente molesto al nivel de Witcher. Por supuesto. Sí. Sí.

Bien. Así que, no hay preguntas entrando. Veo que nadie está escribiendo en este momento, así que vamos a cortar un poco más corto para el descanso. Te liberaré. Si quieres hablar con Alex, puedes hacerlo en el chat espacial. Alex va a saltar allí ahora. Así que, si deseas 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.

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