Modelado de Bases de Datos Relacionales para GraphQL

Rate this content
Bookmark

En este masterclass profundizaremos en el modelado de datos. Comenzaremos con una discusión sobre varios tipos de bases de datos y cómo se relacionan con GraphQL. Una vez establecidos los fundamentos, nos enfocaremos en tipos específicos de bases de datos y cómo construir modelos de datos que funcionen mejor para GraphQL en diferentes escenarios.


Tabla de contenidos

Parte 1 - Hora 1

a. Modelado de Datos de Bases de Datos Relacionales

b. Comparación de Bases de Datos Relacionales y NoSQL

c. GraphQL teniendo en cuenta la base de datos

Parte 2 - Hora 2

a. Diseño de Modelos de Datos Relacionales

b. Relaciones, Construcción de Tablas Multijoin

c. GraphQL y Complejidades de Consultas en el Modelado de Datos Relacionales


Prerrequisitos

a. Herramienta de modelado de datos. El instructor utilizará dbdiagram

b. Postgres, aunque no es necesario instalarlo localmente, ya que utilizaré una imagen de Postgres en Docker de Docker Hub para todos los ejemplos

c. Hasura


106 min
15 Jul, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Este masterclass cubre el modelado relacional con GraphQL, incluyendo la construcción de un esquema de base de datos, el diseño de relaciones y el uso de herramientas como dbDiagram y Hasura. Explora los conceptos de bases de datos relacionales, tablas y relaciones, así como el uso de UUID y auto incrementos. El masterclass también abarca el seguimiento de relaciones de clave externa, la configuración de migraciones y la optimización de consultas para mejorar el rendimiento. Además, se discuten las capacidades de Postgres, consejos para el diseño de bases de datos y el uso de esquemas. En general, el masterclass proporciona información valiosa sobre el modelado relacional y el desarrollo de bases de datos con GraphQL.

Available in English

1. Introducción a la Modelización Relacional con GraphQL

Short description:

Bienvenidos al masterclass de hoy. Soy Adrian. Esto es modelización relacional con GraphQL en mente. Pasaremos por la primera parte, construiremos un esquema de base de datos, diseñaremos algunas cosas, gracias Daria, y luego haremos un breve descanso, básicamente un descanso para ir al baño, antes de pasar a la segunda parte. Así que en la primera parte, nuevamente, modelización relacional, construiremos un esquema real. Algo así. Eso es dbDiagram, por cierto. Eso es en lo que estaremos trabajando. Y luego en la segunda parte, profundizaremos en los modelos de datos relacionales. Lo que obtenemos cuando hacemos consultas con múltiples uniones y las relaciones dentro de la base de datos, pero también lo que obtendríamos usando una herramienta como Hasura, que usaré para mostrar cómo ve las relaciones y cómo las construye para las consultas de GraphQL basadas en las relaciones y el modelado de la base de datos subyacente. Y así es como se ve la herramienta Hasura. Usaremos principalmente la sección de GraphQL, que facilita mucho la creación de consultas de GraphQL y también veremos algunas de las otras partes, como el Explorador, el Exportador de Código, cosas así. También veremos la sección de datos para interactuar directamente con la base de datos en parte del diseño y todo. Y para ejecutar parte de nuestro SQL inicial que escribiremos. Y tal vez use un poco la interfaz de línea de comandos de Hasura. Es una gran herramienta para obtener, si vas a usar Hasura y vas a construir tu flujo de trabajo de desarrollo en torno a él, definitivamente obtén también la interfaz de línea de comandos. Tiene muchas características excelentes para hacer migraciones, completar los metadatos y simplemente trabajar e interactuar de manera automatizada, o poder construir una vía automatizada para tus herramientas. Y luego tomaré el tiempo para pasar a la siguiente parte de tus herramientas.

Bienvenidos al masterclass de hoy. Soy Adrian. Esto es modelización relacional con GraphQL en mente. Así que hay algunos requisitos previos que se señalaron. Por supuesto, nadie tiene que seguir el ritmo. Sin embargo, tengo este material muy orientado a hablar sobre temas específicos y luego trabajar con todos ustedes a través del contenido.

Entonces habrá algo de codificación, habrá diseño y luego habrá que poner en marcha servicios y cosas así. Así que si quieres seguir el ritmo para aprovechar al máximo este masterclass, definitivamente puedes hacerlo. Y aquí puse que usaré Postgres Docker un poco, pero en realidad lo he configurado para que ni siquiera necesite usar eso. Lo único que necesitarás es una cuenta, que puedes registrarte incluso ahora mismo, es bastante rápido hacerlo, con DB diagram y Hasura y prospectivamente Heroku. Heroku proporcionará la base de datos Postgres para Hasura cuando llegue a esa parte del masterclass. Y habrá tiempo para registrarse rápidamente si aún no lo has hecho.

He dividido esto en dos partes. Pasaremos por la primera parte, construiremos un esquema de base de datos, diseñaremos algunas cosas, gracias Daria, y luego haremos un breve descanso, básicamente un descanso para ir al baño, antes de pasar a la segunda parte. Así que en la primera parte, nuevamente, modelización relacional, construiremos un esquema real. Algo así. Eso es dbDiagram, por cierto. Eso es en lo que estaremos trabajando. Y luego en la segunda parte, profundizaremos en los modelos de datos relacionales. Lo que obtenemos cuando hacemos consultas con múltiples uniones y las relaciones dentro de la base de datos, pero también lo que obtendríamos usando una herramienta como Hasura, que usaré para mostrar cómo ve las relaciones y cómo las construye para las consultas de GraphQL basadas en las relaciones y el modelado de la base de datos subyacente. Y así es como se ve la herramienta Hasura. Usaremos principalmente la sección de GraphQL, que facilita mucho la creación de consultas de GraphQL y también veremos algunas de las otras partes, como el Explorador, el Exportador de Código, cosas así. También veremos la sección de datos para interactuar directamente con la base de datos en parte del diseño y todo. Y para ejecutar parte de nuestro SQL inicial que escribiremos. Y tal vez use un poco la interfaz de línea de comandos de Hasura. Es una gran herramienta para obtener, si vas a usar Hasura y vas a construir tu flujo de trabajo de desarrollo en torno a él, definitivamente obtén también la interfaz de línea de comandos. Tiene muchas características excelentes para hacer migraciones, completar los metadatos y simplemente trabajar e interactuar de manera automatizada, o poder construir una vía automatizada para tus herramientas. Y luego tomaré el tiempo para pasar a la siguiente parte de tus herramientas.

2. Introducción a los Conceptos Relacionales

Short description:

Comenzaremos con los conceptos relacionales y mencionaremos brevemente las bases de datos NoSQL. El enfoque estará en las bases de datos relacionales, pero también mencionaré otros tipos. Si estás interesado en aprender más, sígueme y regístrate para futuros masterclass y eventos. Tengo experiencia con varios tipos de bases de datos.

De acuerdo, vamos a comenzar con los conceptos relacionales. Mencionaré algunas cosas sobre las bases de datos NoSQL. Principalmente, este masterclass completo estará orientado a bases de datos database relacionales. Así que nos enfocaremos en las ideas detrás de eso. Pero también mencionaré algunos de los otros porque son bastante comunes en estos días. Y hay muchos conceptos compartidos entre muchos de ellos. Y es útil conocer la diferencia entre los conceptos allí versus los conceptos en el modelo relacional. Así que mencionaré eso en algunas partes.

Y esas cosas que mencioné principalmente se centran en las bases de datos distribuidas columnares y basadas en documentos como Mongo y Apache Cassandra. Y mencionaré un poco sobre las bases de datos de grafos como Neo4j o algo así. Neo4j, Titan y las demás. No mencionaré las de series temporales. No mencionaré algunas de las otras bases de datos de nicho NoSQL en este momento. Sin embargo, si tienes curiosidad, asegúrate de seguirme y registrarte para futuros masterclass y eventos en Hasura y en mis cuentas que proporcionaré al final de esto. Así que no hay razón para preocuparse por eso ahora. Hago mucho streaming y otras cosas así en todo tipo de database. Así que he trabajado mucho en eso, me encantaría compartirlo.

3. Modelado Relacional y Construcción del Modelo de Datos

Short description:

En las bases de datos relacionales, se utilizan tablas para almacenar datos y se conectan a través de relaciones. Estas relaciones pueden ser de uno a muchos, muchos a muchos o recursivas. La herramienta dbDiagram se utiliza para visualizar y construir estas relaciones. Permite la creación de claves primarias y externas para establecer conexiones entre tablas. Las relaciones recursivas se pueden simular en una base de datos relacional relacionando una tabla consigo misma. La construcción de un modelo de datos implica diseñar la estructura de las tablas y sus relaciones. En dbDiagram, se pueden cargar diagramas de muestra como referencia. La herramienta proporciona información sobre cómo dibujar relaciones y construir tablas. También demuestra el uso de diferentes tipos de datos y nombres de columnas.

De acuerdo, así que comenzando en el mundo relacional, vamos a cubrir la forma estándar en la que se diseñan las bases de datos relacionales. Tenemos un esquema que establece las relaciones entre las tablas. En una base de datos relacional, estas son las tablas, estos son los elementos principales dentro de la base de datos que se utilizarán para almacenar datos. Puedes pensar en una tabla casi como una hoja de cálculo o cualquier otra cosa. Almacenará todas las cosas que pondremos en ella y lo hace dividiendo las cosas en columnas.

Por ejemplo, la tabla de origen tiene un ID, una marca de tiempo, nombre, URI, detalles. Y tienen un tipo de dato, marca de tiempo, texto, etc. Luego, las tablas tienen relaciones que son de varios tipos. En una base de datos relacional, principalmente tienes una relación de uno a muchos o muchos a muchos, o tienes una relación recursiva, es decir, una tabla que se relaciona consigo misma. Si observas la tabla NoteJot, verás en el lado lejano que en realidad se está dibujando una línea de relación recursiva hacia ella. Si alguna vez trabajas con datos de gráficos, bases de datos de gráficos, notarás que los datos de gráficos están orientados hacia los bordes y lados de los datos y cómo se conectan.

Entonces, las relaciones varían y pueden tener muchos tipos diferentes de formas en las que ocurren las relaciones más allá de solo uno a muchos y muchos a muchos, cosas así. Pero en una base de datos relacional, se centra en relaciones uno a muchos, muchos a muchos o muchos a uno, dependiendo de cómo se vea la relación. Aquí, he conectado estas tablas donde el ID de origen, verás el ID de origen y las notas de origen aquí. Está conectado de vuelta al ID aquí para dibujar esa relación. Y en la herramienta que utilizaremos, dbDiagram, hay una clave primaria designada con un uno y un asterisco, que designa una clave externa, lo que haría que esta sea una relación de uno a muchos entre esa tabla. Hay otro donde señalé directamente lo que es, por lo que esta nota jot va de uno a muchos a notas de origen. Y lo que he creado en esta situación particular muestra una relación de muchos a muchos. Debido a esa tabla intermedia, puedo relacionar el origen con las notas de jot y puede haber uno o muchos orígenes para cada nota jot o uno o muchos jot de notas por origen. Y eso es lo que es una relación de muchos a muchos, donde puedes relacionarlo de ida y vuelta, pero no hay límite en cuántas cosas pueden estar relacionadas con la otra cosa. Con la relación recursiva, dibujada en la nota jot aquí, significa que una nota, que he llamado nota jot, puede estar relacionada con otra nota, lo que haría que lo que está relacionado con ella sea el padre de esa nota. Y los que están relacionados con ese padre serían los hijos de esa nota. Y en ese sentido, puedes dibujar una relación recursiva con esos datos. La forma más fácil que siempre he encontrado, que se muestra en las computadoras todo el tiempo, de una relación recursiva, es pensar en un árbol de carpetas dentro de la estructura de directorios de tu computadora. Esa es una relación recursiva. Puedes tener tantas carpetas como quieras, tantos archivos como quieras en las carpetas, bueno, en general, y se anidan a medida que avanzas. Esa es una relación recursiva. Y puedes simular el mismo tipo de cosa en una base de datos relacional haciendo lo mismo allí.

