1. Introducción a la Gestión y Modelado de Datos
¡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
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
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.
GraphQL Galaxy 2021
Comments