En un mundo dirigido por datos, nosotros como desarrolladores hemos recurrido a esquemas para ayudar a describir y organizar esos datos. Pero ¿qué sucede cuando tienes un montón de esquemas para hacer un seguimiento? En esta charla aprenderás el papel de todos los diferentes esquemas en una API de GraphQL.
Video Summary and Transcription
¡Bienvenido a la charla! Como desarrolladores, gestionamos y comprendemos los datos con los que el mundo funciona. Cada esquema individual en tu infraestructura define tus datos en el contexto de su propio dominio. El esquema de Prisma se utiliza para generar migraciones y crear una asignación entre la base de datos y la API, permitiendo interacciones seguras en cuanto a tipos. El esquema de GraphQL permite a los clientes consultar de forma segura la base de datos a través de la API. Al utilizar Prisma y GraphQL Code Generator, puedes lograr un entorno de extremo a extremo seguro en cuanto a tipos.
Available in English
1. Introducción a la Gestión y Modelado de Datos
Short description:
¡Bienvenidos a la charla! Como desarrolladores, gestionamos y entendemos los datos en los que se basa el mundo. El modelado de datos puede ser desafiante, especialmente cuando se trata de datos de diversas fuentes. Los esquemas proporcionan una forma de representar modelos de datos, pero la proliferación de esquemas ha planteado la pregunta de la fuente de verdad.
Bienvenidos a todos. Muchas gracias por unirse a mí en esta charla. Estoy muy emocionado de darla en un formato de charla relámpago. Anteriormente, he dado la misma charla en un formato más extenso y la he condensado en las partes necesarias. Así que estoy deseando ver cómo va a ir esto. Si tienen alguna pregunta sobre la charla después de que la haya dado, no duden en enviarme un mensaje en Twitter y estaré encantado de responder cualquier pregunta que puedan tener. Pero antes de adentrarnos en el meollo de esta charla, hablemos del concepto más amplio de que el mundo mismo se basa en data, ya sea tu teléfono celular, ya sea que estés usando Facebook, o tal vez tu refrigerador o cualquier cosa que esté conectada a internet, todo funciona con data y como desarrolladores, en realidad es nuestro trabajo gestionarlo. Así que es una gran responsabilidad que recae sobre nuestros hombros, pero eso es a lo que nos comprometimos cuando nos convertimos en desarrolladores, gestionar estos data, hacer algo con ellos y proporcionarlos en un formato que otros programas puedan utilizar. Así que la conclusión de todo esto es que para gestionar un conjunto de data, debes tener algún tipo de conocimiento sobre su estructura y su propósito. Debes saber por qué estás tratando con tus data y por qué estás haciendo lo que estás haciendo en el código de tu aplicación con tus data. Así que para revisar esta declaración original, no solo es nuestro trabajo gestionar estos data en los que se basa el mundo, sino que también es nuestro trabajo entenderlos al menos en cierta medida. Y esto es difícil porque en general,data es difícil de modelar. Como personas técnicas, tenemos muchas cosas en marcha. Estamos haciendo muchas cosas técnicas. Estamos desarrollando aplicaciones. Tenemos mucho conocimiento que mantener en nuestras mentes. No hay mucho espacio para entender todo el dominio de data de cualquier industria en la que estemos trabajando en ese momento. Así que hay un par de razones más por las que tu data es difícil de modelar, a medida que tu data fluye a través de diferentes áreas de tu aplicación, debes saber cómo interactuar con este data. Por lo tanto, debe ser modelado de una manera que funcione con diferentes partes de tu aplicación. Tu modelo de data puede cambiar a medida que tu aplicación evoluciona. A medida que surgen nuevos requisitos en tu industria, es posible que debas evolucionar tu modelo un poco y hacerlo de una manera segura para tu aplicación puede ser difícil a veces. Otro motivo, y este es importante, es que tu data puede no haber sido modelada por ti. Y también revisaría esto para decir que tu data probablemente no fue modelada por ti. Probablemente estés consumiendo data de otra persona y lo estés utilizando en tu propia aplicación.
Por todas estas razones, nosotros como desarrolladores ideamos esta idea de esquemas, que es una forma de representar clara y concisamente tu modelo de data. Pero aún hay un problema, incluso con los esquemas. Los esquemas están en todas partes, por lo que hemos resuelto el problema de poder modelar nuestros data de una manera que tenga sentido. Pero ahora que hemos encontrado una buena solución, la estamos utilizando en todas partes y el propósito original del esquema se ha perdido. Entonces, lo que se supone que debe ser el esquema es una fuente de verdad de cómo se ve tu data. Pero a medida que comienzas a agregar diferentes esquemas en todas partes, surge la pregunta, ¿ahora cuál es la fuente de verdad? Esto provoca el problema de que ahora tienes múltiples fuentes percibidas de verdad, y cada esquema puede describir tu data de manera un poco diferente, lo que probablemente plantea la pregunta, ¿cuál es la fuente de verdad? Y además, cada esquema tiene un diferente
2. Gestión de Datos y Definición de Esquemas
Short description:
Cada esquema individual en tu infraestructura define tus datos en el contexto de su propio dominio. Analizaremos el esquema de la base de datos, que está escrito en un lenguaje de descripción de datos. Prisma tiene su propio lenguaje, el lenguaje de esquema de Prisma, que permite un modelado más fácil del esquema de la base de datos. El esquema de GraphQL es diferente al esquema de la base de datos, ya que define lo que expone la API, no los propios datos.
rol. Y si los data, si los esquemas se ven similares, es difícil determinar cuál es el rol de cada esquema individual. Entonces, en resumen, cada esquema individual en tu infraestructura define tus data en el contexto de su propio dominio. Ya sea tu base de datos, tu API o cualquier otra cosa, el esquema describe los data para esa parte individual de tu aplicación. Vamos a analizar una pila que tiene una base de datos, una API de GraphQL y también Prisma. De esta manera, podemos ver los esquemas individuales y cómo se relacionan. Para empezar, vamos a ver el esquema de la base de datos, que se muestra a la derecha es el código que necesitarías escribir para crear un esquema básico de la base de datos. Esto está escrito en DDL o un lenguaje de descripción de datos. Y típicamente es un lenguaje específico de la base de datos. Es un poco complicado. Estos lenguajes tienden a ser un poco más difíciles de aprender que algo como, um, algo como JavaScript o algo más fácil de ver a simple vista. Y por esta razón, en Prisma creamos nuestro propio lenguaje llamado lenguaje de esquema de Prisma. Y esto te permite modelar tu esquema de base de datos dentro de un archivo de esquema de Prisma. La única diferencia es que está escrito en este lenguaje que se parece más a GraphQL. Es un poco más fácil de leer. Esto es importante porque ahora, cuando nuevos desarrolladores ingresen a tu aplicación, o tal vez alguien no técnico, pueden ver este modelo y entender lo que está sucediendo. Esto también es importante porque es lo suficientemente simple como para que podamos usarlo dentro de Prisma para generar un cliente de Prisma seguro en cuanto a tipos que interactúa con tu base de datos y garantiza que los data a los que accedes estén realmente disponibles. Y finalmente tenemos el esquema de GraphQL aquí. Esto se parece al esquema de Prisma. Sin embargo, hay una gran diferencia. Aquí es donde mucha gente se confunde con los esquemas. El esquema de GraphQL tiende a parecerse mucho al esquema de tu base de datos porque expone los data de tu base de datos. Pero el problema aquí es que probablemente no debería verse exactamente como el esquema de tu base de datos. Esto no está definiendo tus data aquí. Esto está definiendo lo que expone tu API. Por ejemplo, para ampliar esto, es posible que estés exponiendo data de tu API de GraphQL que ni siquiera está en tu base de datos. O es posible que no estés exponiendo ciertos campos de tu base de datos por razones de seguridad. Y debido a estas cosas, tu esquema de GraphQL es algo completamente separado de tu esquema de base de datos. Puede parecer un poco como duplicación de código mientras los estás escribiendo. Pero si entiendes esta diferencia entre los dos esquemas diferentes aquí, comienza a tener un poco más de sentido. Así que, para resumir, tenemos nuestro esquema de base de datos
3. Mapeo de Esquemas de Prisma y GraphQL
Short description:
El esquema de Prisma se utiliza para generar migraciones y crear un mapeo entre la base de datos y la API, permitiendo interacciones seguras en cuanto a tipos. El esquema de GraphQL permite a los clientes consultar de forma segura la base de datos a través de la API. Al completar los vacíos con herramientas como Prisma y GraphQL Code Generator, se pueden generar tipos para el frontend basados en el esquema de GraphQL. Cuando se utilizan correctamente todos los esquemas y herramientas, se logra un entorno seguro en cuanto a tipos de extremo a extremo. Gracias por acompañarme hoy para discutir las diferencias entre los esquemas. Si tienes alguna pregunta adicional, no dudes en contactarme en Twitter.
El esquema de Prisma es el esquema que se ejecuta en tu servidor de base de datos y define la estructura de tus datos. Tienes el esquema de Prisma que se encuentra en tu API y en el código de tu API. Y esto es lo que se utiliza para generar las migraciones para actualizar el esquema de tu base de datos. Y también es lo que se utiliza para crear ese mapeo y completar el vacío entre la base de datos y la API, de modo que puedas tener interacciones seguras en cuanto a tipos entre ambas. Y finalmente, tienes el esquema de GraphQL que es lo que el cliente utiliza para consultar de forma segura tu base de datos a través de tu API. Pero hay otro vacío allí. Así que, aquí en esta diapositiva tengo los vacíos, y si los completamos, lo que obtenemos es Prisma en medio de la base de datos y la API, como mencioné, y también obtienes algo como GraphQL Code Generator, o tal vez otra herramienta similar que hace algo parecido. Y lo que esto hace es generar tipos para tu cliente de frontend basados en tu esquema de GraphQL. Así que, cuando tienes todas estas piezas en su lugar, todos estos esquemas utilizados correctamente, con estas herramientas agradables en medio de ellos, obtienes una situación y un entorno agradable y seguro en cuanto a tipos, donde tus tipos, incluso desde tu cliente, se basan en tus tipos de base de datos. Así que, muchas gracias por acompañarme hoy para hablar sobre las diferencias entre todos los diferentes esquemas con los que podrías trabajar en tu aplicación. Espero que haya aclarado algunas de esas pequeñas cosas sobre los diferentes esquemas que a menudo confunden a las personas. Si aún tienes alguna pregunta, no dudes en enviarme un mensaje en Twitter al respecto, estaré encantado de responder. Así que, gracias nuevamente y espero que tengas un buen resto de tu conferencia.