De acuerdo, construyendo un modelo de datos. Esto es lo que voy a construir, ¿verdad? Algo así como una base de datos mínima. Acabamos de ver estas tres tablas, origen, notas de origen y nota jot. Pero aquí hay una tabla principal llamada conexión, y luego otras tres llamadas formateador, esquema y acción. Y te mostraré en dbDiagram cómo construir una estructura como esta. Y hablaremos sobre algunas de las piezas particulares de este modelo y por qué también. Ampliaré por qué elegí ciertos tipos de datos, ciertos nombres de columnas, etc., a medida que avancemos en esto. Esto es lo que vamos a hacer. De acuerdo, abre dbDiagram si aún no lo has hecho. Cuando vayas al sitio por primera vez, terminarás aquí y necesitarás crear una cuenta. Así que hazlo si aún no lo has hecho. Si ya lo hiciste, cuando hagas clic en Ir a la aplicación, debería llevarte directamente aquí como esto. En general, viste ese esquema en modo fantasma que mostró. Una excelente manera de trabajar con dbDiagram es utilizar uno de los diagramas de referencia que te proporciona. Y si te desplazas aquí hasta este menú desplegable y simplemente haces clic en Cargar muestra, cargará la muestra para ti. Y te brinda información en el marcado en el lado izquierdo de la pantalla aquí sobre cómo dibujar todas las relaciones y construir las tablas aquí en esta herramienta. Puedes ver aquí una clave primaria con un valor de incremento automático. Están utilizando un var char aquí, una marca de tiempo aquí. Y hablaré más de eso en un momento mientras comienzo a trabajar en esto. Y muestra algunas de las referencias. Esta aquí es una relación de muchos a muchos entre, ¿qué es? El código de país a países y luego comerciantes a países.

4. Construcción de la Tabla de Origen con UUID

Short description:

Los comerciantes pueden tener muchos países, los países pueden tener muchos comerciantes. Utilizaremos un UUID como clave primaria para garantizar la unicidad. Agregar una marca de tiempo proporciona capacidades de auditoría. También incluiremos columnas para nombre, URI y detalles. Las notas de origen tendrán un ID de origen que hace referencia a otra tabla. Los UUID son más rápidos que el incremento automático para grandes volúmenes de inserción de datos.

Entonces, los comerciantes pueden tener muchos países, los países pueden tener muchos comerciantes y sus respectivos códigos de país, etc. Y también hay algunos puntos de referencia aquí. Esta es una gran herramienta y la vamos a usar para construir nuestro esquema inicial.

Entonces, hagámoslo. Voy a hacer clic en el menú desplegable y seleccionar nuevo diagrama. Y luego aquí, voy a comenzar mi primera tabla así. Y simplemente la llamaré origen, abrir y cerrar llave. Y luego veamos, vamos a usar ID UUID. Un UUID es un valor entero de 16 bits. Por lo general, se representa con guiones para que sea más legible. Cada database lo tiene. Es una forma de garantizar que tu ID sea único. Y a diferencia del incremento automático donde puedes tener conflictos porque irá uno, dos, tres, cuatro, cinco, y luego si más de una persona intenta insertar algo, puedes tener un conflicto donde de alguna manera obtienen el cinco y luego el cinco se sobrescribe, o el cinco se elimina, y luego alguien más intenta agregarlo y puede haber una colisión entre ellos porque no son números particularmente únicos. Al usar un UUID, sin embargo, si usas un generador de UUID, que cada database tiene una función o algo que te permitirá crearlo automáticamente. Y la mayoría de los códigos, ya sea que estés usando JavaScript o Python o cualquier otro, hay algo que te permitirá crear un UUID. Por lo tanto, puedes insertar sin preocuparte por los conflictos y puedes hacer referencia sin preocuparte por encontrar la necesidad de deduplicar si por alguna razón alguien desactiva la clave alrededor del UUID que lo mantiene único. Entonces, en este caso, voy a comenzar de inmediato, estableciendo este UUID como la clave primaria, P-K-A. Luego agregaré una marca de tiempo. A menudo, y esto es algo muy importante para el modelado de datos, es una buena idea tener un conjunto predeterminado de columnas que se duplican en todas las tablas y que te ofrecen capacidades de auditoría. Especialmente cuando trabajas en un entorno enterprise donde las auditorías ocurren de manera regular, siempre es genial tener ciertas cosas que la auditoría requerirá, como una marca de tiempo para representar cuándo se cambió por última vez el data y otra información pertinente que pueda ser requerida por la auditoría. Como el usuario que realizó el último cambio. Y proporciona un rastro que se puede auditar para conocer todas las cosas que han cambiado o alterado o manipulado los datos de alguna manera en toda la database. Algunas de las cosas predeterminadas que siempre agrego son la marca de tiempo y a menudo, agrego el usuario del sistema, no particularmente el usuario de la database, sino el usuario del sistema. Porque muchas veces el sistema de la database realizará un seguimiento del usuario que está cambiando los datos de todos modos. Entonces, si quieres que sea fácil de consultar en las propias tablas, debes agregar una marca de tiempo, debes agregar un usuario, tal vez el usuario del sistema o el usuario de la database dependiendo de tus requisitos. Entonces, en este caso, lo mantendré simple y solo tendré la marca de tiempo, no entraré en los usuarios y todo eso. Eso es para eso. Y nuevamente, la database tiene una función que podemos usar para que la marque con una marca de tiempo, coloca la marca de tiempo en la columna. Por lo tanto, no tenemos que ingresarla manualmente o derivarla del código o algo así. Puede ser anulado, pero la database también puede hacerlo por nosotros. Creo que respondí la pregunta sobre UUID, Pravin. Si tienes alguna otra pregunta al respecto, no dudes en preguntar y lo explicaré más. Y también veremos un ejemplo. Así que más allá de hablar de esto, verás que la database generará uno cuando ingresemos algunos datos en la database en breve. Muy bien, lo siguiente en origen, quiero agregar nombre, así que pongo texto y luego URI. Entonces, el nombre de la fuente, estoy pensando en esta tabla como algo que proporciona fuentes de donde está el data o una referencia al data, donde está el data. Piénsalo como algo donde tuviste que buscar en un diccionario o en una biblioteca o algo así, pero en este caso, ya sabes, es internet, lo buscaste en internet y quieres el URI, la ubicación real del indicador de recursos universal, y quieres un nombre para poder darle un nombre amigable que nosotros, los humanos, podamos leer y entender qué es, y finalmente, agregaré detalles, y los detalles básicamente serán algo así como notas que podríamos mantener sobre una fuente en particular que hemos recopilado por alguna razón. Como si encuentro una página increíble sobre GraphQL y React o algo así, pondría el URI allí, agregaría un nombre amigable y luego agregaría más detalles sobre qué es específicamente. Básicamente, una tabla muy glorificada de marcadores.

Luego agreguemos uno para las notas de origen así, y agregaré un ID de origen. Entonces, ese ID de origen, la razón por la que lo llamé así, es porque no es el ID de la tabla. Es el ID que hace referencia a otra tabla a la que esta tabla estará relacionada. Así que haré un UUID porque debe ser el mismo que la tabla a la que hace referencia, y luego agregaré una referencia. En NDB diagram, eso es ref dos puntos mayor que, el nombre de la tabla a la que hace referencia,.id, la columna a la que está relacionada. Así que eso es, y el texto de los detalles, y luego la marca de tiempo, también tendré una marca de tiempo para esta tabla Hubo una pregunta de Nebertec, ¿qué es más rápido, UUID o incremento automático? Si estás hablando de una gran cantidad de data que se inserta, ganarás con los UUID, y te diré por qué. Si tienes un solo sistema, solo un sistema, con solo ese sistema escribiendo inserciones en una database con incrementos automáticos, puede ser bastante rápido, y los incrementos automáticos pueden ser rápidos en todos los sentidos de la realidad. Sin embargo, a menudo, si tienes muchas inserciones, también tienes muchos clientes que intentan hacer las inserciones.

5. UUIDs vs Incrementos Automáticos

Short description:

Los incrementos automáticos pueden volverse lentos y causar conflictos en inserciones, actualizaciones y eliminaciones. Los UUIDs eliminan los conflictos pero pueden complicar el código del lado del cliente. En cuanto al rendimiento, generar UUIDs en el cliente es la opción más rápida. Para múltiples clientes que escriben datos, se recomiendan los UUIDs. La diferencia de rendimiento entre los UUIDs y las funciones de incremento automático es insignificante. Considera las inserciones por lotes para volúmenes grandes de datos.

Se volverán muy lentos con los incrementos automáticos porque se encontrarán con colisiones, y surgirán otros conflictos a medida que trabajes con estas inserciones. Si también tienes actualizaciones y eliminaciones, aún más conflictos. Los UUIDs no tendrán conflictos. Sin embargo, si estás realmente preocupado por las inserciones, no hagas que la database llame a ninguna función para crear UUIDs o hacer incrementos automáticos y crea el identificador único puramente en el lado del cliente. Haz que el cliente haga ese trabajo. Sin embargo, nuevamente, esto puede ser complicado porque estás tomando algo que va a ser una referencia específica de la database, el UUID y las relaciones de clave primaria y clave externa. Y estás poniendo la responsabilidad en el cliente, que no es la database. No sabe por qué estaría creando esto. Eliminas muchos de los conflictos y problemas a nivel de la database, pero también eliminas parte de la responsabilidad de la database. Me gusta que la database use una función para crear un UUID, pero a veces necesitas que el código del cliente o el cliente mismo, quien esté creando estos datos, realmente cree el UUID. Pero en cuanto al rendimiento, la forma más rápida es que la database no lo haga. Si tienes un solo cliente que escribe datos, el incremento automático es bastante rápido. Si tienes varios clientes que escriben los datos, debes pasar a los UUIDs independientemente del rendimiento. Lo otro que agregaría es que la diferencia entre una función de UUID y una función de incremento automático en casi todas las database relacionales es tan insignificante que no debería afectar tus inserciones. Lo otro que debes tener en cuenta son las inserciones por lotes, si realmente tienes grandes volúmenes de datos para insertar en la database. Así que eso es algo a tener en cuenta. Desafortunadamente, la respuesta no es sencilla, depende de cómo vayas a escribir esos datos en la database.

6. Creación de Tablas de Origen y Conexión

Short description:

Aquí están las tablas de origen y nodos de origen. Agregaremos una nota jot con un ID como clave primaria. También agregaremos una marca de tiempo y el ID de la nota. Esto crea una relación recursiva de vuelta a la tabla misma. Podemos agregar detalles tanto a la nota como al origen. A continuación, crearemos la conexión. La conexión vinculará los orígenes a acciones específicas, como ubicaciones FTP o API REST. Agregaremos tablas para acción, formato y esquema. Por último, relacionaremos la conexión de vuelta a las tablas de origen y nota.

Muy bien. Aquí están las tablas de origen y nodos de origen, y ahora voy a agregar la cosa de tomar notas. Vamos a agregar una nota jot así. Y nuevamente, tendremos un ID allí, UUID, y lo haremos la clave primaria, ¿de acuerdo? Y luego agregamos una marca de nuevo. Haremos que sea una marca de tiempo y agreguemos el ID de la nota. Y esto es esa oreja de elefante, esa relación recursiva de vuelta a, la tabla misma, ¿verdad? Note jot dot ID. Y lo ves aparecer en el diagrama a la derecha. Una característica realmente genial de esto es que lo dibuja mientras lo haces. Permíteme agregar detalles. Y luego volvamos a las notas de origen, y relacionaremos esto. Vamos a poner el ID de la nota, referencia UID, note jot dot ID, oops ID. Así que ahora, movamos esto para poder verlo mejor. Puedes ver que tenemos una relación de muchos a muchos y esa recursiva aquí, ¿verdad? Entonces, esa fue la primera parte del esquema que vimos cuando discutí los detalles específicos. Bueno, los detalles para la nota serían como el cuerpo de la nota en sí. Como si quisieras tener una amplia gama de notas recursivas alrededor de una fuente en particular, ¿verdad? Y en el origen, los detalles son específicos solo a la cosa correlativa que se encuentra en esa tabla, en este caso solo la URI. Y también, es solo un ejemplo. Probablemente no tendría detalles en ambos a menos que hubiera una razón muy específica para tenerlos estrechamente acoplados a cada una de esas entidades de esa manera. Pero en este caso, parecía una cosa fácil de agregar que podría ser útil a medida que se desarrolle. Como cuando alguien comienza a hacer desarrollo de aplicaciones contra esto, podrían usar prospectivamente los detalles tanto de la nota como del origen, ¿verdad? Muy bien, entonces lo siguiente, quiero crear la conexión. Y veamos, haremos ID, UID, lo haremos clave primaria. Luego vamos a tener una marca de nuevo. Otra marca de tiempo, porque, nuevamente, con las marcas de tiempo, es para cualquier actualización o cambio en los datos en absoluto, ¿verdad? Marca, y luego veamos, aquí queremos, vamos a hacer dos cosas más. Entonces, la conexión, solo para describir lo que estoy pensando con la conexión, son estas cosas aquí, estas tres tablas, vamos a cambiar su color. Cambiémoslos a este color. Puedes ver en el diagrama, los cambia aquí como esto, el color de la cabeza. Solo para que podamos diferenciarlos de lo que estoy a punto de hacer. Esto es puramente el origen y las notas sobre el origen que se recopilan. Con la conexión, voy a conectar los orígenes a acciones específicas. Entonces, la idea es, si el origen es, digamos, no solo una página web, sino una ubicación FTP, como una ubicación de transferencia de archivos, u otra ubicación de API REST o una ubicación GraphQL, podría configurar acciones, ¿verdad? Y otras cosas, como digamos, decirle qué tipo de formato es. ¿Es XML o JSON o algo así? ¿O hay un esquema para los datos con el que podría realizar una acción y extraer de esa fuente en particular? Entonces, con la conexión, agregaré una marca. Y luego habrá una acción, un formato y un esquema. Así que agreguemos las tablas para eso. Y luego volvamos y agreguemos el ID. Entonces volvamos y agreguemos los IDs a esto. Primero, veamos, ups, tabla, esquema. Y nuevamente, ID, como en todas partes. Haremos PK. Y luego vamos a tabla formato, formateador. Voy a copiar esto, ponerlo allí ya que es lo mismo en todos. Y luego tabla, ¿qué más dije? Ah sí, acción. Quiero hacer una acción. Así, está ahí. Entonces eso está ahí. Y ahora podemos relacionar esto de vuelta aquí con... Veamos, para la conexión queremos hacer... ¿Cómo quiero hacer esto? Creo que lo que haremos es hacer un ID de acción y luego haremos un ID de origen. Veamos, ID, lo necesitaremos. Oh, cambiar el color es una función profesional. Debo haber sido, ¿cuál es el término? Abuelo o algo así. No lo hice, no, no estoy pagando.

7. Explorando el Registro de Auditoría y el Flujo de Datos

Short description:

Sí, tengo el botón de actualización. Nicks, esto es cierto, sin embargo, se puede deducir que 41 probablemente existe, pero puede que no. No es muy confiable. UUID no soluciona esto, pero en una auditoría, es necesario tenerlo en cuenta. La mejor manera de obtener un flujo de datos es tener una marca de tiempo y datos adicionales e información sobre la tabla y los datos. Note jot se llama así para evitar conflictos con palabras reservadas. Tenemos esto allí, esquema, marca de tiempo, ID de conexión, mapa de formateador, JSON como tipo de datos. Y eso es todo.

Sí, tengo el botón de actualización. Así que no sé. Debo haber sido arrastrado allí de alguna manera. Lo siento por eso. Leyendo las preguntas rápidamente. Dame solo un segundo. Nicks, esto es cierto, sin embargo, se puede deducir que 41 probablemente existe, pero como dijiste, énfasis en probablemente existe, pero puede que no. Puede que ni siquiera haya existido nunca. Esto es algo que no sabemos porque la database puede haberlo eliminado y saltado al siguiente incremento. Entonces, aunque parece algo bueno para un registro de auditoría, no es muy confiable.

No es muy confiable, y no estoy diciendo que UUID solucione esto según tu referencia allí, pero en una auditoría, definitivamente se debe tener en cuenta desde la perspectiva de la auditoría. Que solo porque haya un incremento automático no significa que siempre haya la siguiente sucesión de números en orden. La database podría haber omitido cosas por varias razones, podría haber conflictos y los omitió, y nunca se ingresaron, muchas cosas. Un administrador de database podría haber ingresado y haber dicho que omita muchas cosas, comience a incrementar desde 4,000 cuando solo llegó a 399 o algo así. Entonces, desde la perspectiva de la auditoría, definitivamente se debe tener en cuenta que no hay realmente un flujo de ida y vuelta suave, como no hay una lista enlazada del flujo de datos. La mejor manera de obtener un flujo de datos es que tendrás que tener una marca de tiempo, tendrás que tener datos adicionales e información y registros sobre la tabla y los datos en la tabla. Pero eso es un buen punto para mencionar, buen llamado allí. Muy bien, veamos, puse eso aquí, aquí y aquí y luego pongámoslo aquí. Entonces esto es ref, esto puede ser action.id. Y esto va a ser ref. Source.id. Ahora, como puedes ver, mi nomenclatura generalmente sigue un enfoque con IDs donde puedo deducir fácilmente cuál es la relación sin mirar la relación física dibujada en la database. Solo puedo mirar el nombre y saber que action.id apunta a la tabla de acciones. Puedo mirar source.id y saber que apunta a la tabla de origen. El único que es un poco extraño es note jot. La razón por la que lo llamé note jot es porque uno podría apuntar una nota, que es una forma coloquial de decirlo, pero la palabra note a menudo es en la mayoría de las bases de datos una palabra reservada, he descubierto. Entonces realmente no puedes llamar a algo una nota como el nombre de la tabla, al menos en algunas bases de datos. No sé acerca de todas ellas. En ese caso, llamo a la tabla note jot para evitar ese conflicto, pero rutinariamente me refiero a esa tabla cuando llamo a una relación solo como note.punto algo. Porque en el fondo, está destinado a almacenar notas que alguien escribiría sobre una URI en particular. Muy bien, tenemos esto allí, esquema, veamos aquí, ¿qué más queremos allí? Queremos, básicamente, haremos la marca de tiempo estándar rápidamente. Ups, marca de tiempo. Y luego tendremos el ID de conexión, queremos relacionarlo con eso. Así. Y luego, hagamos un mapa de formateador. Y porque esto estará respaldado por Postgres, haremos JSON como el tipo de datos. Entonces eso es solo un mapa abierto, describirá el formato o el esquema, quiero decir de cualquier manera que sea necesario para que podamos saber cuál es el esquema de los datos subyacentes que están en la URI o que se extraerían de la URI. Muy bien, ¿qué no le gusta a mi cosa aquí? Nada como errores mientras haces cosas en vivo. Solo vamos a soltarlo por un segundo. Y luego conexión. ID de conexión. Oh, sé lo que hice. No establecí el tipo, tonto. Ahí vamos, bien, todo arreglado. Y luego para Formatter, vamos con sello nuevamente. Y luego creo que también necesitaremos el ID de conexión allí. Así que solo lo copiaré y luego haremos Formatter. Haremos un mapa de eso también, básicamente lo haremos un mapa JSON. Veamos aquí, y luego acción. Agregar Sello.

QnA

Construyendo el Modelo de Datos y Respondiendo Preguntas

Short description:

En esta parte, discutimos la necesidad de un ID de acción y la relación uno a muchos entre conexiones y acciones. También animamos a los participantes a construir su propio modelo de datos y tomar un descanso antes de comenzar la segunda parte. Respondemos preguntas sobre convenciones de nombres, herramientas de diagramación ERD y compartir e iterar en modelos de datos con el equipo.

¿Necesitamos el ID de acción? No, porque pueden ocurrir múltiples acciones en una conexión. Entonces, según la relación en la conexión, será una relación de uno a muchos hacia la acción. Así que eso debería ser lo que necesitamos allí. Realiza una acción. Oh sí, necesito declarar algo como la acción. Así que también lo haremos JSON. Entonces podemos definir acciones y extender y elaborar en lo que sería eso. Porque realmente no sé cómo sería el sistema del cliente aquí. Esto es solo, nuevamente, una idea de cómo construir un modelo para un sistema que potencialmente haría todas estas cosas. Así que ahí lo tenemos. Tenemos ese modelo de datos que mostré anteriormente en las diapositivas. Así es como construirías eso. Ahora, lo siguiente es que todos ustedes construyan su propio modelo que luego usaremos en breve al implementarlo en el producto Hasura. Así que todos tomen 10 minutos, hagan un descanso, tomen algo rápido para beber y comiencen a construir un modelo de datos que tenga al menos una clave primaria, una clave externa y algunas relaciones de muchos a muchos como hemos hecho aquí. Si quieren, pueden simplemente usar esto y lo haré muy fácil. Veamos aquí, lo pegaré en Discord. ¡Boom, ahí está! Así que si quieren tomar eso de Discord pueden tener este mismo modelo de datos o pueden construir lo que quieran. Así que tomen 10 minutos, son las 9:38 actualmente. Volveremos a las 9:48 y comenzaremos la segunda parte. También en este interludio, si tienen más preguntas o ideas sobre esto o preguntas sobre cómo modelar estas cosas por favor hagan esas preguntas y cubriré todo lo que surja cuando regrese. Volveré exactamente en 10 minutos a las 9:48 o 48 después de la hora, sin importar en qué zona horaria estén. Muy bien, nos vemos en unos momentos. Muy bien, espero que todos hayan podido tomar algo, descansar, etc. Algunas preguntas que responderé verbalmente ahora mismo. Nick preguntó, ¿por qué estaba usando PascalCase? ¿Fue solo una elección personal o alguna razón específica? En Discord también publiqué una entrada de blog donde hablé un poco más sobre eso, especialmente en el caso de las convenciones de nomenclatura de bases de datos y demás. En las bases de datos, sugeriría encarecidamente siempre seguir con CamelCase o PascalCase. No siempre importa cuál elijas. Sin embargo, personalmente tiendo a seguir la nomenclatura que se usa en la pila tecnológica. Entonces, si es.NET, a menudo uso PascalCase porque mucho del código.NET tiende a seguir la convención de ser PascalCase. Con Java, por ejemplo, a menudo cambio a CamelCase para que luego la base de datos, las tablas, las entidades que podrían generarse a través de GraphQL o lo que sea tiendan a estar en ese formato. Sin embargo, los programadores que escriben código contra estas tablas y entidades y otras cosas que se crearán a partir de la base de datos, usarán el mismo formato que ya usan en su código base. Entonces, para ellos, solo se verá como lo que es, sus objetos o entidades o tuplas o elementos o lo que sea fomenta la familiaridad desde esa perspectiva. Oh, interesante. Nivertec menciona que usa herramientas de diagramación ERD en línea de comandos y extensiones de VS Code, pero no genera SQL DDL. Eso parece extraño. Revisaría las herramientas de JetBrains, revisaría varias otras herramientas porque muchas, muchas, muchas herramientas de diagramación ERD que he visto casi siempre tienen especificaciones DDL que exportarán. Así que definitivamente revisaría algunas herramientas nuevas aquí. Debe haber algo en algún lugar. También hubo otra pregunta de Melody Burger. Dice, ¿cómo comparto, comunico e itero en el modelo de datos con el equipo? La herramienta de diagrama de base de datos, que veremos en un momento en realidad exporta el DDL. Te da un SQL, te da imágenes y luego puedes poner eso en el repositorio. Además, en la propia herramienta, puedes compartir estos diagramas como el propio diagrama real, en el diagrama de base de datos, a través de un enlace. Y luego incluso pueden ir, si les das permisos, y pueden editarlo o agregarle cosas siempre que sea necesario. Muchas de las otras herramientas que uso tienden a tener este tipo de capacidad. Entonces, al menos puedes poner una imagen en el repositorio o poner el SQL en el repositorio. Quiero decir, de todos modos necesitas el SQL en algún momento, especialmente cuando estás construyendo ese diseño inicial y necesitas ingresarlo en la base de datos. Si no tienes eso, entonces necesitas recrear manualmente todas las tablas y todo en la base de datos. Eso es bastante frustrante. Sería mucha redundancia de trabajo.

Configuración de Hasura y Backend de la Base de Datos

Short description:

En este punto, exportaremos el SQL desde db diagram hacia el servidor de la API GraphQL de Hasura. Revisaremos el modelo de datos y discutiremos su aplicabilidad a GraphQL. Si tienes alguna pregunta sobre NoSQL, no dudes en preguntar. También abordaremos los desafíos de trabajar con bases de datos distribuidas en GraphQL. Antes de continuar, regístrate en una cuenta de Hasura y un backend de base de datos en Heroku. En Hasura, crearemos un nuevo proyecto, usaremos el nivel gratuito y lanzaremos la consola. El código del diagrama de la base de datos se puede obtener desde el chat de Discord. Utilizaremos Postgres con Hasura. En Hasura, pegaremos el código SQL en la pestaña de datos y lo ejecutaremos. Exploraremos las conexiones, relaciones y entidades, y ejecutaremos consultas GraphQL. El análisis de consultas mostrará el SQL ejecutado por el servidor GraphQL, brindando información sobre el plan de ejecución.

En este punto, con db diagram, obtendremos el SQL y luego lo exportaremos a la herramienta que vamos a utilizar, que es el servidor de la API GraphQL de Hasura. Con eso, comencemos aquí. Tenemos nuestro esquema de base de datos. Vamos a ponerlo en funcionamiento y realmente construirlo, ejecutando algo de SQL. Vamos a ver algunas consultas GraphQL al respecto. Revisaremos algunas de las consultas y los planes de ejecución de esas consultas, agregaremos algunos datos a la base de datos, cosas así. También discutiremos más a fondo el modelo de datos y cómo se aplicaría o no a GraphQL. Y también, si tienes alguna pregunta sobre NoSQL, asegúrate de preguntarme también, porque dejaré eso un poco abierto. Pero una de las cosas que abordaré un poco al final aquí es cómo lidiarás con lo que obtienes de una base de datos distribuida desde una perspectiva de GraphQL, porque puede depender de la base de datos distribuida, puede depender de la base de datos de gráficos o cualquier otra cosa. Y realmente tendrás que hacer mucho trabajo pesado para el GraphQL tú mismo para determinar las relaciones o los gráficos de regreso a las cosas, como en el caso de Apache Cassandra, donde no hay relaciones. Tampoco hay uniones en esa base de datos, mucho más escalable por muchas razones porque es distribuida, escalable horizontalmente, etc. Pero luego, en GraphQL, para obtener el valor y el poder de poder relacionar las entidades y demás, deberás hacer esas conexiones en el servidor que estés utilizando para tu GraphQL. Un poco complicado. Sin embargo, con Hasura y una base de datos relacional, puedes dibujar esas conexiones, lo que lo hace muy, muy poderoso en ese sentido. Así que antes de hacer cualquier otra cosa, si no tienes una cuenta de Hasura y el backend de base de datos necesario a través de Heroku, ve y regístrate ahora mismo en una cuenta en Hasura y Heroku. Con Heroku, todo lo que necesitas hacer es crear esa cuenta e iniciar sesión, y luego en Hasura podrás hacer una autenticación contra eso para obtener la base de datos. Muy fácil en ese sentido. Como hacer clic en un botón. Así que si no tienes eso, comienza a registrarte ahora mismo. Continuaré un poco más y volveremos a eso. Así es como se ve la interfaz en la nube en la solución de Hasura. Haremos clic en nuevo proyecto, lo que creará un nuevo proyecto que se verá exactamente así. Y luego usaremos el nivel gratuito. Nuevamente, Heroku y Hasura combinados te brindan una base de datos gratuita y una API GraphQL gratuita. Y en él, solo ingresas el nombre del proyecto, la región y luego sigues adelante, hay un botón para hacer clic. Creará la base de datos de Heroku para ti siempre que tengas esa cuenta autenticada, lo cual el botón hará eso. Iniciará ese proceso y te permitirá terminarlo fácilmente haciendo clic en algunos botones. Luego haces clic en crear proyecto y se crea un proyecto que se verá exactamente así. Luego haremos clic en lanzar consola y eso es en lo que estaremos trabajando durante la mayor parte del resto de esta masterclass. Y nuevamente, esto es lo que construí y prospectivamente construiste, o puedes obtener el código del diagrama de la base de datos desde el chat de Discord. En db diagram, justo en la exportación, puedes exportar un PDF a Postgres, o un servidor SQL de MySQL o a PNG. Por supuesto, PNG es un formato de imagen. Así que obtendrás una imagen del diagrama, creo que es eso. Y Postgres, MySQL y SQL Server te darán SQL específico para esa base de datos relacional que puedes ejecutar contra esa base de datos en particular. En nuestra situación particular, utilizaremos Postgres porque Hasura funciona principalmente con Postgres en este momento. Y ni siquiera necesitamos lidiar con el PDF. No necesitamos un PDF de nada de esto, pero está ahí si lo necesitas. Y no sé si puedes sin una cuenta de pago o cualquier cuenta en la que esté incluido, ya que he podido guardar el diagrama. Así que eso es otra cosa que puedes hacer. Puedes guardarlo y compartirlo y les dará a las personas el enlace que apuntará al diagrama que acabas de crear. En Hasura, cuando iniciemos sesión, y no te preocupes, navegaré por esto. Solo te estoy mostrando una descripción general rápida de lo que estamos a punto de hacer. Pegaremos el código SQL que obtengamos en la pestaña de datos, en la sección SQL de la pestaña de datos es un lugar donde podemos simplemente pegar, ups, SQL sin procesar y luego ejecutar ese SQL sin procesar. Un poco más sobre eso en un segundo. Haremos eso y una vez para la base de datos, podremos dibujar conexiones, ver las relaciones, ver las entidades y ejecutar consultas GraphQL contra ella y hacer todo lo que necesitemos hacer en ese momento. También echaremos un vistazo al análisis de consultas. A medida que ejecutemos algunas consultas GraphQL, podremos verlas y ver el SQL que realmente está siendo ejecutado por el servidor GraphQL. Esto es muy importante, al igual que con cualquier esquema de datos, diagrama de datos, quieres saber cómo el servidor está ejecutando realmente el SQL, cómo está ejecutando la consulta, sea lo que sea. En este caso particular, es como una consulta básica contra algo que he ejecutado. Debajo del SQL generado, se muestra el plan de ejecución, porque incluso si tienes la declaración SQL, no sabes particularmente cómo un servidor de base de datos ejecutará algo a menos que veas el plan de ejecución.

Plan de Ejecución y Conceptos de Base de Datos

Short description:

Hasura proporciona el plan de ejecución para las declaraciones SQL. Las tablas contienen columnas y los datos almacenados en las columnas se llaman tuplas. Una tupla es una sola fila de datos. El esquema de relación incluye las relaciones entre las tablas. Cardinalidad se refiere al número total de filas en una tabla. Las claves primarias y las claves foráneas reciben índices para la optimización del rendimiento. La cardinalidad también puede referirse a los valores distintos en una columna. Comprender estos conceptos es importante al trabajar con bases de datos. Ahora, creemos un nuevo proyecto en Hasura y seleccionemos la región gratuita, Ohio.

El plan de ejecución muestra el tiempo y otras características relacionadas con eso. Postgres lo tiene, Oracle lo tiene, SQL Server lo tiene. Cada base de datos relacional tiene alguna forma de ver el plan de ejecución. Hasura proporciona esa capacidad para ver qué declaración SQL ha creado y proporciona el plan de ejecución justo debajo de eso. Así que lo veremos y hablaremos más sobre eso.

Bien, a la acción. Si volvemos aquí a exportar, Postgres. Incluso si no has realizado ninguno de los pasos hasta ahora, tengo un truco fácil para ti. Te llevará directamente a donde estamos. Voy a copiar todo este SQL en el chat de Discord. Así que, en dos segundos, uno, dos, boom. Todo está ahora en el chat de Discord. Así que, incluso si no has hecho nada de eso, aún puedes seguir desde este punto si quieres.

Ahora, solo quiero cubrir algunos detalles pedantes, pequeños detalles pedantes sobre una base de datos relacional. Especialmente si quieres hablar en gran detalle pedante sobre una base de datos. Estas son tablas, como mencioné. Estas cosas en las tablas son columnas. Los datos almacenados en esas columnas dentro de una tabla se llaman tupla. Es una sola fila de una tabla. Dentro de eso, es esa única fila de datos. Cada fila individual se considera una tupla. Ahora, en el habla de programador, eso puede ser un poco confuso porque en algunos casos, una tupla puede ser una cosa con dos o tres valores o lo que sea. Depende un poco de los lenguajes de programación, pero en las bases de datos, las bases de datos relacionales, una tupla es la fila. El esquema de relación es el esquema con todas estas relaciones aquí. Un esquema podría ser solo tablas sin la relación. Así que a veces se menciona específicamente el esquema de relación frente al esquema. Un grado es el número total de atributos. Entonces, los valores individuales dentro de una fila, atributos, eso es lo que es un atributo, que en relación se llama el grado de la relación. Así como las referencias, ves esas, esas son tus grados dentro de tus atributos, etc. La cardinalidad, esa es una palabra que surge con bastante frecuencia en las bases de datos relacionales. La cardinalidad es el número total de filas presentes en la tabla, ¿de acuerdo? Una alta cardinalidad proporcionaría muchos datos sobre varias cosas. Una columna, como mencioné, son estas. Veamos qué más. Asegurándome de no haberme perdido nada. He revisado una pequeña lista en mi cabeza aquí. La clave de relación, a veces las cosas se denominan específicamente como esta es la clave de relación, ¿de acuerdo? Y la clave primaria o la clave foránea, esta otra cosa a la que está relacionada, se denominan en general como una clave, ¿de acuerdo? Ahora, desde una perspectiva de rendimiento, estas reciben un índice. Cuando conviertes algo en una clave primaria o una clave foránea, reciben un tipo de índice. Puedes agregar índices a nivel de base de datos a otras columnas. No voy a entrar en eso, pero es algo muy importante de saber, especialmente en las bases de datos relacionales, porque los índices pueden mejorar drásticamente el rendimiento de las exploraciones, lo cual, a su vez, al ver estas consultas, verás en los planes de ejecución qué hacen las exploraciones. Así que si ves que algo está tardando mucho tiempo en una columna en particular, como si dijeras algo basado en esta cosa, puedes mejorar ese rendimiento a menudo asegurándote de que una columna en particular en la que estás realizando esa exploración esté indexada. Sí, Nevertech señala que también hay una cardinalidad de los valores distintos en una columna específica. La cardinalidad es una de esas palabras que puede significar una cosa o muchas cosas dependiendo del contexto específico en el que estés hablando, y se usa con bastante frecuencia. Lo verás en artículos de periódicos, lo verás en artículos de bases de datos, etc. Así que es importante tener en cuenta lo que significa específicamente en un sentido general y luego específicamente a qué se aplica en el contexto particular en el que se utiliza. Eso mismo ocurre con la tupla. Y menciono esto porque, a medida que pasas del stack tecnológico de desarrollo en JavaScript o C# o Java o Python o cualquier otro lenguaje que estés utilizando a la base de datos, y luego de vuelta, puedes ver estas palabras similares, que tienen significados distintivamente diferentes o solo ligeras variaciones en el significado, ayuda a conocer la diferencia para saber cuál es el contexto de la palabra con el stack tecnológico o la base de datos en particular. Bien, creo que eso cubre las bases de algunos de esos detalles pedantes. Bien, tenemos el SQL y espero que hayas creado tu cuenta de Hasura y tu cuenta de Heroku, y voy a seguir adelante y crearemos un nuevo proyecto, y lo llamaré el Proyecto de la Masterclass Impresionante. Solo voy a hacer clic en Free Tier y seleccionaré la región. La región gratuita es Ohio.

Configuración de la Base de Datos y Lanzamiento de la Consola

Short description:

Repasaremos los pasos para configurar la base de datos con Heroku y lanzar la consola. También discutiremos las variables de entorno y la configuración inicial del servidor de la API GraphQL. Por último, ejecutaremos comandos SQL para crear tablas y rastrearlas en el servidor.

Hay muchas otras regiones dependiendo de dónde te encuentres que podrías querer usar, pero yo simplemente usaré la capa gratuita para que todos podamos usarlo y hacer exactamente lo mismo y hacer que funcione. He nombrado el nombre demasiado largo. Debería saberlo mejor que eso. Vamos a llamarlo simplemente la Masterclass Impresionante. Ahí vamos, bien. Luego ve a Database Configuración. Voy a hacer clic en Probar con Heroku. Voy a hacer clic en el botón de Heroku. Justo aquí, si aún no lo has hecho. Aquí es donde comenzaría la autenticaciónauthentication. Harías clic en Aceptar, etc. y luego pasaría por ahí y crearía la aplicación de Heroku. Instalaría Postgres. Obtendría la URL de la base de datos. y la pondría aquí. Y luego, oh, una nota rápida. Puedes tomar este enlace de la base de datos. y puedes usarlo en un conector de Postgres en cualquier herramienta que estés usando con Postgres si estás haciendo eso. Es útil saber que eso es lo que es. Hago clic en Crear Proyecto. ¿Acabo de borrar algo? Bueno, voy a actualizar rápidamente. Puedo hacer eso de nuevo. Ahí vamos. No sé, creo que cuando resalté eso. Puede que haya estropeado el enlace ahí. Pero de todos modos, aquí estamos. Mientras estamos aquí, solo un poco de contexto rápido mientras se genera el servidor. Es útil saber dónde están las variables de entorno. Si haces esto, una de las primeras cosas que a menudo quieres hacer es quitar la consola de la vista en vivo. Porque literalmente cualquiera, como todos ahora mismo. Podría ir a la consola de los demás si estás creando esto. Porque inicialmente se crea completamente abierto. Pero lo que haces es agregar una nueva variable de entorno y vas hacia abajo. Y bueno, voy a escribirlo, porque lo hará más rápido. Habilitar consola, y querrías establecer eso en falso. Lo dejaré habilitado por ahora. Solo para que tengamos algo con lo que trabajar aquí. Ahora parece que estamos listos, todo bien. Y lanzar la consola. Ahí vamos. Ahora mismo, es un GraphQL. No tenemos nada aquí. Si haces clic en los datos, irá y mostrará que solo tenemos estos dos esquemas en nuestra base de datos. El catálogo HTTP Pro no está relacionado. No tienes que lidiar con eso en absoluto. Public es solo nuestro esquema público general. Y, por supuesto, no hay nada aquí porque no hemos creado nada aquí. Es una base de datos vacía con un servidor de APIGraphQL respectivamente vacío. Pero haz clic en SQL y eso cambiará todo eso. Voy a copiar literalmente, para que si algo, si me equivoqué en mi copiar y pegar anterior en Discord, también lo tendré. Voy a copiar ese SQL de allí y lo voy a pegar aquí. Ahí vamos. Como puedes ver, hace un bonito código de colores para nosotros. Tenemos todas nuestras notas y todo en nuestros tipos, etc.. Así que deberíamos estar listos. Otra cosa, puedes desmarcar o marcar rastrear esto. Haz clic en rastrear esto para que inicialmente rastree todas estas tablas y comience a agregar los metadatos necesarios en el servidor, para que sepa qué tipo de consultas y capacidades de GraphQL y otras conexiones que queremos. Voy a hacer clic en ejecutar y en unos segundos tendremos una base de datos.. Ok. SQL ejecutado y notarás aquí a la izquierda acción conexión notas formateadas esquema de trabajo, las notas de origen simplemente aparecen a medida que se creaba. Ahora haz clic en datos una vez más y dejará la pantalla de SQL y simplemente irá a la pantalla general de datos que normalmente ves cuando inicias sesión.

Seguimiento de Relaciones de Clave Externa

Short description:

Las relaciones de clave externa no se rastrean actualmente en la base de datos. Necesitamos agregar estas relaciones para garantizar la consistencia de los datos. Veamos las relaciones existentes y rastreémoslas en los metadatos. Después de agregar las relaciones, podemos editarlas si es necesario. Hay algunas tareas adicionales que debemos realizar en la base de datos.

Ahora hay algunas relaciones de clave externa que no se rastrean actualmente. Por lo tanto, rastreó las tablas pero no rastreó las relaciones de clave externa, eso es algo que vamos a querer hacer. Pero antes de hacer eso, veamos la relación para ver qué obtenemos aquí. Acción, por ejemplo, si hago clic en acción y luego voy aquí a relación, verás que la relación no está agregada actualmente. Así que no hagas clic en nada todavía, volveremos a eso. Lo otro que puedes hacer es, por ejemplo, ir a origen, tenemos insertar fila, modificar. Esto modifica la tabla en sí. Tenemos, nuevamente, las relaciones y las dos conexiones que cree que podemos inferir para las entidades de GraphQL para que sepan que están conectadas de esa manera, ¿verdad? La base de datos lo sabe porque dibujamos las conexiones de la base de datos en las relaciones de clave primaria en el SQL. Pero el servidor de servicio aún no ha establecido esa conexión en sus metadatos para conectarlas de manera sólida porque nos ha dado la opción de hacerlo. Pero ve en la base de datos que obviamente están ahí porque son conexiones reales dentro de la base de datos misma. Así que volvamos a hacer clic en datos y luego haz clic en rastrear todo. Eso agregará todas esas relaciones. Solo tomará uno o dos segundos aquí. ¿Cómo está el tamaño de fuente, por cierto, todos? ¿El tamaño de fuente está bien? ¿Debo aumentar el tamaño de fuente? Cualquier otra queja de ese tipo, avísenme. Veré si puedo ajustarlo hacia arriba o hacia abajo o algo así. Porque sé que algunas de estas fuentes se vuelven un poco pequeñas en el tamaño de pantalla de 1080p. Muy bien, las relaciones se agregaron, así que tendremos un elemento de transición así, las relaciones se agregaron. Ahora, si vamos a, digamos, acción, vamos a relaciones, verás que ahora es una relación real, ya no hay un botón de agregar, solo hay un editar, así que haz clic en eso y realmente puedes cambiar la relación si quieres, pero no necesitas hacer eso. Sin embargo, hay algunas otras cosas que queremos hacer en esta base de datos que no se hicieron antes.

Configuración de Migraciones y UUIDs para Inserciones por Lotes

Short description:

Configurar migraciones es importante para automatizar la creación o cambios en la base de datos. Los UUIDs permiten inserciones por lotes y minimizan las consultas a la base de datos. Usar UUIDs como clave primaria y relaciones de clave externa en todo el modelo de datos es crucial para la optimización del rendimiento. Hasura proporciona autocompletado basado en tipos de datos, lo que facilita realizar cambios rápidos. La función predeterminada 'now' se utiliza comúnmente en varias bases de datos. Las operaciones de actualización varían según la base de datos. En Apache Cassandra, las operaciones de actualización pueden ser peligrosas si la clave primaria tiene varias columnas.

De acuerdo. Este es un punto en el que, si estuviera haciendo esto desde una perspectiva de equipo, desde una perspectiva de flujo de trabajo, ¿verdad?, tratando de incluir todo en el repositorio, como mencionó Melanie anteriormente, ¿cómo compartes todo esto con un equipo? En este punto, este sería el primer punto en el que inmediatamente configuraría las migraciones para automatizar la creación o cambios de la base de datos. Sin embargo, no lo haremos hoy porque estamos enfocados en un tema diferente, pero es muy importante que se inicie lo antes posible para tener un flujo limpio de migraciones desde las migraciones de la versión uno hasta la versión dos de la base de datos, y que se mantengan sincronizadas con el desarrollo de software o los escritores de informes o cualquier persona que use tu base de datos y ejecute consultas GraphQL, etc., en la base de datos. Es decir, quieres mantenerlo sincronizado con ellos para poder darles siempre la especificación de versión y que sepan exactamente qué están obteniendo en la base de datos. Entonces. Si observamos las relaciones, eso está bien, pero lo otro es, vamos a modificar, veremos que esto es un UUID, clave primaria, y es único. Eso es lo que queremos, pero queremos cambiar el valor predeterminado al UUID aleatorio para que la base de datos cree el UUID por nosotros. Ahora, al hacer esto en Postgres, así como en muchas otras bases de datos, obtienes el UUID, la base de datos lo genera por ti. Sin embargo, eso no te impide en el lado del cliente, si es necesario, crear un UUID. Y esto es algo muy interesante que puedes hacer con UUID y que no puedes hacer con incrementos automáticos, y es muy importante, especialmente si tienes un sistema con muchos usuarios que leen y escriben datos y cosas que tendrán relaciones entre los datos primarios y los datos de clave externa que pueden necesitar escribirse en varias tablas. Pero no quieres hacer una serie de consultas a la base de datos porque quieres acelerar el rendimiento del sitio web. Entonces, la forma de hacerlo es que el sitio web cree ese valor inicial de clave primaria. En este caso, digamos origen, está bien. Pero tan pronto como lo creen, está configurado, está listo para guardarse. Pero el usuario también quiere hacer otras cosas como crear la acción, el formateador u otra información como las notas alrededor del origen en el momento de la creación del propio origen. Si ese es el caso y aún están creando esos datos. Como tienes todas estas cosas en un formulario donde pueden crear estas cosas. Es posible que desees que creen más información y luego escriban todo a la vez en la base de datos. La única forma de hacer eso es usar UUIDs. Y luego, al dibujar la relación de clave primaria externa en el cliente, a medida que crean esos datos, has creado ese UUID para poder pasarlo a la base de datos para que la base de datos dibuje correctamente estas correlaciones entre estos datos que se crean en el lado del cliente. Puedes enviar todo a la vez. Entonces, básicamente, tienes una inserción por lotes en una multitud de tablas y los UUIDs te permiten hacer eso, mientras que los incrementos automáticos no te permitirían hacerlo porque podrías tener conflictos cuando varios usuarios intentan escribir cosas en la base de datos. Y requeriría una consulta adicional cada vez. Escribirías la inserción y tendrías que solicitar ese ID implementado automáticamente y luego usarlo para los datos relacionados con la clave externa y enviar esos datos. Así que hay todo un viaje de ida y vuelta que se requiere en esas situaciones, mientras que con UUIDs no es necesario. Esto también es muy, muy importante con GraphQL porque si tomas una entidad compleja y tienes elementos relacionados dentro de esa entidad de entidades y tratas de escribir todo de nuevo, es posible que solo tengas las cosas pertinentes que necesitas. Pero quieres minimizar las consultas a la base de datos y el ir y venir que ocurre. Entonces, en GraphQL lo ocultaremos, pero como administrador de la base de datos, la persona que administra la base de datos, querrías asegurarte de que no haga más consultas de las necesarias. Y eso se soluciona usando UUIDs como clave primaria, clave externa y relaciones en todo tu modelo de datos. Así que voy a guardar eso con la generación aquí. De esa manera, no siempre tengo que obtener eso desde el lado del cliente si no quiero. Y luego para el sello, voy a tomar el valor predeterminado y voy a usar ahora. Observa cómo Hasura te da el autocompletado, pero te lo da en función del tipo de datos. Muy, muy bueno. Eso es parcialmente, ya sabes, es del tipo de datos. El nombre se extrae de eso. Así que ayuda mucho cuando intentas hacer algunos cambios rápidos y obtener los autocompletados que son específicos para lo que estás intentando hacer. Muy bien, tenemos el ID y el sello ahí. Entonces, clock underscore timestamp. Creo que eso depende del tipo de base de datos. Ahora, en realidad no conozco la diferencia específica entre eso. Si sabes, por favor, explícalo, Bravan. Yo solo uso now porque también es... Suele ser la función predeterminada en otras bases de datos también, lo cual me gusta. Las operaciones de actualización son interesantes. Y dependiendo de la base de datos, se comportan de manera diferente. Porque esta es definitivamente una buena pregunta de NoSQL. En tu consulta, ¿cómo lo almacenas? En tus documentos XAML, ¿tienes una variable que define un nuevo elemento en cada bucle? ¿Entonces almacenas un solo elemento que no se debe llevar a la siguiente consulta? Por ejemplo, en Apache Cassandra, las operaciones de actualización pueden ser peligrosas. Porque puedes tener un ID, que es tu clave primaria. Y puede tener varias columnas, porque una clave primaria puede tener varias columnas.

Consideraciones de Diseño y Desarrollo de Bases de Datos

Short description:

Cuando se utilizan UUIDs en una base de datos, insertar un nuevo registro con el mismo nombre y dirección de correo electrónico puede resultar en una entrada duplicada debido al UUID único generado. Las actualizaciones en las bases de datos son en realidad una operación de eliminación e inserción. Al utilizar marcas de tiempo, es importante considerar factores como las zonas horarias, los servidores de tiempo y la precisión de la función. La CLI de Hasura automatiza las migraciones y realiza un seguimiento de la versión, lo que facilita cambiar entre diferentes versiones del esquema de la base de datos. Esto simplifica la gestión de proyectos y la colaboración.

Se llama, digamos, una columna de candidatura. Entonces, si tienes eso, y una columna es un UUID, una columna es un nombre, y una columna es una dirección de correo electrónico, y luego intentas insertar un nuevo registro con el mismo nombre y dirección de correo electrónico, porque solo quieres actualizar el nombre y la dirección de correo electrónico, si estás usando UUID, terminas con un duplicado. Porque el UUID se generaría de manera diferente. Y sería un valor diferente. Entonces, aunque el nombre y la dirección de correo electrónico sean los mismos, se crearía una nueva fila en la database. Ese es uno de los problemas con las actualizaciones. Y las actualizaciones no son algo funcional que ocurra. Todavía se realiza una inserción, pero se le llama actualización porque debes especificar cuál es tu ID en la actualización para asegurarte de que la actualización que esperas realmente ocurra. También es probablemente bueno mencionar que las actualizaciones son un concepto mítico dentro de las bases de datos, porque lo que realmente sucede es una eliminación e inserción en el lado de la database, cada vez que haces una actualización. Cuando haces una actualización, ocurren esas dos cosas. Así que ten en cuenta que estás realizando dos acciones cada vez que haces una actualización en una database.

Oh, ¿qué más hay que mencionar al respecto? Hay mucho. Hay mucho que pensar en el diseño y desarrollo de una database. Así que sí. Volviendo a la database específicamente aquí alrededor de estas tablas. En acciones, he actualizado eso. Voy a actualizar origen porque voy a jugar un poco con origen para mostrar algunas cosas. Así que vamos a obtener esto y agregar el UID allí. Y agregaremos la marca de tiempo. Muy bien, ahí lo tenemos. Y luego vamos a hacerlo también para... Notas de origen no lo necesita porque en cada situación siempre tomarías el ID de origen y el ID de nota para dibujar esta relación mientras haces la inserción en las notas de origen, por lo que no es necesaria ninguna función allí. Sin embargo, en marca de tiempo también quieres hacerlo ahora. Excelente, ahora puedes hacerlo. Entonces, ¿cuál es la diferencia, como preguntó Previn, entre ahora y marca de tiempo? Así que una pequeña desviación aquí en el buen viejo stack exchange. Dice que no veo ninguna diferencia, sin embargo ellos afirman, ah, no hay diferencia. Entonces, las funciones estándar de SQL devuelven un valor basado en la hora de inicio de la transacción actual, marca de tiempo actual, marca de tiempo de transacción, equivalentes a la marca de tiempo actual. Esto es equivalente a la marca de tiempo de transacción tradicional de Postgres. Así que ahí lo tenemos. Bueno saberlo. Supongo que ahora es básicamente un envoltorio para eso, al igual que ahora a menudo es un envoltorio en otras bases de datos para esas cosas. Es una muy buena pregunta, sin embargo. Y para ampliar sobre la preocupación que a menudo se deriva de las preguntas, debes asegurarte de que, cuando uses cualquier tipo de marca de tiempo, se estampe en la zona horaria, en el formato y con otros detalles que esperas. Y conoces los criterios, por ejemplo, ¿está utilizando un servidor de tiempo, verdad? ¿O está utilizando el servidor de tiempo o el reloj local de la database? ¿Verdad? ¿El reloj del servidor local? ¿El servidor local está en tu zona horaria o está en UTC, o incluso está configurado en UTC, pero en una ubicación diferente? Hay muchas variables diferentes en torno a las horas y marcas de tiempo que debes tener en cuenta, especialmente, aún más, si la marca de tiempo se utiliza para una auditoría legal. A menudo, en esa situación, querrías estandarizar algo específico que esté bien documentado, como UTC, y luego hacer cualquier conversión a otras zonas horarias o lo que sea basado en UTC para esa auditoría y la marca de tiempo. Saber qué hace la función y qué tan precisa es la marca de tiempo es crucial para poder entender exactamente en qué estás trabajando. Saber qué hace la función y qué tan precisa o posiblemente imprecisa puede ser una función al hacer una marca de tiempo es muy importante. Tenemos notas de origen, esquema, nota JOT. Echemos un vistazo a eso. Voy a agregar UUID allí. Solo voy a hacerlo rápidamente para todos ellos. Nuevamente, marca de tiempo. Ahora lo genial, si usas la CLI de Hasura, todo esto mientras lo haces en la consola se automatizaría y se mantendría en migración. Entonces, cada vez que ejecutes tu DDL, ejecutes tu esquema de database, puedes moverte hacia adelante y hacia atrás entre las versiones que mantienes. Como esto sería la versión dos en la que estoy trabajando ahora con estas funciones predeterminadas adicionales en su lugar. Entonces, con las migraciones y el uso de la CLI, puedes ir automáticamente hacia adelante y hacia atrás entre ellas con un simple Hestera Migrate Apply. Y en la consola, puedes ejecutar desde tus migraciones para implementarlo y luego realizar estos cambios. Y escribe el SQL en tu carpeta de migraciones dentro de tu proyecto. Muy fácil, como mencionó Melanie anteriormente, ¿cómo te mantienes al día con estas cosas en tu proyecto? Es muy fácil entonces porque crea el SQL para que lo tengas en tu directorio de migraciones que puedes poner en tu repositorio y en cualquier otro material que necesites para tu proyecto, ya sea tarjetas de Jira u otra cosa.

Explorando Herramientas de GraphQL y Análisis de Consultas

Short description:

Con Asura, puedes evitar fácilmente escribir consultas SQL innecesarias. La función Formatter te permite elegir diferentes funciones y sus valores predeterminados. Al trabajar con GraphQL, Asura inspecciona la base de datos e infiere entidades basadas en las tablas. Es importante elegir el formato adecuado para mayor familiaridad. Las herramientas Explorer, CodeExporter y Voyager son útiles para ejecutar declaraciones GraphQL, exportar código y visualizar los metadatos de la base de datos. Voyager proporciona un mapa de los metadatos, rutas de consulta y tipos de datos. Es una herramienta valiosa para solucionar problemas y comprender la API de GraphQL. La función analyze proporciona información sobre la ejecución de consultas y la estructura anidada de los datos. Es útil para modelos complejos y ejecución en el lado del servidor.

Una excelente manera de poder hacer eso. Lo hace muy fácil para que no tengas que escribir ninguna consulta SQL que realmente no necesites escribir. Así que realmente una gran opción allí. Formatter. Vamos a una vista rápida aquí. También tienes una preferencia, como se mencionó, con sellos de tiempo. Si no quieres usar ahora, hay todas estas otras funciones, puedes elegir otra opción predeterminada. Todas aparecen en el menú desplegable y facilitan determinar cuál quieres elegir y usar.

Muy bien, tenemos eso. Ahora adentrémonos en el mundo de GraphQL. Con Asura, inspecciona la base de datos, que en este caso es la base de datos que acabamos de crear con nuestras tablas específicas, y analiza nuestras relaciones e infiere cosas y lo que deberían ser las entidades. En este caso, las entidades son generalmente las tablas. Nuevamente, como se mencionó anteriormente, es importante elegir el formato adecuado. Ayuda a que sea familiar lo que es el concepto de la cosa que estás recuperando con tu consulta, etc., para las personas que escriben código contra esta API en particular, ¿verdad? Así que elige tu formato CamelCase o PascalCase en consecuencia.

Aquí, veamos, íbamos a hacer origen. Hagamos una consulta básica. Elige ID, nombre, sello de tiempo y URI. Por supuesto, no tenemos nada aquí. Ejecutamos eso, boom, nada, ¿verdad? Sin embargo, tenemos algo, hemos ejecutado una consulta. Si miras el historial, mi consulta se ha ejecutado. Si cambias el nombre por otra consulta, por ejemplo, y la ejecutas, boom, aparece en el historial. Puedes volver a estas diversas consultas y verlas. Así de fácil, simplemente haciendo clic en las cosas.

El explorador, lo voy a cerrar por un momento. Voy a cerrar el historial por un momento. Ahora digamos que necesitas escribir algo de código que va a ejecutar esta declaración GraphQL. Haz clic en CodeExporter. Aquí tienes opciones, TypeScript, JavaScript. Como puedes ver a continuación, proporciona el código que necesitas para ejecutar eso, básicamente en formato de copiar y pegar. Puedes cambiar de fetch, o puedes usar React Apollo. Muestra el código pertinente para eso. Así que una característica muy útil. Vamos a deshacernos de CodeExporter por un momento. Luego, haz clic en Voyager. Transmitiendo al espacio. Muy bien, esto puede ser un poco abrumador al principio. Así que vamos a hacer zoom. Como puedes ver, este es un mapa de los metadatos que se crearon sobre la base de datos, que tiene todas las correlaciones, etc. Rutas de consulta para cada una de las tablas que creamos, acción, acción agregada, conexión, formateador, notaJOT, esquema, origen, etc. Y luego eso se mapea para ver los nodos, los mínimos, máximos, ver los tipos de datos y otras cosas así. Tienes tu conexión, origen, y la lista continúa. Así que una excelente manera de descubrir qué está sucediendo en cuanto a la base de datos en el diseño del GraphQL sobre el esquema de la base de datos construido con DDL. Muy bien. Muy, muy útil, un lugar muy importante cuando comienzas a construir modelos más complejos y necesitas solucionar problemas con tu API de GraphQL y determinar qué quieres hacer en cuanto al modelo, pero también tus entidades y cosas así. Luego, hagamos un análisis rápido y veamos qué obtenemos. Ese es el análisis de consulta que mostré un poco antes en las diapositivas. Así que una consulta bastante sencilla porque solo se ejecuta contra una entidad única, y en este caso, una tabla única. Hay algunas anidaciones, que es cómo se genera de forma predeterminada estas cosas. A medida que tus consultas se vuelven más complejas, esto se vuelve más complejo. Y puedes ver aquí lo que estás obteniendo y ejecutando en el lado del servidor. Así que profundicemos un poco en eso.

Añadiendo Registros y Valores Relacionados

Short description:

Volviendo al Explorador y cambiando la fuente a una mutación. Realizaremos una inserción sin el campo ID y solo incluiremos el nombre y la URI. La base de datos se encargará del ID y la marca de tiempo. Al solicitar el ID y la marca, podemos confirmar que se creó el registro y obtener la información necesaria para futuras referencias. Utilicemos mi blog como referencia y agreguemos un registro. Ahora, vayamos a YouTube y agreguemos otro registro. Ahora tenemos algunos registros. A continuación, agreguemos un valor relacionado yendo a la fuente y seleccionando el formateador. Agregaremos algo al formateador e incluiremos el ID de conexión.

Primero, resolvamos eso. Vuelve al Explorador. Y aquí está, esta es una de las características que me encantan de Hasura y su integración gráfica de URL. Es como vamos a la fuente. Y cambiemos esto a una mutación. Y verás todas las inserciones, actualizaciones, eliminaciones, etc. ahora. Vamos con la fuente, hacemos una inserción y no quiero insertar el ID, así que lo quitaré. Quiero hacer el nombre y la URI. Eso es todo. Porque el ID y la marca de tiempo los hará la database, ¿verdad? Así que deshagámonos de esta cosa. Y luego, control + espacio, al igual que en GraphiQL normal, te dará el autocompletado para cosas. Así que solo quiero devolver eso. Voy a pedir el ID y la marca. De acuerdo. Eso me dará confirmación sobre varias cosas. Uno, que el registro se creó cuando lo solicité. Me dará el ID y la marca para que sepa cuándo se hizo. Y también tendré el ID si quiero hacer referencia a ese registro en particular con cualquier cosa que esté haciendo en mi base de código. Así que es una táctica de consulta bastante común que uso. Muy bien, primero la fuente. ¿Cuál es una buena página web? ¿Alguien tiene una buena página web? Voy a ir a mi blog. Lo usaré como referencia. Entonces, composite code dot blog. Ponlo aquí. Y luego el nombre es composite. Composite. Brash encode. Y lo voy a agregar. Ahí lo tenemos. Tenemos el ID y la marca. Vuelve de eso. Estamos listos para continuar. Vamos a otro sitio web. Vamos a YouTube. Al canal de Hasura HQ. Hay mucho contenido bueno allí. Así que un gran reconocimiento a nuestro contenido en YouTube. Así que voy a tomar eso y ponerlo aquí. Ahora tenemos algunos registros. Y boom. Nuevo ID, nueva marca. Así que eso es genial. Ahora tomemos ese ID aquí y agreguemos un valor relacionado. Vamos a la fuente. Y luego queremos hacer el formateador. Digamos que YouTube tiene una API. Así que estaríamos agregando algo al formateador. Esa es la actualización. Quiero la inserción. Tendremos el ID de conexión.

Añadiendo Conexión a la Fuente

Short description:

Primero necesitamos agregar la conexión a la fuente. La conexión necesita el ID de acción y el ID de la fuente. Si tienes elementos de clave externa con elementos requeridos, el ID de la clave primaria debe estar disponible al insertar el registro. Volvamos atrás y agreguemos el ID y el ID de la fuente. Luego iremos a Insertar Conexión. Primero omitiremos la creación de los otros elementos y luego veremos la ejecución nuevamente.

¿Qué dibujé? Creo que esto es malo. Aquí vamos. Primero necesitamos hacer la conexión, así que haremos el ID de la fuente. Y luego, sí, ahí vamos. ¡Ups! Quita eso. SKING. Bien, eso está bien. Luego haremos, pensé que había llamado, oh sí, acción. Veamos cómo podemos hacer esto. Así que formateador. Mira, aquí es donde empieza a complicarse cuando estás haciendo una inserción múltiple.

Vale, en realidad me he confundido. Déjame mirar esto de nuevo. Vale, puse la fuente y solo quiero agregar, necesito agregar la conexión a la fuente primero. ¿Qué necesita la conexión? Necesita todas estas cosas. Así que necesita el ID de acción, el ID de la fuente. Creo que lo dejé, asegurémonos de que sea nulo. Sí, así que puedes agregar uno u otro mientras se hace. A tener en cuenta, eso es otra cosa. Si tienes elementos de clave externa que tienen elementos requeridos, el elemento de clave primaria, ese ID necesita estar disponible para ser insertado con este registro cuando finalmente se junte este registro con todos sus elementos requeridos. Y si eso lleva un minuto, es posible que no tengas ese identificador único si solo envías el elemento de clave primaria al cliente, ¿verdad? Y luego, por alguna razón, no has obtenido el valor de incremento automático o algo así. Así que eso es importante tener en cuenta. Veamos aquí. Conexión. Necesitamos ir con el ID Standards. Volvamos atrás y hagámoslo. El ID se generará automáticamente para nosotros, y luego queremos hacer el ID de la fuente, eso es lo que queremos agregar. Y lo agregué. Cambia esto a mutar. Y mutación. Ahí vamos. Y voy a deshacerme de esto. Vamos a Insertar Conexión. Así que queremos... Tu ID se generará automáticamente. Queremos el ID de la fuente. Eso es lo que copié. Vale, ahí vamos. Luego no necesitaremos este sello. Y eso simplemente proporcionará la conexión. Debe tener una selección de subcampos. Así que veamos, Fuente. En realidad, hagamos esto. Mm. Siento que tal vez deberíamos crear los otros elementos primero y luego este. Así que en ese caso, voy a omitir eso, y vamos a ver la ejecución nuevamente. Así que tenemos la fuente. Veamos eso. Ahí vamos.

Consultas Anidadas y Consideraciones de Rendimiento

Short description:

Tenemos una consulta de un solo registro donde filtramos por nombre. Los conjuntos de resultados se devuelven y se asignan a sus campos correspondientes. A medida que la consulta se vuelve más compleja, se introducen relaciones anidadas, lo que puede provocar problemas de rendimiento debido al aumento del número de uniones. Es importante mantener el número de uniones mínimo para evitar una disminución del rendimiento. La creación de tablas desnormalizadas puede ayudar a mejorar el rendimiento de las consultas al agrupar conjuntos de datos de acceso frecuente.

Entonces tenemos dos. No hay detalles allí. Uno es un blog. El otro es el otro. Así que si hacemos eso, pero luego decimos donde, vamos con el nombre igual a hasura.hq. ¡Ups! Se llama consulta de un solo registro. Así que podemos verlo directamente. Y luego voy a revisar el historial. Ahí está, junto con los demás. Voy a analizar eso y veremos lo que tenemos.

Aquí puedes ver que el where está construido de esta manera. Lo que voy a hacer es desplazarme hacia abajo hasta donde está, y voy a usar el where construido de esta manera. Entonces el nombre de la fuente pública es HHQ y es igual al texto. Es un poco extraño, porque es posible que no pienses en esto como el SQL que escribirías tú mismo si escribieras esta consulta, pero te muestra cómo se hace y cómo se completan estas cosas. Y puedes tomar la determinación. Y por supuesto, aquí están las tres cosas. A partir de esta consulta, se ejecuta esa consulta. Luego se ejecuta esta consulta en ese conjunto de resultados para mostrar los conjuntos que se devuelven, es decir, las tuplas que se devuelven. Y mapea el ID al ID, el nombre al nombre, los detalles a los detalles para que cuando lo veas, vuelva exactamente así.

A medida que esto se vuelve más complicado, sin embargo, veamos uno de estos locos. Digamos que tenemos una conexión y quieres mostrar varias cosas pertinentes. Quieres ver la acción y luego quieres el formateador, el mapa de formateador, el ID del sello. Luego quieres la fuente, el nombre, el ID, el sello. Puedes ver cómo esto comienza a anidarse. Tienes la conexión y luego la acción dentro de eso. Dentro de la acción tienes conexiones y luego la fuente. Ahora veamos si esto se ejecuta. Lo hizo. Sin embargo, hablemos de esto por un momento. Puedes ver que hay muchos más pasos para lo que acaba de ocurrir, aunque no hay data para ejecutarlo en contra. Aún así, tiene que pasar por estos pasos. Hay un escaneo de secuencia de bucle anidado, un escaneo de índice de bucle anidado, otro agregado, bucle anidado, escaneo de secuencia de bucle anidado dentro de eso, otro escaneo de índice, etc. Entonces, si esto es, por así decirlo, un registro en esta unión, el siguiente se ejecuta, consulta, contra el conjunto de todo eso. Entonces puedes tener un producto cartesiano o incluso un producto cartesiano de la consulta. Técnicamente, podrías sobrecargar tu servidor con ciertos tipos de consultas como esta. Y debes ser consciente de eso para poder tomar precauciones. Por ejemplo, esta conexión en acción. Probablemente no querrías llamarla tan profundamente, lo más probable. Querrías mantenerla mínima a un nivel superior. Querrías hacerlo como máximo a dos niveles de profundidad. La buena regla a seguir, al igual que con el diseño relacional, es que nunca quieres ir demasiado lejos con demasiadas uniones. A medida que se agregan uniones, se produce un gran aumento en la disminución del rendimiento, debido a los escaneos correlativos que se deben realizar en la base de datos. Para minimizar eso, mantén las cosas a un nivel de profundidad, dos niveles de profundidad. Y puedes pensar en ellos como tus uniones, ¿verdad? A medida que te anidas en un objeto de entidad de esa manera, aumentas tus uniones. Entonces, cuando diseñes el esquema de tu base de datos, piensa en las entidades de GraphQL y cómo se consultarán. Entonces, una de las cosas que puedes hacer para solucionar consultas o cambiar cosas para que sean más rápidas o más fácilmente consultables, si sabes que ciertos conjuntos de data siempre se necesitan juntos, puedes crear una tabla desnormalizada. Y tal vez, ya sea con código o algo más, llenar eso al mismo tiempo que llenas tus tablas de sistema de registro. Ahora, una forma de hacerlo es si volvemos a data, y digamos que queremos esa conexión con sus datos relacionados necesarios.

Optimización de Consultas para el Rendimiento

Short description:

Podemos combinar las columnas de ID de acción e ID de fuente en una sola tabla para consultas más rápidas. Este enfoque desnormalizado reduce la redundancia y permite consultar múltiples elementos dentro de la entidad. Al minimizar las uniones y anidaciones, podemos obtener resultados más rápidos con solo un nivel de anidación.

Entonces tenemos el sello de ID, pero tiene una acción e ID de fuente. Por lo tanto, podríamos querer una tabla que tenga todas las columnas de ID de acción e ID de fuente combinadas. Muy desnormalizado, muchos elementos redundantes de data dentro de eso. Como se mencionó anteriormente sobre la cardinalidad, tu cardinalidad distinta disminuye y tienes mucha redundancia dentro de una tabla. Pero tienes una sola tabla o una sola entidad en GraphQL para consultar. Entonces puedes consultar múltiples elementos diferentes dentro de esa entidad, o en términos de SQL, múltiples columnas diferentes para consultar en esa entidad y obtener resultados más rápidos. Y también obtener resultados que están anidados solo un nivel para minimizar la cantidad de uniones y anidaciones dentro de la consulta misma que se debe ejecutar en la base de datos.

Rendimiento, Diseño y Casos de Uso

Short description:

La normalización y desnormalización de datos juegan un papel crucial en el rendimiento y el diseño. Considere qué partes de la entidad se necesitan en un momento determinado y si es necesario ampliar la entidad para incluir otras cosas. Sígueme en Twitter, Twitch y YouTube para obtener más contenido relacionado con Hasura y GraphQL. Hasura no se limita a aplicaciones CRUD y ofrece funciones como validación personalizada, autenticación y esquemas remotos. Se puede utilizar para aplicaciones móviles orientadas al cliente con permisos basados en roles y autorización.

Entonces, con eso, ¿alguna pregunta al respecto? Porque ahí es donde se encuentra la mayor parte del rendimiento y del diseño, es en la normalización o desnormalización de los datos para cambiar cómo hacemos las consultas con nuestros queries y GraphQL de las entidades. ¿Qué partes de la entidad queremos en un momento particular? ¿Queremos más de lo que está disponible en una sola entidad? ¿Necesitamos ampliar esa entidad para incluir otras cosas? Esas son las cosas que debemos tener en cuenta.

Entonces, preguntas, comentarios, etc. A medida que piensas en otras preguntas o comentarios, voy a mostrar mi última diapositiva, porque básicamente es el material que tengo para esto. Tengan en cuenta que la diapositiva tiene enlaces, voy a poner estas diapositivas a disposición. Las publicaré en el discord en los próximos minutos. Así que si quieres los enlaces en las diapositivas, solo tienes que obtener las diapositivas y tienen los enlaces. Son todas diapositivas de Google, así que no se necesita nada, ningún formato loco o aplicaciones para eso, y voy a agregar algunas cosas aquí. Por ejemplo, yo, contáctame en Twitter en Adren. Twitter, Twitch, Adrian. Twitter, Twitch y YouTube también. También transmito programas en Hasura HQ sobre este tema específico en relación con la herramienta Hasura. Hay muchas cosas por ahí sobre migraciones. Voy a hacer más. Y en un futuro muy cercano, en 2021, estaremos escribiendo aplicaciones con React, Vue.js, cosas así en torno al servidor de API de Hasura utilizando GraphQL. Hay muchos temas de GraphQL de profundización en ese sentido. Así que asegúrate de seguirnos en Twitch, suscribirte en YouTube y seguirnos en Twitter. Yo, personalmente, estoy disponible en Twitter en twitter.com/Adrian. Y en Twitch en twitch.tv/thrashingcode. Y en YouTube en lo mismo. También tenemos GraphQL Asia próximamente. Así que, si estás interesado, definitivamente échale un vistazo. Y para más entrenamiento sobre este tema específico, así como muchos otros sobre GraphQL, cómo hacer el modelado de datos en GraphQL, visita siro.io/events. Hay muchas cosas buenas ahí. Y eso es prácticamente todo. Creo que podría tener, veamos aquí. Oh no. Definitivamente sígueme en Twitter y envíame un mensaje si estás interesado en créditos. Porque creo que tengo algunas opciones de crédito bastante geniales que puedo darte. Pero sígueme y te los enviaré porque no tengo el código conmigo en este momento. ¿Cuáles son los casos de uso previstos para Hasura? ¿Es esto principalmente para aplicaciones CRUD empresariales o para aplicaciones web móviles orientadas al consumidor? Anibertec pregunta. Sí. ¿No es esa la mejor respuesta, sí? Definitivamente se puede utilizar muy, muy fácilmente para aplicaciones CRUD. Porque como viste, mientras trabajaba en ello, puedes ir y todas las características CRUD están ahí por defecto, listas para usar. Como todo esto, nada de esto estaba predefinido al comienzo de la masterclass. Lo hice como lo haría en cualquier circunstancia la primera vez que lo hago, para todos ustedes. Una razón por la que hago esto es asegurarme de que no haya pequeños contratiempos en el proceso. Me gusta asegurarme de que cualquier material que presente sea fluido de principio a fin, para que tu experiencia sea la misma experiencia que te estoy mostrando. No quiero trucos ahí. Así que lo viste ahí mismo, simplemente, boom. Todas las capacidades CRUD están ahí por defecto. Sin embargo, Hasura hace mucho más que eso. Por ejemplo, puedes ver las Acciones. Y puedes agregar acciones que hagan validación personalizada, autenticación personalizada, como si estuvieras usando OAuth con Auth0 o algo así. Te brinda esas capacidades para agregar eso y luego ejecutar GraphQL contra eso, o crear contra eso de esa manera. Los esquemas remotos te permiten conectarte a un punto final que es GraphQL, e integrarlo e incluso establecer relaciones entre este otro punto final de GraphQL técnicamente no relacionado y establecer correlaciones entre él, como relaciones como vimos, que se genera automáticamente a partir de la base de datos a la que está directamente apuntando. Con los esquemas remotos, puedes apuntar a esos lugares y básicamente incorporar todo tipo de otras API de GraphQL y centralizarlas para proporcionar un punto de referencia de origen único para tus desarrolladores o escritores de informes o lo que sea para acceder y tener todas esas relaciones correlativas y todo lo que necesitan y deben tener para simplificar la vida a medida que desarrollan desde este punto singular. Así que eso va mucho más allá de simplemente el crud, ¿verdad? En cuanto a las aplicaciones móviles orientadas al cliente, sí, definitivamente lo usaría para eso. Puedes configurar permisos basados en roles, autorización, todo tipo de cosas ahí.

Capacidades y Consejos de Postgres

Short description:

Postgres ofrece capacidades extendidas y puede escalarse horizontalmente. Los campos JSON en Postgres se pueden inferir como cadenas a menos que se especifique lo contrario. Los tipos en Postgres se mapean correctamente en Hasura. Si un tipo no está disponible, se puede inferir tal cual. Se proporciona una lista de consejos generales relacionados con las consultas de GraphQL y la perspectiva de la base de datos. Estos consejos incluyen minimizar las uniones, usar 'exists' en lugar de 'in' para verificar la existencia de datos, usar tipos de datos apropiados y crear índices en columnas selectivamente según los patrones de consulta y la cardinalidad.

Básicamente, lo que está disponible en Postgres se extiende más allá de eso y a medida que agregamos bases de datos como MySQL, SQL Server, que sucedió bastante pronto, esos permisos también se mapearán correctamente a través de para que puedas tener todas esas capacidades que necesitas, especialmente en escenarios más complejos y extraños para asegurarte de tener los permisos correctos y roles y otras cosas así para el software del cliente.

Otras cosas que tenemos, básicamente puedes escalar esto horizontalmente, así que para sitios web grandes orientados al cliente o aplicaciones móviles para las que necesitarías capacidades de alto rendimiento, también tenemos opciones para eso. Si utilizaras algunas de las opciones de alto rendimiento para Postgres, simplemente apuntas a esa opción de alto rendimiento y listo, estás listo para comenzar. Como creo que Citus y algunas de las otras, o algunas de las opciones de RDS grandes dentro de Amazon incluso.

Quiero decir, supongo que los tipos de los campos JSON en Postgres a través de Hasura. Ok, voy a hacerte una pregunta porque no estoy seguro del contexto exacto. Entonces, ¿qué era? Teníamos acción, y esto es JSON, ¿verdad? Entonces también puedes usar JSON-B, ¿verdad? Y creo que eso agrega más contexto para algunos escenarios. En cuanto a la tipificación y cosas así. Pero si solo usas JSON, creo que hay. No recuerdo exactamente qué hemos hecho en el pasado específicamente para eso. Para llevar los tipos JSON a través de ese objeto JSON. Estoy tratando de pensar cómo lo hace PostgreSQL incluso. Si lo hace. Sí, eso es un poco complicado. Porque de lo contrario, quiero decir, como probablemente sepas, cuando tienes JSON, si solo obtienes el JSON, y no hay algo para inferir los tipos dentro del propio JSON, generalmente son solo cadenas, ¿verdad? Si tuvieras un arreglo, sería un arreglo de cadenas, a menos que se especifique. A menos que puedas encontrar alguna forma de inferir que es un entero o algo así. Así que creo que tendrías que hacer eso de la misma manera que lo inferirías si solo obtuvieras JSON que no conocieras. Esa es una buena pregunta. Tendría que verificar eso y ver específicamente cuál es el detalle al respecto. Porque no estoy seguro en este momento. En algún lugar de ahí, hay algo sin embargo. Porque sé que los tipos se mapean correctamente, por lo que todo lo que está en Postgres debería estar disponible de alguna manera, forma o manera. Si no está disponible para ti, infiere los tipos tal cual, y si Postgres lo hace, entonces Hasura en algún momento podrá hacerlo si aún no lo hace.

Una cosa más, justo aquí al final, por supuesto que recuerdo esto justo al final. Creé una lista que quería repasar. Voy a pegarla aquí mismo. PerthTips. Estos son algo arbitrarios, no relacionados específicamente con el esquema, sino en general. De alguna manera se relacionan con el esquema, pero nuevamente, en general. Veamos aquí, pegar sin formato. ¿Puedo hacer eso? Sí, ahí está. Aquí hay algunas que he estado recopilando en las últimas semanas. Que están más relacionadas con cosas que anoto específicamente y que ayudan específicamente al lado de las consultas de GraphQL, desde la perspectiva de la base de datos.

Uno, minimizar las uniones, mencioné eso. Usar 'exists' en lugar de 'in' para verificar la existencia de datos. Me he encontrado con ese escenario varias veces. Eso es prácticamente sinónimo de cualquier cosa que vayas a ejecutar ANSI SQL en contra. Entonces SQL Server, Postgres, etc., eso ayuda. Siento que es un poco tonto mencionarlo, pero usar el tipo de datos apropiado para una cosa, si es un tipo de datos específico. Sí, los incluiré. Eso es una buena idea, probablemente. O en hypertech. Voy a volver, eso es raro. Además, mencioné que puedes crear índices en columnas en la base de datos. Sí, puedes hacerlo. Sin embargo, eso no significa que obtengas un impulso de rendimiento si creas un índice para cada columna. Dependiendo de cómo la base de datos haga los índices, que generalmente es similar entre bases de datos relacionales, quieres elegir una, dos o tal vez tres, como máximo, columnas con las que vas a hacer consultas dentro de la cláusula WHERE de obviamente tu GraphQL o tu SQL, a medida que se mapea. Quieres que esa cláusula WHERE se ejecute en columnas de índice, idealmente. Pero si estás haciendo cláusulas WHERE contra un montón de columnas diferentes, entonces es un poco difícil elegir y seleccionar. Quieres elegir las columnas que tendrán la mayor cardinalidad distintiva.

Optimización de Índices y Uso de Esquemas

Short description:

Los índices pueden ser problemáticos si hay redundancia. La desnormalización de datos mediante la combinación de columnas en una sola tabla puede ayudar, pero sacrifica la cardinalidad distinta. Apache Cassandra funciona de manera diferente al modelo relacional y ofrece lecturas rápidas con escalabilidad horizontal. Los esquemas en las bases de datos proporcionan una forma de organizar y optimizar el rendimiento. Actúan como un espacio de nombres para agrupar tablas por dominio empresarial. Otros bases de datos como SQL Server y Oracle tienen opciones similares. ¿Alguna otra pregunta? Estaré disponible durante los próximos minutos. ¡Gracias por asistir!

Eso es una cosa, si hay mucha redundancia, los índices pueden ser problemáticos. Así que realmente tienes que probar y error a través de eso y familiarizarte más con cómo la database optimiza y mejora la ejecución de las consultas y los escaneos. También mencioné la desnormalización de los datos, que consiste en tomar la clave primaria y extranjera estándar y combinar varias columnas en una sola tabla, eso puede ayudar. Pero, por supuesto, pierdes tu cardinalidad distinta, y luego debes considerar qué columnas indexar y cuántas cosas debes tener juntas o no debes tener juntas debido a la redundancia dentro de la tabla.

Esto es algo, sin embargo, si tienes un servidor que utiliza Apache Cassandra y ejecutas un GraphQL encima de eso, Apache Cassandra funciona de manera muy diferente en cómo hacer esto. Tienes una estructura de tabla, pero es de columnas y almacenada, y tus cláusulas WHERE solo se pueden hacer contra una o dos columnas, en general, a la vez. Pero literalmente puedes tener petabytes de datos en una tabla y obtener consultas oportunas contra eso debido a la escalabilidad horizontal de Apache Cassandra, por ejemplo. Pero nuevamente, como estaba diciendo, eso es muy diferente, una base de datos muy diferente al modelo relacional, pero te brinda esa capacidad de generación de informes que no se puede comparar porque las lecturas son tan rápidas.

Veamos aquí, oh sí, los esquemas, en algunas de las bases de datos, parece que el esquema no está, hay un poco de redundancia. Entonces está el esquema del modelo de la database, y luego está la característica de esquema. En Postgres, puedes nombrar un esquema y luego poner tablas dentro del esquema. Está el design de esquema, donde todas las tablas están relacionadas entre sí, pero luego está el esquema, casi como si fuera un espacio de nombres en el que puedes organizar tablas. Entonces tienes mi esquema.nombreTabla cada vez que escribes una consulta. Poner cosas en esquemas ayuda a organizar, pero también puede ayudarte a optimizar necesidades específicas de rendimiento o algo así, y a separar cosas por dominio empresarial u otras necesidades. SQL Server tiene opciones como esa, al igual que Oracle, etc. No siempre se llama esquema, pero es como un elemento de espaciado de nombres dentro de la database para poder agrupar tablas. No cambia realmente la tabla en sí de ninguna manera, solo la organiza en un espacio de nombres donde se divide en una estructura organizativa de dominio.

Muy bien, sí. ¿Alguna otra pregunta? Estaré aquí durante los próximos cinco minutos y más, al menos. Voy a compartir estas diapositivas rápidamente, y las publicaré en Discord ahora mismo. Así que si tienes más preguntas, no dudes en hacerlas. Responderé todo lo que pueda. Si no, te ayudaré a encontrar una respuesta. Mientras tanto, si tienes alguna pregunta o quieres que te responda algo, mientras tanto, voy a compartir esto rápidamente y te lo enviaré. Así que gracias por asistir, espero que haya sido útil, y nuevamente, ya sabes, sígueme, sigue el Twitch de Hasura, etc., lee el blog, échale un vistazo, hay mucho más que estamos produciendo y produciremos, y mucho más específicamente sobre cómo conectar el esquema de la database y el modelado del design teniendo en cuenta cómo hacerlo bien con GraphQL. Para hacer el desarrollo más rápido, más fácil, más robusto y capaz a medida que lo haces. Así que nuevamente, gracias, voy a dejar de compartir mi pantalla, enviarte esos enlaces y estaré en el chat. Así que gracias de nuevo a todos, ¡saludos!

Watch more workshops on topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
Remix Conf Europe 2022Remix Conf Europe 2022
195 min
How to Solve Real-World Problems with Remix
Featured Workshop
- Errors? How to render and log your server and client errorsa - When to return errors vs throwb - Setup logging service like Sentry, LogRocket, and Bugsnag- Forms? How to validate and handle multi-page formsa - Use zod to validate form data in your actionb - Step through multi-page forms without losing data- Stuck? How to patch bugs or missing features in Remix so you can move ona - Use patch-package to quickly fix your Remix installb - Show tool for managing multiple patches and cherry-pick open PRs- Users? How to handle multi-tenant apps with Prismaa - Determine tenant by host or by userb - Multiple database or single database/multiple schemasc - Ensures tenant data always separate from others
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
GraphQL Galaxy 2022GraphQL Galaxy 2022
16 min
Step aside resolvers: a new approach to GraphQL execution
Though GraphQL is declarative, resolvers operate field-by-field, layer-by-layer, often resulting in unnecessary work for your business logic even when using techniques such as DataLoader. In this talk, Benjie will introduce his vision for a new general-purpose GraphQL execution strategy whose holistic approach could lead to significant efficiency and scalability gains for all GraphQL APIs.