Masterclass de GraphQL Medley para construir aplicaciones nativas de la nube con una base de datos SQL distribuida de código abierto

Bienvenidos a todos. Mi nombre es Eric Pratt. Hoy vamos a repasar nuestro Masterclass de GraphQL. Comenzaremos con SQL Distribuido, Yugabyte y algunos Servidores GraphQL populares. Como dije, mi nombre es Eric Pratt. Soy un ingeniero de soluciones senior aquí en Yugibyte en el equipo de cloud. Anteriormente, fui ingeniero de soporte premium en Datastats. Tengo a otros dos compañeros conmigo y les permitiré que se presenten.

Hola a todos, mi nombre es Nikhil. Soy uno de los ingenieros en el equipo de ecosistema. Construimos integraciones con herramientas populares para desarrolladores como GraphQL, Spring Framework, y otros proyectos nativos de la cloud. Si tienen alguna pregunta sobre las integraciones con SQL distribuido y GraphQL. Pueden contactarnos en nuestro Slack. Eso es lo que hacemos a diario en nuestros esfuerzos de ingeniería. Antes de esto, estuve en Ubuntu. Fui arquitecto senior de datos allí, construyendo soluciones nativas de la cloud. Gracias, Brad.

Hola a todos. Mi nombre es Marco Rejcic. También soy un ingeniero de soluciones aquí en Ubite. Anteriormente, trabajé en ingeniería de soluciones en Oracle, enfocado tanto en tecnologías de la cloud como en tecnologías locales. Estoy emocionado de hablarles hoy. Como mencionó Nikhil, somos muy activos en nuestro canal de Slack de Community. Así que si pueden descargar Ubite localmente o usar la cloud o lo que sea, si tienen alguna pregunta, no duden en encontrarnos allí. Esta es nuestra agenda del masterclass. Les daremos una breve introducción, comenzando con las bases de datos de SQL distribuido y GraphQL. Haremos una breve descripción de nuestra base de datos de código abierto, nuestra oferta de código abierto para Ubite. Y luego haremos algunas sesiones prácticas para implementar esto. Marco y Asura harán una aplicación de encuestas en tiempo real. Yo haré una aplicación de publicaciones sociales con Prisma y Ubite. Y finalmente, Nico hará una aplicación de exploración espacial, que creo que es bastante genial, con la plataforma Apollo y Ubite. Al final de todo eso, si tenemos tiempo, repasaremos cómo optimizar el rendimiento de las consultas de GraphQL con SQL distribuido y algunos consejos y trucos que hemos descubierto mientras trabajamos con clientes durante el último año aproximadamente.

Comenzando con GraphQL, tenemos tu aplicación, tenemos tu servidor GraphQL, nuestra base de datos. Tenemos capas abstractas que cubren nuestra base de datos para que puedas consultar y modificar datos a través de las construcciones de GraphQL, construir tu esquema y evolucionar los modelos de dominio. Podemos evolucionar la API sin versionar, lo cual creo que es bastante bueno. Y luego tienes paginación y filtrado integrados. Llamémoslo fuentes de datos dispares y finalmente soporte para eventos.

Entonces, GraphQL, es solo un lenguaje de consulta para tu API, construyes tus consultas, puedes obtener exactamente lo que necesitas. Puedes combinar varios recursos en una sola solicitud. Es bastante robusto. Y como dijimos anteriormente, puedes evolucionar tu API sin versionar y admite sistemas basados en eventos. Aquí tenemos un ejemplo de una consulta. Si están familiarizados con GraphQL, esto debería ser bastante familiar. Y luego, ya sabes, tiene tus API REST genéricas. Por lo tanto, tus GET, POST, admite todos esos. Aquí hay algunos ejemplos que tenemos sobre cómo funcionan con una respuesta particular. Y luego, para GraphQL, tenemos nuestras formas de recuperar datos, ¿verdad? Que son nuestras publicaciones. Puedes ver la solicitud allí. Aquí está la consulta que ejecutaríamos en este lado. Entonces, digamos que queremos obtener el nombre del autor y los artículos de una tabla en particular, y luego tenemos esa respuesta aquí que obtendrás. Y a medida que trabajamos en muchos de estos ejemplos, o en muchos de estos talleres diferentes, recorreremos bastantes de estos, por lo que te familiarizarás con ellos para los diferentes GraphQL, Casura, Prisma y luego Apollo. Por lo tanto, podrás ver qué tiene cada uno de ellos y cómo interactúan con Lugabyte. Es bastante genial. Creo que les va a gustar.

Así que voy a cederle la palabra a Marko aquí, ya que repasaremos la base de datos SQL distribuida de código abierto y los fundamentos de Lugabyte. Antes de entrar en la parte divertida de la demostración en vivo, queríamos poner a todos al día sobre lo que estamos haciendo aquí en Lugabyte DB, por qué creemos que esto es importante para las aplicaciones nativas de la nube y qué es realmente Lugabyte DB para aquellos que no están familiarizados. Lugabyte DB es una base de datos SQL distribuida 100% de código abierto. Nuestro objetivo es convertirla en la base de datos preferida para aplicaciones nativas de la nube. Realmente estamos tratando de unir los dos mundos entre SQL tradicional y las fortalezas que esos tipos de sistemas proporcionan con las fortalezas de los sistemas NoSQL típicos. Nuestros fundadores tienen una amplia experiencia tanto con Oracle como con la implementación de Cassandra y HPASE en Facebook a mediados de la década de 2000. Y si conocen algo sobre Facebook en la década de 2000, eso es más o menos cuando tuvieron un crecimiento de usuarios increíble y realmente tuvieron que comenzar a moverse hacia sistemas NoSQL porque los sistemas de bases de datos tradicionales que estaban utilizando simplemente no podían escalar a lo que querían.

Y obviamente esto fue muy nuevo para todos los que operaban en Internet. Una vez que este tipo de crecimiento de usuarios comenzó a mostrarse realmente, los sistemas SQL no pudieron escalar a la velocidad que se necesitaba, ¿verdad? Y así, al poder seguir brindando características sólidas de SQL con nuestra compatibilidad con Postgres SQL, compatibilidad de funciones y transacciones de activos, seguridad, todos los principales factores por los que a los usuarios les gustan los sistemas SQL en primer lugar, ¿verdad? Ya sea Oracle, SQL Server, MySQL, Postgres, todos son realmente cosas importantes, ¿verdad?

Quieres características sólidas de SQL, buen rendimiento, seguridad sólida y cumplimiento de activos e integridad de datos. Las desventajas de esos tipos de sistemas es que, aunque hay cierta resiliencia y alta disponibilidad, la mayoría de ellas son complementos. Tienes la capacidad de escalar horizontalmente, pero tienes que usar fragmentación manual, ¿verdad? No es una característica principal de la base de datos y no se creó como algo importante, ¿verdad? Y luego, las distribuciones geográficas típicamente requerirán que tengas instancias separadas de tu base de datos para poder lograr eso.

Entonces, poder aprovechar los beneficios del mundo NoSQL, donde estas tres cosas realmente son algo en lo que esos sistemas son buenos, ¿verdad? Tienes un clúster que se ejecuta en múltiples nodos donde la alta disponibilidad puede ser atendida si uno de esos nodos se cae, tienes otros nodos que pueden asumir ese tráfico. Puedes escalar horizontalmente, ¿verdad? Esa es la pieza clave para esos sistemas y por qué se construyeron en primer lugar, escalar lecturas y escrituras, y luego la distribución geográfica. Entonces, la desventaja de los sistemas NoSQL, obviamente, es esa frase NoSQL, donde, aunque algunos de estos sistemas continúan agregando características de SQL a medida que pasa el tiempo, no tienen compatibilidad completa con SQL, todavía les faltan muchas características que se utilizan en las aplicaciones hoy en día, no tienen integridad de datos ni la capacidad de ejecutar transacciones multinodo y asegurarse de que sean compatibles con ACID. Entonces, realmente uniendo esos dos mundos juntos, asegurándose de que tengas características sólidas de SQL, integridad de datos, pero al mismo tiempo tienes incorporada la escalabilidad horizontal y la capacidad de ejecutar tu base de datos en cualquier nube o en tu propio centro de datos privado junto con diferentes regiones en todo el mundo a medida que creces como empresa.

La primera verdadera, ya sabes, encrucijada en la que nos encontramos fue, si vamos a diseñar la base de datos SQL distribuida perfecta, qué rutas queremos seguir, en qué base de datos queremos enfocarnos y utilizarla como inspiración para nuestra capa de consulta. Y lo que decidimos hacer es elegir PostgresSQL. Vimos mucha popularidad. Nos encantó la comunidad. Como muestra esta visualización en el lado izquierdo aquí, desde 2013 hasta donde estamos hoy, y esta visualización se corta en 2019, 2020, pero incluso hasta finales de 2021, vemos que la popularidad de Postgres sigue creciendo más que algunos de los otros sistemas NoSQL que han sido extremadamente populares en los últimos cinco, diez años también, ¿verdad? Así que realmente queríamos poder construir, seguir construyendo sobre eso. Lo que hicimos fue reutilizar la capa de consulta de Postgres, similar al enfoque que tomó Aurora, ¿verdad? Aurora te permite reutilizar tus aplicaciones de MySQL y Postgres sin muchos cambios, al igual que tu ByteDB si vienes del extremo de Postgres. Y eso es un poco diferente a lo que hizo Spanner, ¿verdad? Google Spanner fue una de las primeras bases de datos SQL distribuidas, pero su enfoque fue, vamos a construir una nueva sintaxis. Y el problema con el que se encontraron es que muchas de nuestras características de RDBMS, muchas características de SQL que los usuarios siguen buscando. Y realmente vimos que Amazon Aurora se benefició de eso a medida que pasaba el tiempo. Y Aurora hoy es mucho más popular que Google Spanner. Vimos que Google Spanner en el último mes lanzó más funcionalidades de Postgres SQL porque creo que han notado que eso va a ser algo importante que van a tener que introducir. Entonces, ByteDB combina estas dos cosas con el lado de Aurora y la capa de consulta. Tomamos su enfoque donde dijimos, queremos que los usuarios tengan la menor fricción posible al venir a ByteDB. Queremos asegurarnos de tener todas las características de SQL que proporciona Postgres. Queremos tener la capacidad de que los usuarios sigan utilizando los mismos controladores, etc., para hacer la menor cantidad de cambios necesarios para ejecutarse en ByteDB en lugar de desarrollar una nueva sintaxis SQL, en lugar de reescribir Postgres u otra base de datos de código abierto en un lenguaje diferente, ¿verdad?

La segunda pieza con YugabyteDB es la capa de almacenamiento, ¿verdad? La capa de consulta, tomamos el enfoque de Aurora, la capa de almacenamiento, tomamos realmente el enfoque de Google Spanner porque queríamos tanto la escalabilidad como la alta disponibilidad. Si sabes algo sobre Amazon Aurora, sabes que aunque escala muy bien las lecturas, la escalabilidad no es tan buena. Así que usando Google Spanner y el consenso Raft, podemos agregar lentamente más nodos a tu clúster hasta que lo necesites, ¿verdad?

Y solo para profundizar en el conjunto de características de RDBMS, esto es lo que se admite hoy en YugabyteDB a partir de la versión 2.9, puedes ver una lista completa en nuestra documentación también. Cosas como procedimientos almacenados, disparadores, seguridad a nivel de roles, tipos definidos por el usuario, etc., verás que no muchas bases de datos NoSQL, si alguna, NewSQL, así como todos los sistemas SQL distribuidos, no tendrán eso porque es casi imposible hacerlo sin reutilizar el código SQL de Postgres. Entonces, si estás usando alguno de estos hoy, ten la seguridad de que también puedes usarlos con YugabyteDB si decides hacer esa transición.

Ahora, para profundizar en la parte de escalabilidad. Aquí a la izquierda, esto es lo que has visto durante años, tu típica, tenemos un servidor único de base de datos y los clientes llegan, todos nuestros datos están en un solo nodo. Si queremos escalar para poder manejar más tráfico de clientes, estamos un poco limitados. Dependiendo de dónde esté tu cuello de botella en el almacenamiento o si es la CPU o si es la RAM, realmente todo lo que puedes hacer es aumentar el tamaño de tu instancia, escalar verticalmente. Y eventualmente, llegas a este punto de cruce donde se vuelve demasiado caro, ¿verdad? O tal vez las limitaciones físicas están ahí. Estás confiando en los fabricantes de estos servidores que eligen las relaciones entre CPU y RAM, ¿verdad? Y a veces eso es lo que te hace pensar, bueno, ahora tengo que empezar a fragmentar, ¿verdad? Bueno, hasta este punto, habrías tenido que fragmentar manualmente si estás usando MySQL, Oracle, tienen la capacidad de fragmentar, pero no hacen fragmentación automática como lo hace YugabyteDB, tienes que fragmentar manualmente tus datos en un clúster y tienes que administrar todo eso. Cada vez que hay cambios, tendrás que hacer esos cambios en los fragmentos mismos y fragmentarlo manualmente a la aplicación, y esto lleva mucho tiempo. Si eres alguien que está haciendo esto hoy o lo ha hecho en el pasado, o incluso solo ha oído hablar de ello, lleva mucho tiempo y también requiere mucha experiencia. Por lo tanto, el objetivo de YugabyteDB era eliminar esto del usuario y asegurarse de que la base de datos misma pudiera hacerlo automáticamente.

Entonces, cada vez que creas una base de datos en YugabyteDB, mira aquí a la derecha, dividimos esos datos en fragmentos y luego distribuimos esos fragmentos en todos los nodos de tu clúster. La parte interesante de esto es que ahora cada uno de estos nodos actuará como el nodo maestro, aceptando el tráfico del cliente, teniendo su propia CPU y RAM que puede atender ese tráfico. Cada vez que necesites escalar, aún puedes escalar verticalmente si lo deseas, ¿verdad?, pasar de dos núcleos a cuatro núcleos, ocho, 16, 32, etc., o simplemente puedes agregar más nodos al clúster. Y estos nodos pueden estar en la misma región, pueden estar en diferentes regiones, somos muy flexibles cuando se trata del tipo de topología que tienes. La parte clave es que todos estos nodos son idénticos, ¿verdad?, cada nodo tiene su propia capa de consulta de Postgres, tiene su propia capa de almacenamiento de DocumentDB que se ejecuta en el nodo de YugabyteDB dentro de un solo clúster.

Entonces, si miramos a un usuario en su teléfono celular, si tienes una aplicación móvil o es una aplicación web que utiliza GraphQL conectado a algo como Hasura GraphQL Engine, y luego Hasura se comunica con el motor de YugabyteDB, se comunica con esa capa de consulta que es compatible con Postgres, como verás cuando hagamos la demostración de Hasura, estaremos utilizando el Conector de Postgres en sí. No hay un conector especial de YugabyteDB, estamos utilizando el mismo exacto. Y luego eso se comunica con los datos, ¿verdad? Conectando a cualquier nodo, YugabyteDB almacenará en caché las diferentes ubicaciones de los fragmentos y podrá dirigir el tráfico hacia donde sea necesario, y luego puedes agregar o eliminar nodos en cualquier momento sin tiempo de inactividad. Eso es diferente a cómo tendrías que hacerlo con sistemas tradicionales, ¿verdad? Digamos que tenías una aplicación monolítica y una base de datos de un solo servidor, tendrías una aplicación conectada a GraphQL, conectada al servidor GraphQL, que golpea esa instancia de Postgres de un solo nodo, en este ejemplo.

Ahora, si vemos cómo se verá con YugabyteDB y GraphQL, como ves hoy, te divides en microservicios, cada uno utiliza APIs de GraphQL, conectándose al mismo clúster. A medida que construyes más microservicios y más APIs, puedes golpear el mismo clúster y agregar nodos a ese clúster, ¿verdad? Entonces no estás limitado a un solo nodo. Si comienzas con un clúster de tres nodos, puedes hacer crecer eso a un clúster de seis nodos o un clúster de nueve nodos, etc. Incluso si estás ejecutando, muchas veces en nuestras conversaciones, los usuarios crearán microservicios para su código de aplicación y dividirán su código de aplicación masiva en diferentes secciones. Y a veces todavía lo están ejecutando en un solo nodo de base de datos, ya sea Postgres, MySQL, Oracle. No importa realmente, porque al mismo tiempo todos ellos son, es el mismo tipo de sistema, ¿verdad? No escala tan fácilmente. Entonces, una parte clave de cualquier tipo de esfuerzo de modernización para tus aplicaciones será la base de datos. Porque realmente lo que estamos haciendo es que si continúas ejecutándolo en una instancia de un solo nodo, eventualmente te encontrarás con otro cuello de botella. Porque ese es un beneficio que YugibyteDB proporciona.

Y hay diferentes topologías con cualquier clúster de YugibyteDB. Cada clúster de YugibyteDB tiene un mínimo de tres nodos. Entonces, si asumimos que cada una de estas pequeñas visualizaciones es un solo nodo, puedes ejecutarlo en diferentes zonas de disponibilidad. Bien, zona de disponibilidad uno, zona de disponibilidad dos, zona de disponibilidad tres. Tus datos se distribuyen en estos tres nodos que se ejecutan en tres zonas de disponibilidad diferentes, y se replican de forma síncrona y utilizando el consenso RAF para asegurar la integridad de los datos entre ellos. Entonces tienes consistencia entre zonas, pero obviamente no tienes la ventaja de los rellenos regionales. Ahí es donde entra en juego la topología regional. Si deseas redundancia a nivel de región, querrás tener tus nodos en tres regiones diferentes en lugar de tres zonas de disponibilidad diferentes. Técnicamente, también pueden ser tres zonas de disponibilidad diferentes. Pero estarán en tres regiones diferentes, ¿verdad? Entonces, ahí está la clave. Estamos ampliando la distancia que queremos proteger.

Y luego la última es la multi-nube. Si deseas ejecutar en AWS, GCP y Azure, y deseas tener X cantidad de nodos en cada uno, también puedes hacerlo. Y eso obviamente lo lleva a otro nivel, ¿verdad? Donde si algo tuviera un nuevo proveedor de nube en una región en particular, tienes otros proveedores de nube que se asegurarán de que tu clúster siga funcionando. Y estas nubes también pueden ser un centro de datos privado. Entonces, esto no necesariamente tiene que ser una nube pública como AWS. Si tienes tu propio centro de datos, puedes tener un nodo en tu propio centro de datos y luego otros nodos que estén tal vez en nubes públicas. Una de las áreas clave de conversación que tenemos con los usuarios es a medida que se expanden a nivel mundial, ¿cómo llegamos a nuestros usuarios con una latencia más baja en estas nuevas regiones en las que estamos lanzando nuestra aplicación? Y para eso, eso es algo en lo que YugibyteDB es realmente bueno, donde te permite escalar y agregar nodos a nuevas regiones según sea necesario. Y puedes lograr esto de dos formas diferentes. Una de ellas es mediante la replicación síncrona y la idea de la partición a nivel geográfico, donde asignas filas específicas a regiones específicas. Particionamos una columna en particular que te permite seleccionar diferentes variables que te permiten elegir, bueno, si llega una fila y la columna geográfica es EE. UU., se asignará automáticamente esa fila a Estados Unidos. Si es la UE, irá a la UE. Si es Asia, irá a Asia. ¿Verdad? Entonces, eso es algo que, cuando surge mucho, cuando hablas de cumplimiento de datos, especialmente con el cumplimiento de la UE y el GDPR, casi siempre necesitamos asegurarnos de que, bueno, los datos de la UE se queden en la UE. Pero al mismo tiempo, si quisieras, podrías consultar en las diferentes regiones, pero los datos se almacenan en esa región en particular. YugabyteDB también tiene el concepto de replicación asíncrona. Entonces, si deseas tener dos clústeres separados sincronizados con replicación asíncrona en lugar de replicación síncrona, eso también es algo que podemos hacer. Y cuando hemos visto a los usuarios lograr eso para una baja latencia en diferentes regiones también. Al combinar Yugabyte Cloud y otros servicios diferentes, digamos, por ejemplo, Hasura Cloud, realmente hemos visto a los desarrolladores comenzar a adoptar este tipo de arquitectura donde no tienen que lidiar con la infraestructura. No tienen que ir a la línea de comandos y ejecutar diferentes scripts y diferentes tipos de comandos para implementar estas diferentes tecnologías. Estas tecnologías son completamente administradas para ellos por las personas que las construyeron en primer lugar. Y al usarlas juntas, realmente obtienes una pila GraphQL totalmente administrada. Y eso es lo que vamos a mostrarte hoy en la parte de Hasura.

Elimina la necesidad de tener que instalar y administrar las cosas tú mismo. Simplemente haces clic en un par de botones a través de una interfaz de usuario y hace ese trabajo por ti. Y luego, con la pieza de Yugo agregada, tienes la ventaja de escalar linealmente a medida que crece tu tráfico, ¿verdad? Simplemente puedes agregar nodos a tu clúster y puedes agregar esos nodos, nuevamente, como hablamos, pero con diferentes proveedores de nube, diferentes regiones, etc.

Entonces, eso es solo un breve saludo del equipo de Yugo by, dándoles una idea de lo que es Yugo by DB a alto nivel. Obviamente, nos encantaría continuar esta conversación para ustedes. Si tienen alguna pregunta, no duden en seguirlas haciendo en el chat, cualquiera de nosotros que no esté presentando intentará responderlas para ustedes. Y seguiremos desde allí.

Entonces, ahora pasemos a la parte divertida, ¿verdad? Comenzando con Hasura, lo que vamos a hacer es mostrarte rápidamente cómo usar el GraphQL Counsel. Y volver al motor GraphQL para interactuar con Yugo by DB y su compatibilidad con Postgres. Entonces, los pasos que vamos a seguir, vamos a crear una instancia de Hasura en la nube, vamos a crear una instancia de Yugo by DB en la nube y luego vamos a configurar Hasura para comunicarse con esa instancia, probarla, hacer los cambios necesarios en el esquema y la aplicación para usar esa instancia de Hasura en la nube. Y luego vamos a ejecutar la aplicación y mostrarte qué puedes hacer con ella.

La aplicación de hoy en la que vamos a trabajar se llama aplicación de votación en tiempo real. Está construida con React, va a ser impulsada por Hasura en la nube para la parte del motor GraphQL y luego en el backend va a estar Yugo by DB. Vamos a mostrarte cómo puedes emitir votos en la encuesta y ver los resultados en tiempo real. Crearemos una base de datos y te mostraremos cómo existen los datos en ella también. Así que será divertido.

Lo primero que vamos a hacer, y lo pondré en el chat aquí, es Yugo by Hasura cloud workshops, ese será el repositorio que usaremos hoy. Menciona algunos requisitos previos, algunos requisitos técnicos. Vamos a pasar por todo esto contigo. Reitera la aplicación en la que vamos a trabajar. Lo que vamos a usar hoy para la sesión práctica es este documento aquí. Y vamos a ir pasando lentamente por estos pasos juntos. Entonces, lo primero, crear una instancia de Yugo by DB en la nube, crear una instancia de Hasura en la nube, asegurarse de tener acceso a la red. Ese es el primer paso. Así que primero vamos a ir a Hasura. Si vas a Hasura.io/cloud, podremos comenzar. Ya he creado mi cuenta de Hasura. Es muy rápido. Puedes iniciar sesión con tus credenciales de Google Cloud, eso es lo que hice. Y puedes crear un proyecto. Nivel gratuito. De acuerdo. Y, por supuesto, si quieres usar uno de pago, puedes hacerlo, estoy usando el nivel gratuito, porque quiero mostrarte cómo puedes usar el nivel gratuito en Hasura y Yugo by DB, no tienes que pagar nada y jugar con algunas de estas diferentes aplicaciones. Cambia el código para que se parezca un poco más a lo que ustedes quieren hacer. Voy a cambiar esto a Yugo Byte DB demo. Vamos a guardar eso. De acuerdo. Y luego una de las cosas que vamos a necesitar aquí, vamos a ir y vamos a guardar una copia de esto porque lo necesitaremos más adelante. Así que voy a guardar, ya tengo mi clúster creado. Así que voy a agregar eso. Y luego lo último que necesitamos aquí es este secreto de administrador. Así que vamos a copiar eso aquí también. Eso es todo en el lado de Hasura. Muy rápido para crear una cuenta y crear un proyecto. Ahora, muy rápidamente. Vamos a hacerlo en el lado de Yugo Byte DB. Si vas a cloud.yugobyte.com, podrás iniciar sesión en tu cuenta si ya tienes una. Si no, puedes hacer un registro y te llevará a esta página. Marko, ¿puedes aumentar un poco el tamaño de tu pantalla? Sí. ¿Cómo se ve eso? ¿Está mejor? Sí, está bien. Entonces, lo típico, información personal para registrarse. No requerimos que ingreses ninguna tarjeta de crédito para ingresar. Así que puedes ir y crear una cuenta, comenzar a usar Yugo by Cloud, y luego te presentarán nuestra sección de primeros pasos. Aquí, ya he creado un clúster porque lleva un poco de tiempo. Así que eso ya está listo para mí. Obviamente, ustedes no tendrán ningún clúster, pero podrán ir y hacer clic en Primeros pasos, crear un clúster de nivel gratuito y podrán crear su clúster gratuito de Yugo by Cloud. Tenemos un límite de uno por cuenta, así que verás aquí que no puedo crear uno. Pero voy a ir y simplemente guiarlos a través de la creación de un clúster pago. Pero obviamente, no tienes que hacer eso. Es el mismo proceso. Entonces, lo que verás aquí es que voy a ir y hacer esto, este ya está creado en AWS US-West1, así que lo mantendré en la misma región. Haré lo mismo. Entonces aquí, lo llamaré Asura demo. No me está dejando, porque ya tengo ese nombre. Y luego voy a seguir adelante y hacer esto, US-West1. Quería tolerancia a la zona de disponibilidad, así que quería a nivel de nodo, también puedo hacer eso. Pronto, también tendremos a nivel regional. Y luego, sigue adelante y haz clic en Siguiente.

Lo primero que tendrás que hacer es descargar tus credenciales. Si deseas mantener las credenciales predeterminadas, adelante y hazlo. Si deseas agregar las tuyas propias, también puedes hacerlo. Aquí se mencionan dos API diferentes. ySQL es la API compatible con Postgres de la que hablamos un poco durante la parte de presentación. yCQL es nuestra API compatible con Cassandra, si tienes cargas de trabajo NoSQL que deseas probar. Aquí puedes usar las mismas credenciales para cada una o hacerlo de manera diferente. Depende del nivel de control que desees. De cualquier manera, deberás descargar tus credenciales antes de poder crear tu clúster.

Una vez que hayas descargado esas credenciales, cópialas para tenerlas disponibles. Asegúrate de que todo esté seguro y que nadie más tenga acceso a tus contraseñas. Luego, haz clic en crear un clúster. Como mencioné, ya tengo mi clúster configurado. Así que voy a mostrarte cómo se ve una vez que está en funcionamiento.

Verás una sección de resumen. Tenemos una idea de cuál es nuestra tolerancia a fallos. Si estás ejecutando un clúster de nodo gratuito, verás que hay un clúster de nivel gratuito. Verás que solo hay un nodo. Entonces, si deseas probar cosas como alta disponibilidad y escalabilidad horizontal, no podrás hacerlo con el clúster de nivel gratuito. Pero si tienes un caso de uso específico en mente y deseas probar algo como una prueba de concepto, puedes comunicarte conmigo o con Prad o cualquier persona del equipo de ingeniería de ventas o del equipo de ventas. Podemos ayudarte a configurar una prueba gratuita para que puedas probar un clúster UBIDB completo. Verás más información. Verás el nivel de cifrado cuando se crea, métricas clave. No tengo nada en ejecución en este momento, así que no verás nada allí. Tablas de nodos, tenemos un solo nodo, diferentes cosas que podemos hacer en el lado del rendimiento, observando las actividades que están ocurriendo y también otras configuraciones. Entonces, verás una de las cosas que se mencionan aquí es que para conectarte a este clúster, debes tener al menos una IP en la lista permitida. En este momento, no tengo ninguna. Así que vamos a crear nuestras IPs. Voy a crear una nueva. Esta será solo para mi red doméstica. Significa que si, para mi computadora portátil local, quiero usar esto, puedo hacerlo. Puedo ir y conectarme desde. Dirección IP o rango, no conozco mi IP. Así que voy a hacer clic en este botón para que lo detecte automáticamente y lo agregue allí, y luego hacer clic en Guardar. Permíteme ejecutarlo de nuevo. De acuerdo, así que va a aplicar eso. Aquí, quiero agregar otro a mi clúster de Hasura, así que déjame ir rápidamente a Acceso a la red y agregar otra dirección IP. Esta se llamará Hasura. Para conectarme desde mi Hasura. Rango de IP, voy a volver a mi proyecto de Hasura y voy a copiar esto aquí también. Y lo agregaré aquí. Como puedes ver, aquí puede ser una dirección IP específica o direcciones o un rango completo, así que he hecho ambas cosas. Mi red doméstica es un rango, para esto es una dirección IP específica porque lo sabía. Entonces, verás aquí que el verde indica que, ¡hey, esta es una lista permitida de red activa! Entonces, verás aquí que se está utilizando por este clúster en particular y mostrará todos los demás clústeres que podría estar utilizando. No puedes eliminarlo si se está utilizando activamente. Entonces, si quisiera eliminar esta lista permitida en particular, tendría que ir al clúster de Hasura y quitarlo primero y luego poder terminarlo, ¿verdad? Hasura uno, todavía no lo estoy usando, así que puedo eliminarlo aquí si es necesario. Permíteme volver aquí, ir a Configuración. También puedo ir a Enlaces rápidos, Editar lista permitida de IP y simplemente agregar esto. Entonces, puedes ver aquí las diferentes listas permitidas que creas. Es tan simple como hacer clic para activarlas o desactivarlas aquí. De acuerdo, parece que también está aplicando esa. Pronto las tendremos disponibles. Muy bien, eso se encarga del primer paso. Permíteme tomar un sorbo rápido de agua y continuaremos. Muy bien, entonces, el siguiente paso es configurar la instancia de Hasura Cloud para usar YugabyteDB Cloud. Vuelve a nuestro proyecto de Hasura y vamos a iniciar la consola. Ahora estamos en la pestaña API. Queremos ir a la pestaña Datos y luego vamos a usar la pestaña Conectar base de datos existente para que nuestra conexión funcione. El nombre de nuestra base de datos, verás aquí que ya tenemos una que debes usar llamada yugabyte-cloud-instance y te mostraré por qué necesitamos usar eso en un momento, pero simplemente cópialo y pégalo. Continuaremos usando el controlador de Postgres SQL. YugabyteDB es compatible con Postgres, por lo que podremos usar el mismo controlador exacto para conectarnos. La URL de la base de datos es el camino a seguir. Verás aquí que tienen una pequeña cadena de conexión para nosotros. Si vuelves a yugabyte-cloud-instance, en realidad tienes una cadena de conexión disponible para tu conexión a Hasura. Si haces clic en conectar, habrá tres métodos de conexión diferentes. Uno es con la Shell de Cloud, ¿verdad? Y lo usaremos un poco para verificar una vez que hayamos migrado los datos. Puedes hacer una Shell de Cloud donde descargas los clientes de Yugibyte DB y los usas desde tu servidor remoto, o puedes conectarlo directamente desde aquí, ¿verdad? Tienes una pequeña opción de pestaña aquí para optimizar para la nube de Azure, así que vamos a hacer eso. Voy a copiar esto. Asegúrate de estar usando la API correcta y luego voy a hacer los cambios necesarios que necesito para hacer esto.

Verás que SSL está autenticado si no deseas usar SSL. Bueno, el modo SSL se establece en requerido de todos modos así que lo uses o no se utilizará el modo SSL requerido. Pero vamos a ir aquí. Esto es Yugibyte, ¿verdad? Entonces, una cosa que quiero asegurarme es que en realidad no estoy usando la base de datos de Yugibyte. Solo dice las mejores prácticas. Quiero crear una nueva database específicamente para mi aplicación o específicamente para esta demostración que estoy ejecutando. Así que voy a iniciar el Esquema en la Nube, y se abrirá una nueva pestaña que te permite acceder directamente a tu database. Una vez que aparezca esto, podré ingresar mi contraseña y podré echar un vistazo y demostrarles que no hay tablas allí y que estamos comenzando desde cero. Muy bien, estamos en la base de datos Yugibyte-DB. Vamos a verificar. No hay nada aquí. Veamos una lista de todas nuestras bases de datos. Tenemos varias bases de datos del sistema que se crean por defecto. Así que voy a crear la database Sero. Y de esa manera, cuando comencemos nuestra migración utilizando la función de migración GraphQL, podremos conectarnos a la base de datos Sero y eso es lo que creará todas nuestras tablas. Muy bien, cuando volvamos aquí, podremos hacer eso. Permíteme... Como puedes ver, ¿verdad? Todos los atajos relacionados con PostgreSQL o todas las consultas compatibles con PostgreSQL, puedes ejecutarlas en Yugibyte. Por lo tanto, no es necesario aprender un nuevo lenguaje SQL. Todos los conocimientos existentes de PostgreSQL se pueden utilizar también con Yugibyte.

Sí, exactamente. También me gustaría señalar que la database predeterminada que se crea es Yugibyte, pero eso es propiedad de PostgreSQL. Entonces, por razones de security, te damos un usuario administrador y ese usuario administrador tiene funcionalidad limitada para la database Yugibyte predeterminada. Por lo tanto, querrás crear tu propia database para tus aplicaciones. De esa manera puedes crear esquemas y otras cosas así. O específicamente crea su propio esquema para una cosa en particular. Así que asegúrate, y mi demo hará lo mismo, pero solo quería señalar eso mientras estamos viendo esto aquí. Sí, gracias, Brad. Y eso es específico de la cloud también. Si estás ejecutando Yugibyte DB de código abierto, no tendrás problemas para iniciar sesión como Yugibyte o como PostgreSQL si así lo deseas. Nuevamente, creo que desde las best practices, generalmente es mejor crear tu propia database de todos modos, pero solo quería darles una advertencia de que si estás usando la cloud e inicias sesión como usuario de Yugibyte, no podrás realizar ciertas acciones como crear un esquema. Por ejemplo, en la database Yugibyte, tendrás que crear una nueva database y luego crear un nuevo esquema.

Ok, creo que por eso, ahora tenemos todo bien, así que ahora vamos a volver aquí. Vamos a... Ponemos Hasura aquí porque esa es la database a la que queremos conectarnos. 5433, este es el puerto al que quieres ir para Yugibyte DB, ¿verdad? Aquí tenemos el nombre de host. También puedes encontrar el nombre de host yendo a Configuración y luego a Nombre de host aquí. Y Eric, vi que alguien levantó la mano. No sé si quieres, no sé si lo han publicado en el chat o en Discord, pero si quieren echar un vistazo. Mira aquí. Creo que es Mary. ¿Alguna pregunta? Adelante y pregunte. Oh, okay. Olvídalo, fue un error. Falsa alarma. Muy bien, entonces, okay. Así que ahora estamos de vuelta aquí. Vamos a continuar. Y luego vamos a... Actualicemos eso. No creé mi propia contraseña, como puedes ver. Usé la que proporcionó Yugibyte. Esto es realmente cómo se ve. Es tu cadena de conexión típica de PostgreSQL. La diferencia aquí es que vamos a tener el nombre de host de tu Cloud de Yugibyte así como el puerto específico de Yugibyte, que es 5433. Estamos llamando a nuestra database y el resto. Así que vamos a copiar todo eso. Vamos a ir al grupo de conexiones. No al grupo de conexiones, sino a la conexión de database y Hasura, y luego vamos a conectar nuestra database. Y en breve deberíamos tener esto. Ahí vamos, en un abrir y cerrar de ojos. Ahora tenemos esto aquí. Vamos a ver nuestra database. Y verás que no tenemos ninguna tabla. No tenemos ningún tipo de otras relaciones, ¿verdad? Eso nos lleva al siguiente paso donde vamos a querer clonar el repositorio del masterclass. Ya está disponible para ti aquí mismo. Ahora puedes copiar y pegar aquí mismo, todo el contenido, ¿verdad? Si quieres que realmente pase por el repositorio también, puedes hacer eso. Puedes hacer clic en código, copiarlo aquí mismo. Así que vamos a clonarlo. Verás aquí que no tengo nada realmente sucediendo. Voy a clonar esto. Ahora está aquí. Voy a entrar en el directorio, y verás todos nuestros diferentes, sabes, diferentes, esto es en realidad lo que estamos leyendo en el navegador, y luego todas las diferentes partes de ese repositorio que estábamos viendo antes. Muy bien. Así que vamos a hacer eso. Si aún no lo has hecho, instala la CLI de Hasura. Si estás usando algo como homebrew para hacerlo típicamente, puedes hacer brew install Hasura-CLI, y lo descargará para ti. Entonces, por ahora, vamos a ir al directorio de Hasura. Vamos a tener que editar nuestro archivo de configuración. Entonces, cuando estemos ejecutando la aplicación, queremos asegurarnos de que la migración pueda conectarse a nuestra database. Así que vamos a echar un vistazo a eso. Vamos a ir a Hasura y config.yml, y hay dos áreas principales que tendremos que editar. Tendremos que editar el punto final para nuestra aplicación, y luego vamos a tener que editar el secreto de administrador para asegurarnos de tener la autenticidad correcta, ¿verdad? Ya hemos guardado eso aquí en Hasura. Podemos aumentar un poco el tamaño de fuente del ID. Sí. Sí, esto está bien. ¿Esto está bien? Sí. De acuerdo. Así que déjame copiar esto, lo moveré aquí. Probablemente no necesitemos tanto espacio.

De acuerdo, así que voy a proceder y cambiar esto. En lugar de Hasura.ybdemo, ahora será ubitedb-demo o cualquier convención de nomenclatura que hayas utilizado. Vamos a cambiar esto también a MySecret, y luego vamos a guardar esto. Vamos a salir de eso.

La siguiente parte es aplicar la migración en sí. Ya hemos actualizado el punto final y el secreto de administrador, ahora vamos a ejecutar la migración. Así que vamos a hacer eso aquí. Vamos a ejecutar esto. Genial, migración aplicada. Ahora podremos ver que hay algunas tablas no rastreadas. Genial. Así que aquí tenemos las tablas para esa aplicación en particular que vamos a necesitar. ¿Qué significa tener una tabla no rastreada? Simplemente significa que las tablas o vistas no están expuestas a través de la API de GraphQL. Así que vamos a exponerlas. Vamos a rastrear esas tablas primero. Y una vez que eso esté completado, vamos a rastrear cualquier otra cosa que venga con ellas, ¿verdad? Si echas un vistazo aquí, verás que queremos rastrear todas las diferentes tablas y las relaciones para ellas. Y luego tendremos que agregar otra relación nosotros mismos para mostrarte cómo se ve eso si necesitas hacerlo manualmente y no tienes la capacidad de hacerlo como lo hicimos hoy. ¿De acuerdo? Parece que todas nuestras tablas y vistas han sido rastreadas, ahora queremos rastrear las diferentes relaciones de clave externa. Vamos a hacer eso también. Esperaremos un minuto. Genial, se han creado las relaciones. Vamos a refrescar una vez más. Y asegurémonos de que haya realmente algunas relaciones que existan aquí. Así que vamos a echar un vistazo a la tabla de opciones, relaciones, y parece que ya hay algunas relaciones creadas. Vamos a crear nuestra propia relación ahora sobre algunas de las que ya se han creado para nosotros. Así que vamos a ir a los resultados de la encuesta, ¿de acuerdo? Después de esto, queremos crear una relación, una relación de matriz para los resultados de la encuesta, el nombre de la relación es opción en la tabla de resultados de la encuesta haciendo referencia al ID de la encuesta en la tabla de opciones dot ID de la encuesta. Muy bien. Así que voy a ir a los resultados de la encuesta. Voy a ir a relaciones, configurar manualmente. Vamos a hacer una relación de matriz. La llamaremos opción, en singular, no en plural. Sí, está bien. Esquema público, referencia. En realidad, queremos hacer referencia a la tabla de opciones haciendo referencia al ID de la encuesta para cada una. De acuerdo. Vamos a guardar eso. Genial. Otro paso completado.

Paso seis, verificar la configuración. Ve a la Consola de GraphQL de Hasura, ejecuta la mutación y las consultas de GraphQL presentes en el archivo GraphQL JS. Así que déjame abrir esto. Hay varias consultas diferentes que podemos ejecutar. Bien, vamos a ejecutar esta para demostrarlo. Y a medida que te desplazas por esto, estás utilizando suscripciones para ejecutar esta aplicación. Y algunas cosas diferentes dependiendo de lo que alguien vote en la aplicación de encuestas y luego, obviamente, hacer esos cambios por ti. Así que vamos a añadir eso. Vamos a ir a la pestaña API aquí. Vuelve a la pestaña API y vamos a ejecutar esa consulta de ejemplo solo para asegurarnos de que estamos obteniendo lo que necesitamos. Y ahí lo tenemos. Así que estamos ejecutando la consulta aquí. Y vemos los resultados aquí, el ID de la encuesta en sí, cuál es la pregunta, cuál es tu favorito de los frameworks. Y luego diferentes IDs para las opciones que tienes, React, Vue, VanillaJS, Angular y Ruby. Así que echemos un vistazo rápidamente también en el lado de YugabyteDB, en cómo se ve eso. Así que déjame abrir esta terminal en la nube, esta vez conectándome a la base de datos de Hasura. Vamos a confirmar eso. Y luego déjame obtener mi contraseña. Y luego, lo que vamos a hacer ahí es simplemente usar SQL para mostrarte que las diferentes tablas que están ahí tendrán el mismo tipo de resultados. De acuerdo, entramos aquí, estamos conectados a Hasura. Hacemos backslash D, veremos la lista de relaciones que ahora tenemos. Así que todas estas diferentes aquí, puedes verlas si echas un vistazo a la pestaña data. Así que solo estamos confirmando en el lado de Hasura y en el lado de YugabyteDB que vemos lo que queremos ver. Si hago select star from, por ejemplo, opción, verás que nuestras opciones se corresponden con las diferentes opciones que ves si ejecuto esto de nuevo, ¿verdad? Todas estas, si echo un vistazo a lo que es la encuesta real, hagámoslo con esta, verás que es la misma pregunta. Si quisiéramos agregar más encuestas, podríamos. ¿De acuerdo? Si queremos ver qué usuarios hay, solo ha habido un usuario hasta ahora, ¿verdad? Y luego tenemos varios votos ya realizados cuando se creó, la idea de ello, el usuario, ¿verdad? Solo usamos el usuario administrador para todos esos. Verás que ya se han realizado algunos votos Si realmente quiero ver los resultados de la encuesta, y podrás ver esto una vez que mostremos lo visual, ¿verdad? Verás que ya se han realizado uno, dos, cuatro, siete, ocho votos. Así que vamos a continuar, y ahora que hemos hecho eso, pasaremos al siguiente paso, que es el último paso antes de ejecutar la aplicación. Vamos a editar otro archivo para asegurarnos de que pueda conectarse a la aplicación.

Esta vez podemos conectarnos a nuestra instancia de Hasura. Así que vamos a abrir ese archivo en particular. Estará en la carpeta source, Apollo.js. Y las dos áreas principales que vamos a cambiar son el nombre de host, aquí mismo, y luego el secreto de Hasura nuevamente. Para el nombre de host, asegúrese de no incluir HTTPS. Cometí ese error yo mismo. Causará algunos problemas en la interfaz de usuario. Así que vamos a copiar todo excepto la parte de HTTPS. Vamos a pegarlo aquí en el nombre de host. Así es como se verá el nuestro. Volvamos, copiemos el secreto. Aquí está, bien. Vamos a guardar eso. Hemos terminado con eso.

Ahora vamos a ver qué sigue. Bien, ya hemos hecho todo esto, y ahora simplemente vamos a la raíz del repositorio y ejecutamos estos comandos. Así que vamos a hacer eso. Raíz del repositorio, ls k, npm install. Ejecutemos esto rápidamente. Y debería terminar en un segundo. Bien. Luego asegurémonos de que se abra aquí. Genial. Voy a abrirlo. Así que si voy a localhost, mostrará la aplicación. Así que aquí vemos las mismas opciones que vimos cuando estábamos verificando nuestro testing tanto del lado de UBITE como del lado del servidor. Veremos que ya hemos realizado algunas votaciones. Dos, tres, uno, uno, uno. Así que eso suma ocho, al igual que en nuestra demostración de UBITE DB. Y luego verás las diferentes opciones de carga. Así que si hago clic en React, votemos por React. Veremos que ahora también hay tres. Si quiero ver cómo se ven algunas de estas piezas de GraphQL, también podemos hacerlo a través de la interfaz de Hasura. Así que si vuelvo aquí, puedo ejecutar select start from poll results. Mostrará. Así que ahora verás que para React, ahora hay tres. A medida que hacemos cambios aquí en vivo, podremos no solo actualizar la interfaz de usuario, sino que también se actualizará la base de datos inmediatamente todo a través de Hasura. Así que rápidamente, ahora son cuatro. Detrás de escena, en realidad está utilizando las suscripciones de Hasura. Así que la tercera consulta en la parte inferior solo muestra eso. Sí, esa, correcta. Como qué tipo de performance podrías ver con, digamos, Postgres, verás el mismo tipo de performance con Yugabyte. Más adelante, veremos cómo pudimos poner a prueba las suscripciones de GraphQL para escalarlo a un millón de registros. Entonces, y escalar fácilmente la base de datos. Puedes comenzar pequeño, y cuando tengas más usuarios que usen tu API, puedes escalar la base de datos y aumentar la escala de las suscripciones también. En última instancia, eso es lo que queríamos mostrar en esto. Sí, y vamos a profundizar un poco, asegúrate de quedarte en Zoom porque lo veremos un poco más adelante. Así que acabamos de terminar la parte de Hasura. Ahora vamos a jugar con Prisma, y luego también con Apollo. Entonces, Eric, te lo paso a ti. Nikhil, Eric, ¿hay algo más que crean que sería bueno mostrar mientras ya estoy aquí o algo en lo que quieran comentar? Sí, esto fue genial, Marco. Creo que hemos cubierto todo lo que queríamos cubrir. Vamos a preguntar a los asistentes si tienen alguna pregunta. Así que si tienen alguna pregunta sobre cómo comenzar con Hasura y Yugabyte, no duden en hacernos cualquier pregunta. Si pueden, quiero decir, si están siguiendo, si tienen problemas para seguir, quiero decir, para hacer que la aplicación funcione, también nos lo pueden hacer saber. Sí, y si prefieren preguntarnos por Slack, hay muchos usuarios de Yugabyte DB, así como administradores como yo, Nikhil, Eric. Si tienen alguna pregunta, estaremos encantados de tener esas conversaciones aquí también. En esta parte, vamos a trabajar con Hasura. Así que voy a salir de aquí. Acabamos de pasar por esta parte de Hasura, pero a continuación vamos a trabajar con Prisma, disculpen. Así que pueden ver, vamos a comenzar con Prisma. Esto es, vamos a crear una pequeña instancia de Prisma, crear la instancia de Cloud de Yugabyte. Espero que ya lo tengan funcionando. Tal vez si no lo lograron completamente durante Hasura, esperemos que ahora esté funcionando correctamente. Y este será el conjunto de herramientas que vamos a utilizar. Tendremos un servidor Apollo. Tendrás el GraphQL Nexus, un cliente de Prisma y Prisma Migrate.

En esta parte, vamos a crear nuestra aplicación Prisma y realizar una migración en vivo de los datos. También crearemos una nueva tabla de base de datos en tiempo real. Trabajaremos con el servidor Apollo y configuraremos la cadena de URL para conectarnos a nuestra instancia de Postgres o YugoByte. Después de la instalación, abriremos el archivo schema.prisma y modificaremos la URL de Postgres. Por último, crearemos y poblaremos la base de datos.

Para comenzar, vamos a crear nuestra aplicación Prisma y realizar una migración en vivo de los datos. También crearemos una nueva tabla de base de datos en tiempo real. Trabajaremos con el servidor Apollo y configuraremos la cadena de URL para conectarnos a nuestra instancia de Postgres o YugoByte. Después de la instalación, abriremos el archivo schema.prisma y modificaremos la URL de Postgres. Por último, crearemos y poblaremos la base de datos.

Para comenzar, abramos una sesión de terminal. Aquí es donde vamos a trabajar. Si aún no lo has hecho, crea una carpeta específica. He creado esta carpeta llamada 'Prisma Workshop' porque vamos a descargar el ejemplo e instalar todas las dependencias rápidamente. También tengo configurado un clúster de YugoByte Cloud. Es de pago y consta de tres nodos. Puedes verlo aquí en la región oeste de Estados Unidos. Aún no tengo tablas, pero vamos a crearlas rápidamente. Instalemos todo. Asegurémonos de aumentar un poco el tamaño de fuente en el navegador. En la carpeta 'GraphQL', ya tengo todo lo necesario para Prisma. Ingresamos a esa carpeta y ejecutamos 'npm install' para instalar las dependencias. Ahora vamos a permitir que se conecte a nuestra instancia de Postgres o YugoByte utilizando la API de Postgres. Abramos el archivo 'schema.prisma' en nuestro editor. Aquí es donde crearemos todo. Tenemos la configuración de la fuente de datos 'DB' y vamos a establecer la URL de Postgres. Simplemente copiamos la URL y la pegamos en la cadena de URL. Guardamos los cambios y volvemos a la terminal. Ahora podemos crear y poblar la base de datos.

Entonces, simplemente podemos ejecutar este comando, npx prisma migrate dev, y esto creará, conectará a nuestra database y creará algunas tablas. Así que lo ejecutaremos. Ahora esto lleva un poco de tiempo. Me di cuenta de que para Prisma lleva un poco más de tiempo en conectarse, definitivamente lleva un poco más. Pero cuando volvemos, podemos ver esas, ya podemos ver que tenemos esa nueva tabla, una nueva tabla comenzada, y a medida que se sincroniza, se crearán las demás. Así que llevará unos minutos, no unos minutos, sino un par de minutos para sincronizar, crear todo. No estoy seguro de por qué Prisma tarda un poco, aún no he investigado mucho al respecto, pero lleva un poco más de tiempo de lo que creo que lleva para Hisura. Pero eventualmente, una vez que se ejecute esto, esto. Ahí vamos, ahora está aplicando el script de migración. Así que, ejecutando las declaraciones SQL. Veamos algunas tablas más. Bien, ahora tenemos nuestro perfil de usuario. ¿Qué tal la tabla de perfil? Eso es interesante. Eso es divertido. Eso es divertido. Bien, todo está sincronizado ahora. Como podemos ver, en realidad tenemos muchas tablas adicionales Estoy bastante sorprendido. Bueno, parece que lo limpié. Eso fue extraño. No voy a mentir, lo he hecho varias veces. Parece que quería crear algunas tablas adicionales que no había hecho antes, así que me disculpo por eso pero fue interesante. Me encantan las demostraciones en vivo. Muy bien, a partir de ahí ahora podemos tener otro archivo llamado seed.ts. Así que si lo miramos rápidamente, lo abriremos y veremos que tenemos solo algunos data. Entonces puedes construir los datos de usuario y podemos tener este archivo con algunos data y se insertará esos data en la database. Así que podemos ejecutar nuestro MPXprismdbseed y se cargará esos data para nosotros. Sí, puedes ver eso, muy bien, se crearon esos usuarios. Así que si volvemos y entramos en nuestra Cloud Shell, volvamos a la tabla de Prisma. Realmente debería mantener esto abierto más tiempo, pero déjalo abierto. Debería dejarse abierto. Bien. Disculpas por la demora. A veces llevará un poco de tiempo. Crea su propia instancia para la shell. Um. ¿Alguna pregunta hasta ahora, todos pueden seguir adelante y hacer esto también? No dudes en preguntar, puedo. Sí, responder cualquier pregunta mientras esperamos aquí. Actualicemos, veamos para el viaje. Intentemos de nuevo y volvamos allí. Ahí vamos. OK, podríamos vincular la tabla de usuario. usuario, y podemos ver que tenemos tres usuarios, sus identificadores y listos para seguir adelante. Ahora vamos a iniciar el servidor GraphQL, todo lo que tenemos que hacer es ejecutar el NPM run dev. Y se iniciará. Bien, eso se inicia rápido y bien. Entonces solo tenemos que ir a localhost, puerto cuatro mil y tendremos nuestro Apollo. Así que simplemente haz clic aquí y ahora tenemos nuestro bien, tenemos nuestra interfaz de usuario y podemos interactuar con nuestra database de manera fácil. Si estás familiarizado con graphico, podemos comenzar a construir nuestras consultas aquí. Así que ya tengo algunas consultas configuradas con las que podemos comenzar. Así que vamos a copiar esta. Y pero en lugar de eso, vamos a crear yo. Crearemos mi nombre y diremos, be proud at ebike.com. Así que si ejecutamos esta consulta, boom, se crea mi usuario. Podemos comprobarlo. Ahí estoy. Si queremos ver, si hacemos clic aquí abajo, hay algunas consultas más que podemos ejecutar. Así que vamos a crear un nuevo borrador y decir, esto es para publicaciones sociales, ¿verdad? Así que vamos a crear este borrador. Fácil y rápido. Ejecutamos eso. Ahora hemos creado un borrador para este usuario Alice. Ella está en el slack de Prisma, ¿verdad? Una vez que esté ahí, podemos volver y ahora podemos recibir, podemos ir y decir, ok, vamos a obtener ese borrador y ver, ya sabes, si realmente, si realmente se creó. Así que fácil y rápido. Boom. Aquí hay otro borrador. Aquí está el borrador que fue creado por Alice. Muy bien. Sin problemas. Así que todo esto funciona bastante bien. Podemos ejecutar esto.

Entonces. Correcto. Aquí tenemos algunos, um, aquí están todas las publicaciones publicadas por sus autores. Podemos ver que prácticamente solo Alice, um, también creó una. Um, como puedes ver, no tenemos que revisar todas ellas, pero si quieres, eres más que bienvenido a hacerlo. Hay muchos ejemplos diferentes aquí de, uh, diferentes, uh, consultas gráficas que puedes ejecutar. Podemos crear publicaciones, podemos eliminar publicaciones. Podemos hacer lo que queramos. Um, pero la parte principal, una de las cosas que me pareció realmente genial de este Prisma fue evolucionar esta aplicación. Así que esta sección aquí, evolucionando la aplicación, um, vamos a migrar la base de datos y actualizaremos el código de la aplicación. Um, así que lo hacemos todo en vivo. Es bastante genial. Así que creamos una nueva tabla llamada Perfil. Esto permitirá a los usuarios de esta aplicación en particular crear un perfil que pueden vincular a su, um, ya sabes, a su ID de usuario. Y a medida que hacemos esto, todo es en vivo. Así que en realidad no apagamos nada. Um, es bastante genial. Así que podemos comenzar esta sección aquí. Um, Veré si hay alguna pregunta hasta ahora, alguien, algo en Discord? Si no, simplemente seguiremos avanzando.

Lo que haremos ahora es agregar otro shell aquí. Vamos a nuestro masterclass. Así que estamos aquí y lo que vamos a hacer es abrir nuestro esquema prisma. Lo tenemos aquí. Voy a deshacerme de eso. Aquí está el esquema. Correcto. Entonces lo que vamos a hacer es agregar otra. Columna a nuestra tabla de perfil. Y esto estará vinculado a nuestro perfil. Luego, la columna estará vinculada a nuestra tabla de perfil. Así que vamos aquí y lo vamos a copiar. Esto es lo que estamos agregando. Así que es fácil para ustedes. Muy bien. Ahora tenemos nuestra nueva tabla, ¿verdad? Nuestro perfil, nuestro ID y la biografía que vamos a hacer. El usuario. Nuestro nombre de clase, ¿verdad? Nuestro perfil, su ID y la biografía que vamos a hacer el usuario y el ID del usuario. Esto estará vinculado de vuelta a nuestra tabla de usuario donde se agregará esa sección de perfil. Así que ahora podemos migrar esto y se creará en tiempo real nuestra nueva tabla. Así que ejecutemos esto aquí. De acuerdo. Y esto lleva un poco de tiempo, ¿verdad? Va a ser similar a lo que hicimos antes, donde creamos nuestras tablas iniciales. Va a crear esa tabla de perfil. Miremos aquí. De acuerdo. Ahora podemos ver que nuestro perfil está haciendo esta parte de migración. A medida que prepara todo y luego se limpia a sí mismo. Esto lleva un tiempo. Una vez que termine, veremos que se sincronizará de nuevo y podrás ver si ya está aquí, así que aún no está del todo. Una vez que se sincronice, estaremos listos para continuar. Esta es la única parte que encontré interesante. Lleva un poco de tiempo. Como dije, no he investigado mucho sobre la parte de Prisma, pero lleva un poco de tiempo. Podemos ver, si vamos a Performance, que hay un poco de latencia al crearlos, así que más. Pero en realidad no utilizamos mucha CPU mientras realizamos estas operaciones, así que no es muy intenso. Estos nodos no son particularmente grandes, ¿verdad? Solo tenemos cuatro CPU. Tenemos cuatro CPU y dos gigas de RAM en cada uno, así que no son particularmente grandes, pero está bien. Solo estamos creando esos todavía. Está bien. Esto nos da tiempo para preguntas si alguien las tiene, nuevamente. En la siguiente parte, actualizaremos el código de la aplicación. Esa parte es un poco más compleja. Tenemos que hacer varios cambios en el código para poder interactuar con nuestra nueva tabla, poder hacer consultas y verla, así que si tienen alguna pregunta sobre esa parte, lo haré un poco más despacio.

De acuerdo, parece que terminamos de nuevo. Deberíamos tener nuestra tabla. ¿No lo hizo? No se veía bien. Bueno, lo reiniciaremos. Reiniciar... reiniciarlo. Veamos si lo retomamos. No creó nuestra... No actualizó nuestra tabla. Denme un segundo aquí. Veamos el perfil. ¿Está ahí? ¿Qué hay? Tampoco está aquí. Veamos. Tal vez la CLI se agotó y ahora se inició. Sí. De acuerdo. Solo estoy. ¿Podría ser el problema? No es el archivo correcto. Bueno, eso es culpa mía. De acuerdo, hagámoslo de nuevo con el archivo correcto, ¿qué tal eso? ¿Dónde está el mío? ¿Qué tal entonces? Espero estar mejorando. No. De acuerdo, eso es. Bien, intentemos ejecutar esto una vez más. Así que, migrar eso, agregar el perfil. Eso es, en realidad sé qué hice mal. No guardé el archivo, así que es mi culpa. Lo siento, chicos. Así que, lo haremos de nuevo. Y mientras eso sucede, echaremos un vistazo a la siguiente parte mientras se ejecuta. Entonces, en el archivo fuente del esquema TS, lo recorreremos. Este es el código de la aplicación. Vamos a crear nuestro tipo de objeto perfil. Esto nos permitirá interactuar con nuestra tabla de perfil. Y luego aquí, vamos a ajustar el tipo de objeto usuario, ¿verdad? Nuestra tabla de usuario, y vamos a agregar ese campo perfil. También tenemos que incluirlo en nuestra sección de creación de esquema. Y luego, también tendremos que crear la mutación gráfica. Esto nos permite hacer mutaciones en esas tablas. Y así, lo recorreremos. No hay muchos cambios de código locos, pero tendremos que hacer algunos. Y así, una cosa que noté en los ejemplos de Prisma, si vamos a... Saqué esto de Prisma, sus ejemplos. En esta parte en particular, tuve que cambiar un poco para que al menos funcionara para mí. Y podemos hablar de eso más tarde. Está pasando y creando esas tablas. Entonces, la parte interesante, pensé, fue, como viste con Sera, se crea bastante rápido. En Prisma lleva un poco de tiempo aquí. Así que, disculpen la demora. Pero por favor, hagan preguntas ahora. Si alguien está tratando de ponerse al día, probablemente tenga tiempo ahora. Echemos un vistazo aquí. De acuerdo. Ahora finalmente estamos aplicando la migración. Está agregando ese perfil. Y ahora podemos ver nuestra tabla de perfil. Ahora podemos ver que está sincronizada. No hemos detenido la aplicación esta vez. Todavía está en ejecución, todavía podemos interactuar. Así que está bien. Ahora que eso está hecho, ahora pasaremos a hacer la migración del código de la aplicación mientras todo sigue en ejecución. Así que podemos deshacernos de este chico, podemos volver aquí y abriremos nuestro archivo Schema TS. Entonces, si volvemos al masterclass de YouCube, vamos a GraphQL, vamos a source, encontramos nuestro código de la aplicación, y queremos, ¿verdad?, nuestro archivo schema.ts, archivo de TypeScript. Aquí está. ¿Todos pueden verlo bien? Eliminaré el chat. De acuerdo, un poco más grande para que sepamos lo que estamos haciendo aquí. De acuerdo, este es todo el código de la aplicación. Y si bajamos hasta el tipo de usuario, lo que haremos aquí es hacer un poco de espacio para nuestro perfil, copiar esta parte aquí, y lo agregaremos a nuestro código. Y luego, nos desharemos de esta parte. De acuerdo, ahora hemos agregado nuestro tipo de objeto perfil. Esto nos permitirá interactuar con nuestra tabla de perfil.

Y luego, vamos a agregar esta sección en particular aquí a la tabla de usuario para poder interactuar con la nueva columna que creamos en nuestra tabla de usuarios. Entonces, esto se pone un poco interesante. Solo tienes que limpiarlo un poco. No del todo. Así que, voy a hacerlo un poco para tenerlo abajo. No importa realmente. Técnicamente no tienes que hacerlo, pero está bien. No es lo mejor, pero no pasaremos mucho tiempo haciéndolo bonito.

Entonces, tenemos que bajar a nuestra sección de creación de esquema aquí, así que tenemos nuestra creación de esquema y vamos a agregar nuestro perfil llamado allí. No olvides nuestra coma. Y ahora vamos a agregar nuestra gran notación de perfil GraphQL. Así que, vamos a encontrar esto. Tenemos que volver a subir en realidad. Esto va a ser, encontramos nuestra sección de rotación. Lo siento, un poco rápido aquí, pero aquí están nuestras rotaciones. Así que verás algunas de las diferentes aquí. Esto fue, puedes crear tu borrador. Aquí está cómo alternar una publicación publicada. Así que todo esto se relaciona con muchos de esos campos de mutación que vimos antes donde teníamos esa larga lista que podías hacer. Así que veamos aquí. Hagamos un poco de espacio aquí. Ahí vamos. Lo agregaremos. Solo alinéalo un poco. Ahí está, y luego nos desharemos de esto. De acuerdo. Así que déjame revisar nuestros bloques aquí. Solo quiero asegurarme de que todo esté bien. Eso se ve bien. De acuerdo. Así que voy a traer esto de vuelta. Lo que veremos aquí es que nuestra aplicación todavía está en ejecución. Así que una vez que guardemos esto, se actualizará la aplicación para que podamos usar todo de nuevo. ¿De acuerdo? Así que simplemente presionaremos comando S. Así que guardaremos esto y lo veremos aquí, aplicando todo. Y estamos listos para continuar. Si hubiera un error, lo verías aquí. Así que te mostraré rápidamente cómo se ve eso. Así que en el ejemplo de PRISMA que tienen en su sitio, estoy abriendo un problema de GitHub para eso, pero si, digamos, eliminamos esto y lo guardamos con control. Ahora tenemos un error. Así que puedes ver que te dirá cuál es el problema en vivo. Este sería un error que encontré usando el código de ejemplo. Y para resolver eso, agregamos esto. Así que eso se encarga de eso. No sé qué tan familiarizado está todo el mundo con el código de la aplicación y cosas así. No entraré en detalles per se de eso, pero eso nos permite superar y seguir trabajando con nuestra aplicación.

Ahora que eso está bien, podemos bajar aquí y ahora podemos probar la nueva mutación. Podemos decir, está bien, para Mahmoud, él va a tener esta biografía, o cualquier persona, podemos, este es solo el ejemplo que tenemos aquí. Podemos agregar esto y ejecutarlo. y ahora este usuario ahora tiene un perfil. Así que si volvemos y, digamos, empezamos desde el usuario, podemos ver, ¿verdad?, lo tenemos aquí. Tiene un ID de tres. Ahora podemos mirar nuestra tabla de perfil. Y ahí está. Ves, este es el ID de la fila en nuestra tabla de perfil. Pero podemos ver que está vinculado a nuestro usuario, ID de tres, así que esas tablas están vinculadas. Hicimos todo esto en vivo sin tener que detener nuestro servidor de aplicaciones. Creo que eso es bastante genial. Al menos en el lado de Prisma. Y eso resume este masterclass en particular. Puedes volver al masterclass de Prisma real. Tienen muchas más mutaciones y cosas con las que puedes jugar. Pero puedes revisar la documentación de Prisma. Este ejemplo, como dije, que hicimos aquí, lo tienes en el chat. Puedes jugar con él si quieres. Por favor, crea tu UVI Cloud. Recorre esto. Podemos ver como nuestras consultas en vivo de performance. No se están ejecutando en este momento, pero podemos ir y, digamos, creemos otro para mí. Y echemos un vistazo.

Esta parte es bastante interesante. Personalmente, me gusta el snowboard. No puedo esperar a que comience la temporada. Vivo en Denver. Si están interesados. Y estoy esperando la nieve. Todavía no hay nieve. Así que voy a sacar esto y veremos si podemos capturar esa consulta en vivo. Se ejecuta bastante rápido. Eso se ejecutó demasiado rápido, así que no lo capturé a tiempo, pero está funcionando. Hay una sección de mascotas para consultas lentas. Hablaremos un poco de esto más adelante en nuestra optimización de consultas. Pero podemos ver nuestro perfil. Eso está relacionado con mi ID de usuario en nuestra tabla de usuarios. Creo que es un ejemplo bastante interesante. Ahora se lo voy a pasar a Nikhil aquí. Y él va a mostrar un ejemplo más interesante. Esto es lo que me gusta de esto es que estamos construyendo sobre esto y verán que él va a trabajar con Apollo y tener un ejemplo realmente genial. Esperaremos un minuto. Y comenzaremos con Apollo GraphQL y Yoga by Bp. Este es nuestro último de los servidores GraphQL que queríamos mostrarles hoy con Yugabyte DB. Como pueden ver, ¿verdad?, como todo lo que estábamos haciendo es seguir los pasos que estaban usando con cualquier otra base de datos, como por ejemplo Postgres, MongoDB, no Mongo, Postgres o MySQL. Eso seguirá funcionando con Yugabyte DB también. Y si, por ejemplo, ya están usando Postgres y están buscando usar Yugabyte DB como o si están buscando usar un sistema altamente escalable porque han alcanzado algunas de las limitaciones de un solo nodo de Postgres, entonces Yugabyte DB puede ser una buena opción para casos de uso en los que se necesita escalabilidad y un entorno siempre activo donde no se pueden tener interrupciones. Algunas de las topologías de implementación que Marco explicó al principio, ¿verdad? Eso nos ayudará mucho a construir una arquitectura siempre activa. Y en este taller solo queríamos mostrar lo sencillo que es para cualquiera comenzar con Yugabyte, ya sea la versión de código abierto o la versión en la nube. Solo son unos pocos cambios de configuración y todos los conceptos de GraphQL con los que están familiarizados seguirán funcionando con Yugabyte DB. De acuerdo, suena bien. Comencemos con Apollo GraphQL. La plataforma Apollo proporciona algunas cosas más en comparación con lo que proporciona Prisma y también es similar a cómo es el motor GraphQL de Hasura, pero una diferencia es que en la plataforma Apollo, tienes mucho más control sobre cómo implementas tu servidor GraphQL. Estas son las cuatro categorías diferentes en las que la plataforma Apollo se enfoca, te permite construir tu gráfico. Desde la perspectiva de Apollo, cuando decimos gráfico, no es más que construir las consultas GraphQL o los propios tipos de GraphQL. Obviamente, puedes construir tu esquema y todo eso y escribir todos los resolvers que se requieren para las consultas y las mutaciones utilizando las API del servidor Apollo, y obviamente la mayoría de las aplicaciones de Node.js utilizan el cliente Apollo como cliente Apollo para crear los servidores GraphQL del backend. No importa si es Prisma, Hasura o Apollo en sí, siempre se utilizará algún cliente Apollo para obtener la información del servidor. Y otra cosa que proporciona la plataforma Apollo es Apollo Studio, que no es más que una interfaz de usuario donde puedes ir y ver y revisar todos los tipos y ejecutar algunas consultas GraphQL. Además de eso, Apollo Studio tiene la capacidad de monitorear tus servidores Apollo también. Cosas como el rendimiento, la latencia y cosas así. Todo eso se puede monitorear con Apollo Studio. Y una cosa importante es que Apollo Studio es gratuito, solo tienes que crear una cuenta en Apollo Studio. Y si quieres usar algunas características de análisis más avanzadas que Apollo Studio proporciona para identificar patrones de interrupción y cosas así. Entonces tendrás que optar por las versiones más avanzadas de pago de Apollo Studio. De lo contrario, todo lo que tenemos actualmente seguirá funcionando con la versión gratuita de Apollo Studio. Y obviamente, al igual que con los demás servidores GraphQL, también puedes federar diferentes fuentes de datos ya sean diferentes bases de datos, tu lago de datos o diferentes APIs REST, o incluso si tienes APIs SOAP, todo eso se puede federar utilizando el servidor GraphQL. Al igual que con los otros dos motores GraphQL que hemos visto, incluso con el servidor Apollo, puedes conectarte fácilmente a Yugabyte DB utilizando las API del servidor Apollo. Lo que hace el servidor Apollo en segundo plano es que, como es una implementación basada en Node.js, puedes utilizar cualquier ORM de Node.js que admita. En la sesión de hoy utilizaremos SQLite. SQLite es uno de los ORMs de Node.js más populares. Por lo tanto, todo el código que escribas para instanciar y crear las operaciones actuales seguirá siendo el mismo en todas las bases de datos. Solo cambia la forma en que instancias el objeto SQLite o creas una nueva base de datos según la implementación de la base de datos. Por lo tanto, si ya tienes un servidor GraphQL que has implementado con Postgres, será muy fácil conectarlo a Yugabyte. Pero si te conectas, si estás utilizando otras bases de datos como MySQL o SQL Server, con solo unos pocos cambios de código puedes migrar tu aplicación de esas bases de datos a Yugabyte DB. Mostraremos cómo se hacen esos pasos. Como parte de este taller, veremos cómo crear una base de datos para Yugabyte DB utilizando SQLite. Y obviamente, todas las API que proporciona SQLite como buscar por uno, buscar por ID de usuario o la columna de la tabla en sí. Todo eso sigue funcionando con Yugabyte DB, la base de datos de Yugabyte. Es similar a cómo trabajamos con las otras demos o aplicaciones de taller a las que fuimos. En dos días para Apollo, construiremos una aplicación de exploración espacial. Es una aplicación futurista que puede acceder a las APIs de solo lectura que proporciona SpaceX, donde tiene una lista de todos los lanzamientos de cohetes que están realizando. Y puedes reservar un asiento en uno de sus dragones tripulados que tienen. Y obviamente, cuando haces una reserva, querrás almacenar tu información en una fuente de datos. Para eso utilizaremos Yugabyte DB para almacenar nuestra base de datos.

Tiene dos componentes. Construiremos la parte del servidor GraphQL utilizando Apollo y también hay un cliente NodeJS ReactJS que tiene cosas como ver todos los próximos lanzamientos de cohetes y agregar un lanzamiento al carrito y realizar el pago para tu perfil. Por lo tanto, veremos cómo se ve el esquema de esto, qué mutaciones necesitamos y qué consultas vamos a construir como parte de esta aplicación.

Si te desplazas un poco hacia atrás, como dije, realizaremos la sesión práctica comenzando con la construcción del esquema, consultando la fuente de datos utilizando SQLite para Yugabyte DB, luego los resolvers de consulta y los resolvers de mutación. Si comparas entre Hasura y Apollo, en Hasura todos estos aspectos son una caja negra. Una vez que rastreas tu tabla GraphQL o la tabla de la base de datos en sí, Hasura se encarga de construir todas las consultas, resolvers y resolvers de mutación detrás de escena. Si deseas un control más detallado para construir las consultas y lo que debe suceder en tus resolvers, puedes comenzar a utilizar las API del servidor Apollo donde tendrás más control sobre cómo construir los resolvers. Y obviamente intentaremos conectarnos a Apollo Studio y ejecutar algunas consultas de ejemplo. Y finalmente, una vez que tengamos el servidor en funcionamiento, ejecutaremos nuestra aplicación de interfaz de usuario del cliente que tiene la interfaz de usuario real para esta aplicación.

De acuerdo, los enlaces a las sesiones prácticas están aquí. Si haces clic en esto, navegarás a workshop.md. Obviamente hemos estado hablando de crear una instancia en Yugabyte Cloud. Incluso he creado previamente una instancia en la nube para mí para este taller. Y si alguien se acaba de unir y desea comenzar a crear un nuevo clúster, puedes ir aquí y hacer clic en agregar clúster y puedes hacer clic en la instancia gratuita de Yugabyte. Dado que ya tenemos todo, está limitado a uno por cuenta de usuario. Entonces, si ya has creado uno, no podrás crear otro más. Y todas las demás opciones que tienes para la versión de pago son similares a la versión gratuita. Puedes darle un nombre a tu clúster, seleccionar la zona de disponibilidad que desees y en qué proveedor de nube deseas ejecutarlo, todas esas cosas las puedes seleccionar aquí para simplemente... Para ahorrar algo de tiempo, ya hemos creado previamente esa instancia. Como sabes, no es que el clúster esté preaprovisionado. Crearemos máquinas virtuales y los contenedores que se requieren para ejecutar Yugabyte sobre la marcha. Por eso, lleva unos minutos configurar la máquina virtual y el contenedor. Por lo tanto, solo queríamos ahorrar ese tiempo. Ya he creado una instancia. Esta es la instancia que voy a utilizar. Como dijimos anteriormente, seguro, hay algunas cosas que querrías tener como parte de tu instancia en sí. Como las credenciales que se requieren, así como algunos de los nombres de host que tienes para conectarte a esta instancia en sí.

Genial. Con suerte, esta es la tercera vez que explicas que ahora eres un experto en cómo trabajar con instancias de Yugabyte Cloud. Una vez que hayas creado una instancia de Yugabyte Cloud, obviamente, lo siguiente que querrías hacer es configurar el equilibrador de carga para que puedas conectarte a esta instancia. Para mí, ya lo he configurado ya que ya hemos pasado por esto dos veces. Aprendí cómo agregar una nueva IP. Lo siguiente que querríamos hacer es configurar una cuenta en Apollo Studio. De acuerdo, déjame hacerlo rápidamente. Studio.apollographQL.com. Si vas aquí, navegarás al esquema de GraphQL y todas esas cosas. Puedes ir y ver una vista previa. Volveremos a esta página una vez que avancemos con la sesión práctica. Genial. Como dije, si vas a la estructura del proyecto, vamos a clonar la estructura del proyecto en primer lugar, iré a clonar en GitHub. Si estás utilizando un IDE y usas Visual Studio Code, podemos ir y crear un nuevo terminal aquí. En este nuevo terminal, puedo ir al directorio temp y decir git clone. He clonado el proyecto, navegaré hasta el proyecto. Y si ves aquí, hay algunas carpetas que hemos creado. Hay una carpeta de cliente y una carpeta de servidor y una carpeta de servidor inicial. La carpeta de servidor es en realidad el código completo. Si te sientes perezoso y no quieres seguir paso a paso para construir el servidor en sí, simplemente puedes ir y comenzar el servidor allí. Pero para el recorrido de hoy, utilizaremos el proyecto inicial del servidor. Voy a importar el proyecto inicial del servidor como parte de este repositorio. Permíteme ir y decir Abrir Carpeta. De acuerdo. Mover a servidor inicial. Como soy el autor, confío en mí mismo. Permíteme iniciar el terminal nuevamente para que podamos comenzar a trabajar en esto. De acuerdo, genial. Con suerte, has configurado tu IDE y tienes el proyecto inicial del servidor en tu IDE. Y ahora volvamos a la sesión práctica del taller. ¿Algún pregunta hasta ahora sobre la estructura de archivos del proyecto en sí? Si no, simplemente continuaré con la sesión práctica.

Genial, de acuerdo. Como expliqué, el repositorio tiene tres carpetas, el servidor inicial y el cliente en sí. Por lo tanto, lo primero que haremos como parte de esta descripción general es construir el esquema para nuestra aplicación X Center. Como expliqué, hay dos dominios que estamos abordando aquí, básicamente, esos son los dominios para los cuales queremos definir nuestros esquemas. Entonces, hay un dominio. El primer dominio son nuestros lanzadores de cohetes en sí y el segundo es el usuario que reserva un asiento en esos lanzamientos. Por eso, en nuestro esquema, deberían poder manejar cosas como obtener una lista de los próximos lanzamientos de cohetes, obtener el lanzamiento específico por su ID, iniciar sesión como usuario y reservar un lanzamiento. Y también tienes la capacidad de agregar el lanzamiento, como la reserva, al carrito, realizar el pago y cancelar el anterior. Por lo tanto, algunas de las operaciones básicas de escritura que querrías hacer con cualquier dominio. Y lo primero, como dije, es construir los tipos de GraphQL, las consultas y las mutaciones que se requieren para nuestro dominio. Si navegas a la fuente y a schema.js, verás un archivo vacío. Y lo primero que harías al construir un esquema de GraphQL es, obviamente, ya que esto es un servidor Apollo, traeremos la API del servidor Apollo para que podamos construir nuestros tipos de GraphQL.

Voy a copiar el contenido para crear nuestro servidor GraphQL. La sintaxis es bastante sencilla. Lo primero que haremos es importar las dependencias necesarias, en este caso GraphQL, y definir un conjunto de tipos. Exportaremos esa definición de tipos para que pueda ser utilizada más adelante en nuestro index.js. El siguiente paso es construir los tipos de objeto. GraphQL es un lenguaje basado en tipos muy completo, por lo que tenemos una serie de tipos definidos para lanzamientos, cohetes, usuarios, misiones y datos de viaje. Copiaremos los tipos necesarios y los colocaremos aquí.

Una vez que tengamos los tipos, lo siguiente que haremos es construir o definir las consultas de GraphQL. Para cada consulta de GraphQL que definamos, obviamente tendremos que crear los resolvers, ya que Apollo no genera resolvers automáticamente. Cuando construimos el servidor Apollo, necesitamos definir los resolvers para las consultas específicas de nuestro dominio o caso de uso empresarial. Por lo tanto, la primera consulta que queremos ejecutar es la consulta de lanzadores. Consultaremos la API de SpaceX para obtener una serie de lanzamientos y transformaremos la información obtenida de la respuesta REST en GraphQL. Para cada consulta, podemos definir qué atributos necesitamos de la respuesta REST. Eso es lo que haremos con esta consulta aquí. Definiremos una consulta y luego definiremos los atributos que necesitamos de la respuesta REST. Es así de sencillo construir los tipos de GraphQL. Como puedes ver, no es necesario escribir mucho código complicado para construir los tipos en sí. Es bastante sencillo diseñar tus propios tipos de GraphQL según las necesidades de tu aplicación.

Bien, voy a guardar esto rápidamente. No vamos a iniciar el servidor ahora porque aún no hemos conectado la fuente de datos. Primero, vamos a conectar la fuente de datos o hablar sobre la fuente de datos en sí. Como puedes ver, tenemos una carpeta llamada fuentes de datos. En nuestra fuente de datos, tenemos dos cosas sucediendo. Tenemos una fuente de datos de la API REST de SpaceX. Como dijimos, el servidor Apollo es capaz de hacer una federación entre múltiples fuentes de datos, ya sea diferentes bases de datos o API REST. En este ejemplo en particular, vamos a federar las fuentes de datos entre la respuesta de la API REST y también Gigabyte DB para almacenar la información. Por lo tanto, en nuestra primera fuente de datos, tenemos la fuente de datos de la API REST de SpaceX. Esta es publicada por SpaceX. Si vas a launch.js aquí, puedes ver cómo se escriben los reductores. Los reductores no son más que una forma de formatear la respuesta REST obtenida de la API REST y convertirla en un formato de tabla de GraphQL. Dado que es de solo lectura, no es muy interesante para nuestro caso de uso específico de la base de datos. Puedes revisar cómo se escriben los reductores para la respuesta REST. Lo que nos interesa es escribir reductores para la fuente de datos de Gigabyte DB en sí. Por lo tanto, para la fuente de datos de Gigabyte DB, como puedes imaginar, hay algunas cosas que queremos hacer en la base de datos. Lo primero es crear un usuario. Si el usuario no existe, queremos insertarlo en la base de datos. Y si ya existe, simplemente queremos obtener la información. Eso es todo. Y lo segundo es reservar viajes. Esto es como una inserción en la tabla de Gigabyte en la base de datos. La cancelación, obviamente, implica eliminar la entrada de la base de datos y obtener lanzamientos por ID de usuario. Esto es como una consulta de selección por ID de usuario que se puede hacer o una selección de lanzamientos en la tabla de usuarios. Estas son las consultas que construiremos. Antes de construir los reductores reales para estas consultas, lo primero que queremos hacer es configurar la conectividad entre nuestro servidor Apollo GraphQL y la base de datos de Yugabyte. Vamos a copiar este código y explicar qué está sucediendo en este par de líneas de código uno por uno. Primero, creamos una nueva instancia de SQLite. SQLite, como dije, es un ORM. Admite la conexión a múltiples bases de datos. En nuestro caso, utilizaremos el dialecto Postgres. Como mencionamos desde el principio, UGIDB es compatible con Postgres y, dado que estamos utilizando Yugabyte Cloud, hay algunas cosas que queremos. Queremos el nombre de host, el nombre de usuario y la contraseña que estábamos usando. Bien, ahora volvamos a mi instancia. Copiaré el nombre de host aquí. Copiaré el nombre de host. Y otra cosa es la contraseña. Tengo una contraseña en algún lugar. Déjame obtener mi contraseña.

Voy a poner mi contraseña aquí. Y la guardaré. Y otra cosa que puedes ver aquí es que nos conectaremos a través de SSL porque la instancia de Yugabyte Cloud solo se comunica a través de TLS o SSL. Y obviamente, si quieres autenticación, si quieres que tu cliente autentique el servidor, debes poder descargar el certificado raíz y configurar el certificado raíz en el bloque SSL aquí. Eso está implementado en el código completo, te mostraré cómo configurar la autenticación también. Si ves aquí, todo lo que necesitarías es descargar el certificado raíz de la instancia de Gigabyte Cloud y especificar el archivo CA. Una vez que se haya hecho el archivo CA, lo que sucederá es que el cliente de Node.js que estamos construyendo o el servidor GraphQL que estamos construyendo autenticará también el servidor, lo que significa que sabrás que te estás conectando al servidor correcto. Estás evitando todo tipo de ataques de intermediarios y ese tipo de cosas. Por ahora, como es solo una demostración, no es una aplicación lista para producción. Si estás construyendo una aplicación lista para producción, debes configurar todas estas cosas. Así de simple es configurar nuestro servidor GraphQL para usar Gigabyte DB. Y después de eso, lo que estamos haciendo es que queremos definir nuestras tablas. SQL proporciona una API llamada db.define, donde puedes definir todas tus tablas y las columnas y especificar los tipos de datos correspondientes. Creamos dos tablas, la tabla de usuarios y la tabla de viajes, que se utilizarán en nuestro index.js para iniciar el propio servidor GraphQL. Una vez que hayamos creado nuestra tienda, el siguiente paso es crear nuestros reductores de mutación. Si voy a user.js, si ves en nuestro user.js, lo primero que hago es obtener esta tienda. Quiero decir, primero, esto es solo como una fuente de datos que estamos construyendo, en nuestra fuente de datos, lo primero que usará esta fuente de datos de usuarios, puedes pasarle cualquier tienda, en nuestro caso, pasaremos una tienda de Yugabyte DB, también podrías pasar una SQLite o un MySQL o cualquiera de esas cosas. Y ahora copiemos este código que va a escribir nuestros reductores. Ok, voy a copiar los reductores. Como puedes ver, los reductores son bastante sencillos. Y lo que estoy haciendo es que hemos definido todos nuestros métodos que queríamos crear aquí. Si vas a la implementación de esto, primero estamos haciendo una comprobación de validación si hay una dirección de correo electrónico o no, si los derechos de correo electrónico son válidos, y luego vamos a usar la API de SQLite, ¿verdad? Todo lo que estamos haciendo es usar SQLite como una referencia y... consultando la tabla de usuarios, y estamos comprobando si find or create, estos son un conjunto común de API que SQLite proporciona. Si ya estás familiarizado con SQLite, sabrás lo fácil que es comenzar con eso. Entonces, este find or create, simplemente ejecutará una consulta de selección de estrella en la base de datos. Si encuentra algunos datos, simplemente los devolverá. Si no encuentra datos, luego continúa e inserta. Todas estas cosas son una caja negra para el usuario. Solo necesita estar familiarizado con las API que SQLite proporciona. Ok, vamos a guardar esto por ahora. Una vez que esto esté guardado, y el resto de las cosas son bastante sencillas. Como si estás viendo ese destroy, si quieres eliminar una entrada, simplemente usa una API de destroy. Puedes ver lo fácil que es escribir reductores. Una vez que hayamos escrito el reductor, creo que es hora de seguir adelante y comenzar la aplicación en sí. Antes de ir y comenzar nuestro servidor, veamos cómo estamos usando las tiendas y los reductores que hemos escrito, ¿verdad? Si ves aquí, lo primero que estamos diciendo es que estamos creando una tienda. Una vez que hagamos esto, esto le dirá a esta aplicación de Node.js que haga una conexión a tu otra base de datos y luego estamos creando los reductores de API de lanzamiento y API de usuario, que se pasarán al servidor Apollo. Si ves aquí, vamos a pasar las fuentes de datos y siempre hay que usarlas por el servidor Apollo para generar la API GraphQL o servir las consultas GraphQL en sí. Así de simple es. Es como en tres o cuatro pasos, puedes diseñar tus tipos GraphQL, escribir las fuentes de datos requeridas y los reductores que se requieren para tu esquema y comenzar el servidor GraphQL. Como pudiste ver, aunque hay algunos pasos que debes hacer en comparación con Hasura, aquí obtienes mucho más control. Depende de la conveniencia versus el control. Si estás tratando de hacer algo rápidamente, un prototipo o si no quieres complicar el código del backend, puedes usar Hasura. Pero si tienes mucho más control y estás escribiendo consultas complejas y quieres saber cómo se ejecutan las consultas en tu base de datos, si quieres ese tipo de control, puedes usar el servidor Apollo. Ok, voy a guardar esto. Voy a hacer npm install. Con suerte, eso es todo. Ok. npm install. Ok, déjame ver. Hubo un error tipográfico. Ok, esto lleva uno o dos minutos. ¿Alguna pregunta hasta ahora, gente? Sobre el servidor GraphQL Apollo en la consola de comandos que acabamos de hablar. Ok. Ok, hemos construido nuestra aplicación, la aplicación de Node.js, déjame seguir adelante y decir npm start. Esto debería iniciar mi servidor. Ok, genial. Como pudiste ver, hay una cosa que estoy haciendo cuando configuro mi SQLize. Como es un ORM, en mi SQLize estoy viendo dbsync force true, lo que significa que si ya existen tablas que se crearon, quiero que se eliminen las tablas y se creen nuevas tablas. Automáticamente, SQLize ORM puede eliminar las tablas y crear las nuevas tablas para nosotros. Si vuelvo aquí, ok la conexión está cerrada. Déjame, volver y abrir la terminal. Podemos ver que no hay datos. Y también podemos ir aquí y explorar nuestro Apollo Studio. Y si vamos aquí, podemos ver todos nuestros objetos y los diferentes tipos que creamos. Como pudiste ver, creamos tres mutaciones diferentes. Podemos reservar viajes, cancelar el viaje y podemos iniciar sesión en el usuario. Y obviamente podemos hacer algunas consultas, lanzamientos, conexiones de lanzamientos. Todas las bases de datos en las fuentes de datos que creas en tu código, el servidor Apollo puede enviar esa información al estudio Graphe donde puedes revisar todo.

Es muy sencillo para ti entender, como descubrir todas las consultas y mutaciones que admites en tu servidor GraphQL. Y obviamente hay algunos objetos, tipos que admitimos. Estos son los tipos que creamos. Puedes ver fácilmente lo que tiene cada uno de ellos. Profundiza en cada una de las cosas y lo que quieras crear en tu consulta GraphQL. Una vez hecho esto, parece que mi conexión también está aquí. Voy a obtener mi contraseña. Copiar esto. Si ves aquí, haré select start from users, o no debería haber ningún dato ya que creamos un nuevo conjunto de tablas. Y también diré trips. También tengo algunas tablas residuales de otra aplicación que es una aplicación de macros. Pero está bien. Como puedes ver, las nuevas tablas que creamos, ya que las eliminamos, no hay datos. Ahora lo que voy a hacer es ir al estudio Apollo. Voy a ejecutar algunas mutaciones de eso. Lo primero que quiero hacer es crear un usuario y decir que voy a hacer un kill a databyte T.P. Voy a decir, iniciar sesión de usuario. Y una vez que iniciemos sesión en el usuario, obtendremos el token de autenticación. Tomemos nota de este token de autenticación. Lo usaremos en la próxima mutación que haremos. Si volvemos a nuestro código aquí, hay dos mutaciones que estamos ejecutando. Una es el inicio de sesión real del propio usuario y la reserva de viajes para ese usuario utilizando la API GraphQL. Ya lo tengo. Como hemos creado un nuevo usuario, si entro en la base de datos en sí, puedo decir, start from users. Debería poder ver una entrada allí. Como puedes ver, creamos una nueva entrada ahora para un enlace y déjame ir por TP. Usemos mi ID de token de inicio de sesión para crear una nueva entrada de reserva. Volvamos a nuestro código. Leer documentación. Copiemos la mutación aquí. Y si vamos a las cabeceras aquí, hay una etiqueta de autorización que necesitamos en esta autorización. Ok, perfecto, ya está ahí. Voy a decir, reservar viajes. Esto debería poder reservarnos un viaje. Los viajes se reservaron correctamente y estos son los tres lanzamientos donde tengo un asiento. Esperemos que esto se haga realidad en nuestra vida, donde podamos viajar al espacio como volamos en aviones. Y tal vez todo lo que estás viendo en el futuro, serás tú quien implemente un sitio web o un portal para reservar vuelos en lanzamientos espaciales. Genial, déjame seguir adelante y ver si los datos se reflejan aquí, voy a decir desde trips. Obviamente, ¿cuáles son las tres cosas que tenemos? Se muestra aquí, increíble. Si podemos hacer lo mismo usando un cliente que vamos a tener. Creemos una nueva terminal aquí para que podamos iniciar una nueva. Voy a decir, ok, lo siento, sí. Voy a crear una nueva terminal, ok. Navegar a cliente. Reiniciemos la aplicación para que los datos se actualicen. Ok, creo que no hay más datos. Ok, perfecto. Ahora voy al cliente. El cliente está construido con React JS. Dado que este es un taller basado en el backend, no vamos a profundizar mucho en cómo se ha implementado el cliente. Es bastante sencillo. Si ves, habrá un cliente GraphQL. Cada uno de esos clientes GraphQL se utilizará para consultar el servidor que hemos creado. Si vas al servidor y al índice en sí, verás algunas de las páginas. Como puedes ver, aquí estamos usando Apollo Client para consultar la base de datos, y Apollo Client está configurado para ir a la ubicación predeterminada, donde ejecutaremos nuestro servidor. Y obviamente, todas las API que se requieren, todas las consultas que tenemos, ya están documentadas aquí. Si estás interesado en esa implementación del cliente, no dudes en ver este código. Por ahora, solo voy a hacer npm install y iniciar la aplicación. Ok. Ok. Démosle un minuto para que se complete la instalación. Déjame volver al tutorial. Ok. Increíble. Ahora diré, npm start, esto debería iniciar el cliente. Oh, lo siento. Oh, genial. Se detuvo. Oh wow, ya he iniciado sesión. Genial.

Como puedes ver, simplemente cerraré sesión y esta es la aplicación, la parte de la interfaz de usuario del cliente. Podemos seguir adelante y ver, sí, megabyte.com. Ver en inicio de sesión. Esto debería tener una entrada para mí como usuario ahora. De acuerdo. Entrada para mí. Y si voy a los lanzamientos en mi perfil, no tengo ninguna reserva, ningún viaje reservado. Iré a inicio. Este es el primer Crew-1 Falcon, es el primer cohete Falcon que SpaceX utiliza para lanzar astronautas al espacio. A todos nos encantaría estar en ese lanzamiento espacial, ¿verdad? O el lanzamiento del cohete. Me encantaría estar también en eso. Y digamos que hay entrada a los otros interesantes. De acuerdo, ¿y ahora qué? De acuerdo, hagamos clic en otro. Y digamos agregar al carrito. Voy a mi carrito. Tengo dos lanzamientos de cohetes en los que quiero estar. Diré reservar todo. Ahora, si vuelvo a mi perfil, tengo dos lanzamientos en los que estoy reservado. También podemos ver eso en los viajes. Así de simple es, amigos, comenzar con GraphQL y reservarlo o configurarlo con un SQL distribuido como Yugabyte DB. Obviamente, aquí solo queríamos mostrar lo fácil que es comenzar. Pero si tu aplicación está construida con Yugabyte DB o con GraphQL en sí, ¿cómo manejas esas situaciones? Esa es la siguiente parte de la que queríamos hablar. ¿Cómo escalas realmente tus cargas de trabajo de GraphQL? Voy a tomar 10 minutos rápidos para mostrar cómo puedes escalar tus cargas de trabajo de GraphQL utilizando Yugabyte DB. Obviamente, descubrimos lo fácil que es comenzar con todos los motores populares de GraphQL. Si hay otro motor que deseas, es tan simple como configurar, obtener las credenciales correctas y configurarlo para que funcione con Yugabyte. Y obviamente, has construido una aplicación utilizando la API de GraphQL, ¿verdad? ¿Y qué sucedería? ¿Y cuál es el cuello de botella actual que estamos viendo con nuestros clientes? Básicamente, muchas personas comienzan con PostgreSQL. Y lo que estamos viendo es que a medida que aumenta el número de consultas que van a GraphQL, que son atendidas por las API de GraphQL, el uso de recursos en la base de datos también aumenta, ¿verdad? Algunos casos de uso de los clientes han alcanzado el límite de cuánto puedes escalar verticalmente. Entonces, hay tanto que puedes escalar verticalmente, ¿verdad? Como tal, obviamente, habrá un umbral de CPU que alcanzarás en algún momento. Y también no hay, si esta única instancia de tu base de datos se cae, toda tu aplicación se cae. No deberías estar en esa situación en este espacio en la nube, o en el entorno de la nube actual. Puede haber casos en los que toda tu nube se caiga. Hace apenas dos meses, toda la región este y oeste de AWS se cayó. Y hay muchas aplicaciones a escala de Internet, no puedo mencionar a las personas, todas se cayeron. No deberías estar en esas situaciones. Es por eso que necesitas pensar en escalar y en la resiliencia de tu arquitectura. Al pasar a una base de datos nativa de la nube como Yugabyte, obtienes todas estas cosas de forma predeterminada. En Yugabyte DB, puedes comenzar de forma pequeña. Puedes comenzar con un clúster de tres nodos. Estamos manejando, digamos, 500 solicitudes por minuto o por segundo. Y si deseas escalar, digamos, si te vuelves viral y deseas manejar, digamos, 5,000 solicitudes por segundo en cuestión de horas, puedes hacerlo agregando nuevos nodos a la instancia de Yugabyte DB. Por lo tanto, Yugabyte DB puede distribuir la carga o equilibrar la carga de las solicitudes de consulta y manejar más tráfico. A medida que obtienes más datos, no solo maneja una mayor cantidad de datos, sino también el procesamiento. También puedes escalar el procesamiento con Yugabyte DB. Y obviamente, lo otro que puede suceder son las interrupciones, ¿verdad? Y también tu base de datos puede caerse o tu servidor GraphQL en sí puede caerse. La mayoría de las veces, el servidor GraphQL es sin estado. Todo el estado se mantiene en la base de datos. Entonces, si pierdes una instancia de GraphQL, obviamente puedes seguir generando nuevas instancias de GraphQL, pero es esencial que los datos estén disponibles. Si tienes una instancia de un solo nodo como PostgreSQL, que no tiene ninguna redirección o es difícil configurar réplicas de lectura, tendrás interrupciones en tu arquitectura. Ahí es donde entra en juego un SQL distribuido. Ahí es donde Yugabyte DB proporciona todas estas cosas de forma predeterminada, como explicó Marco las diferentes topologías que puedes tener en Yugabyte DB en una nube multicéntrica y multinube, donde tus aplicaciones siempre están activas. Queríamos descubrir cuánta escala podemos lograr de manera lineal. Para eso, hicimos un ejercicio donde queríamos escalar las suscripciones de GraphQL de manera lineal. Comenzamos de forma pequeña, es un caso de uso bastante sencillo que queríamos hacer. Obviamente, queríamos simular una aplicación de comercio electrónico donde habrá usuarios y los usuarios realizarán pedidos. Obviamente, en situaciones como el Black Friday o el Cyber Monday, la cantidad de tráfico aumentará considerablemente. Por lo tanto, puedes escalar tu base de datos para ese tipo de eventos y, a medida que el tráfico disminuye, también puedes reducir la escala. En este ejercicio, vamos a mostrar la parte de escalar que hicimos. Comenzamos con 25,000 suscripciones utilizando un clúster de tres nodos. Por lo tanto, pudimos escalar ese mismo clúster de 25,000 suscriptores a 1 millón de suscriptores sin tiempo de inactividad ni latencia, sin detener los servidores GraphQL o los servidores GraphQL que atienden el tráfico de los usuarios. Queríamos simular eso. Pasamos de 25,000 suscriptores a un millón de suscriptores dentro del mismo clúster. Así es como de escalable es de manera lineal. Puedes comenzar de forma pequeña y, a medida que una aplicación gana tracción, puedes escalar tu paquete. Esta es una configuración de referencia. Si estás interesado, no dudes en preguntarme y te mostraré dónde está el código y todo eso. Todo se ejecutó en Kubernetes para que sea más fácil escalar cada nivel, lo que queríamos evaluar. No dudes en preguntarnos en el chat si necesitas detalles sobre la configuración de referencia en sí. Genial, eso es todo lo que tenía como parte de la escalabilidad, ahora viene la parte más interesante que Prat va a usar. Obviamente, SQL distribuido es como una cultura que debes conocer, ¿cómo ajustas las consultas? ¿Cuáles son los aspectos a tener en cuenta al trabajar con SQL distribuido, verdad? Esa parte será cubierta por Prat. Permíteme dejar de compartir mi pantalla y devolver el control a Prat.

De acuerdo, así que vamos a seguir adelante y compartiré mi pantalla aquí nuevamente. Más fácil. De acuerdo. Entonces, el ajuste de consultas con Yugabyte. Como mencionó Nico y la mayoría de las cosas en las que están trabajando son ORMs y tienen formas particulares de consultar tu base de datos. Incluso si escribes tu propio SQL, por ejemplo, como en Asura, tienen algunas piezas interesantes donde puedes escribir tu propio SQL, pero cuando rastreas eso, si recuerdas cuando estábamos viendo Asura, cambia cómo interpreta tu código SQL regular para trabajar con el ORM de Asura y cómo decide crear esa consulta por sí mismo. Por lo general, me gusta comenzar con, ¿por dónde empezamos? Correcto, tienes la optimización del rendimiento frente a la depuración de consultas. La optimización del rendimiento, por lo general, implica métricas a nivel del sistema operativo. Estás viendo la memoria, la CPU, la E/S, ¿cómo afectan las consultas estas estadísticas? ¿Tenemos suficiente potencia, verdad? Como mencionó Nikko, en qué punto escalamos en lugar de intentar ajustar las consultas. Por lo tanto, a menudo, estamos viendo estas métricas para decidir, ok, ¿tenemos algunas consultas con un rendimiento deficiente o simplemente no tenemos suficientes nodos para satisfacer nuestra carga de trabajo? Y esa es la gran parte de Yugabyte, puedes agregar nodos fácilmente, como nos hemos dado cuenta de que, ya sabes, solo necesitamos más CPU o más E/S o necesitamos atender más consultas, podemos agregar nodos. Es realmente así de simple para nosotros. Y luego la depuración de consultas, ¿verdad? Lo que veremos es cómo identificar consultas lentas. ¿Cómo las analizamos para decidir, sabes, dónde están los problemas dentro de esas consultas? Podemos hacer eso en Asura. Prisma es un poco diferente, y luego tenemos explain versus explain analyze y lo que hacen y lo que son. Asura tiene esta función incorporada realmente útil. Te permite ejecutar el equivalente de un explain analyze dentro de Postgres. Entonces, en la consola de Asura, tenemos este botón llamado analyze, ¿verdad? Y está allí en la sección de la API. Lo que hace, te dará el SQL generado y el plan de ejecución. Entonces, lo que vemos aquí es una de las consultas que ejecutamos para la aplicación de encuestas. Y te muestra el SQL generado. Esto es realmente útil. ¿Es lo suficientemente grande para todos? Solo date cuenta de lo que podemos ver aquí es el propietario que estoy creando en este SQL generado que se ejecuta. Entonces, verás que tiene el select de lo que estamos buscando. Y luego tiene estos left, outer join laterales. Eso siempre me confunde con las diferentes tablas y cosas de las que tenemos que obtener toda la información. Y no son fáciles de ver. No son fáciles de descifrar lo que realmente están haciendo. Y luego puedes ver un poco más abajo que tenemos el plan de ejecución para estas consultas en particular. Y nuevamente, por lo general, son un poco difíciles de ver. Podemos ver aquí que hacemos este join de bucle izquierdo anidado y ejecutamos un escaneo de función. Lo materializamos, movemos estos. Y para cualquiera de estos, cada uno de estos tiene que ser cada una de estas como el escaneo de función, ups, no quería hacer eso. Cada una de estas partes tiene que obtener la pieza debajo de ella, satisfecha para trabajar hasta el final. Y en este en particular, muchas veces lo que estamos buscando son exploraciones secuenciales, y tal vez algunos de estos agregados. Y voy a hablar un poco sobre lo que todo esto significa. Pero la primera parte es, ¿cómo identifico una consulta lenta? Puedes comprarlo. Para nosotros, como somos Postgres, tenemos declaraciones de estadísticas de PG. Y está incorporado en Postgres. Y nos ayuda a investigar las consultas problemáticas. Muestra el ID de la consulta, el número de llamadas de la consulta, el tiempo total que llevó, nos da los tiempos mínimo, máximo y promedio, el número de filas que devuelve. Esta es una gran tabla para usar cuando intentas depurar algunas de las consultas problemáticas con las que puedes encontrarte. Entonces, lo que generalmente quieres hacer es lo primero es que la tabla de declaraciones de estadísticas de PG agrega todas las consultas. Por lo tanto, lo primero que quieres hacer es restablecer la tabla. De esa manera, si sabes que esta consulta en particular es, o si no sabes qué consulta es, sabes, que se está ejecutando mal, o estás tratando de averiguarlo, porque tal vez tienes un montón de consultas diferentes que se ejecutan todas al mismo tiempo. Si ejecutas este select PG stat statement reset, eliminará completamente esa tabla en particular. No te afecta. Correcto, esta es solo una tabla de estadísticas en Postgres que usamos. Por lo tanto, no importa, no afectará a tu aplicación, pero luego, la consulta que más me gusta usar es esta a continuación, donde seleccionamos el ID de la base de datos, la consulta, ya sabes, yada yada yada, todas las cosas diferentes. Y luego las ordenamos por tiempo total descendente. Por lo tanto, nos da las consultas más lentas, las 10 consultas más lentas, y eso nos permitirá ver, ok, cuáles son las 10 principales. Vamos a elegirlas y empecemos a trabajar en ellas. Luego también tenemos, voy a hacer un poco de publicidad para nuestra plataforma Ubi, es una versión empresarial. Tenemos una pestaña de consultas lentas allí. Y luego, como viste en mi otro ejemplo, también tienes esas consultas lentas en nuestra nube. Ambos son lo mismo. Es solo una vista de las declaraciones de estadísticas de PG. Por lo tanto, simplemente te lo damos en un bonito espacio de interfaz de usuario aquí. Y podemos ver, ya sabes, cuánto tiempo llevó algunas de estas. Pero esto es solo nuestra publicidad descarada para nuestra plataforma de datos Ubi para nuestros usuarios empresariales, si te gusta. Entonces, ok, descubrimos qué consulta lenta es, ¿y ahora qué hacemos? Lo primero que me gusta hacer es ejecutar un plan de explicación. Esto es solo un plan de explicación realmente básico, explicar seleccionar todo de esta tabla foo. Y lo que vemos es que tenemos un escaneo secuencial en esa tabla. Ahora, lo que eso significa es que, quiero decir, si estás familiarizado, pero tenemos que escanear toda la tabla para encontrar, ya sabes, todos esos datos. Ahora, como Marco señaló anteriormente en esto, lo dividimos en varios nodos, ¿verdad? Por lo tanto, el escaneo secuencial de tablas en Ubite es un poco complicado porque, si lo piensas, tenemos que escanear toda la tabla y esos datos pueden estar distribuidos en varios nodos, y luego tenemos que hacer eso por todos ellos. Puedes ver cómo esto puede ser un poco complicado, especialmente en un sistema distribuido como Ubite. Ya sabes, a medida que agregas más nodos y más nodos, esto puede llevar más tiempo. Entonces, lo que estamos viendo aquí, como vemos, tenemos un escaneo secuencial en foo, tenemos un costo, tenemos el número de filas y tenemos el ancho. Por costo, el rango número punto punto número es porque muestra el costo para comenzar la operación de fila y los costos para obtener todas las filas. Y con todas, quiero decir, todas las devueltas por esta operación, todas en la tabla. Entonces, lo que vemos aquí, como tenemos un costo de cero y luego 155.

Entonces, el costo inicial, ¿verdad?, es cero, y para un escaneo secuencial, será cero porque simplemente leemos la página y devolvemos las filas. Simplemente comenzamos en la parte superior y luego vamos hasta abajo. Eso es prácticamente todo. Filas, obviamente, es autoexplicativo, es el número de filas para la operación que se recuperan. Y luego tienes el ancho. Entonces, el ancho es la idea de PostgresQL, o la idea de Postgres, de cuántos bytes, ¿verdad?, en promedio hay en una sola fila devuelta por esta operación. Entonces, lo que vemos aquí es que como nuestra tabla falsa solo tiene una columna entera, se almacena como cuatro bytes. Ahí lo tienes. Una cosa importante a tener en cuenta aquí es que también es genial que esta consulta no se ejecuta realmente. Por lo tanto, no la estamos ejecutando en la database. Solo estamos tratando de entender, y sabes, los operadores la están analizando, para entender qué hará. Pero en realidad no ejecutamos la consulta. Así que estamos bien aquí. Pasemos a la siguiente diapositiva.

Entonces, veamos veamos el explain analyze, ¿verdad? Esto es muy similar a explain, pero en realidad te muestra dónde se gasta nuestro tiempo. Y esto es muy importante, ¿verdad? Cuando intentas entender las consultas lentas y los problemas de consultas dentro de las bases de datos, todo se trata de dónde estás gastando tu tiempo. Así que podemos ver que tenemos el explain analyze, seleccionar todo de nuestra tabla T, y limitar a 100. Entonces, nuevamente, puedes ver el límite, nuestro costo es de cero a 9.33, el número de filas es 100, ¿verdad? Porque estamos limitando eso a 100 filas y nuestro ancho parece ser de aproximadamente 608 bytes. Pero luego puedes ver que tenemos nuestro tiempo real y puedes ver el número de filas, el número de bucles y que estamos haciendo ese escaneo secuencial en la tabla T. Entonces, nuevamente, si realmente lo miramos, se ejecuta la consulta. Muestra este tiempo real y dónde gastamos. Así que estamos mirando 100 filas y miramos una vez. Esto es una estimación del número de filas en realidad en la tabla pero estamos limitando a 100. Así que realmente solo obtenemos eso superior. Pero como hacemos un escaneo secuencial, tenemos que mirar toda la tabla. Por eso puedes ver que los escaneos secuenciales son bastante difíciles. Dentro de Yugo Binding Así que veamos algo un poco más complejo. Bien, tenemos una tabla de cervecerías. Tenemos el ID de la cervecería, el nombre, la ciudad, el estado, la clave primaria que será nuestro ID de cervecería. Y luego tenemos cervezas. Correcto, así que nombre, ID de la cerveza, ABV. Si estás familiarizado con las cervezas, entenderás qué son algunos de estos. Me gusta la cerveza, creo que a algunos también. Y luego tenemos nuestra restricción. Tenemos una relación de clave externa, ID de la cervecería y luego hace referencia a la tabla de cervecerías ID de cervecería. Así que vamos a ejecutar algunas consultas contra esto para echar un vistazo. Aquí tenemos nuestro explain y seleccionamos algunas columnas de cervezas y cervecerías y tenemos un pequeño join allí. Y ahora podemos ver el plan de consulta. Así que hacemos un bucle anidado y tenemos un escaneo secuencial en cervezas. Obtenemos un costo de cero, nuestras filas tienen solo mil y nuestro ancho. Y luego usamos un escaneo de índice utilizando el PK de cervecerías en VR. Entonces, este plan de consulta muestra el plan de ejecución que el optimizador ideó en base a su conocimiento de los data. La consulta no se ejecuta nuevamente. Así es como se ejecutará. No muestra tiempo ni estadísticas ni nada pero tiene algunas estadísticas importantes, ¿verdad? Tenemos en la línea uno, no hay costo de inicio, ¿verdad? Lo sabemos. El bucle anidado obtiene mil filas. Un bucle anidado toma una sola fila de la primera fuente de filas, ¿de acuerdo? La fuente de filas de conducción coincide con eso con la segunda fuente de filas, la fuente de filas de sondeo hasta que se agote la fuente de filas de conducción. Así es como funciona este plan de consulta. Así que avanzamos. En la línea dos, podemos ver que hacemos ese escaneo secuencial en las cervezas, no hay costo de inicio y un costo total de cien. Entonces, esta fuente de filas debe producir 1,000 filas para que la fuente de filas obtenga 1,000 filas, la siguiente fuente de filas. Entonces, hacemos un escaneo de índice en cervecerías en el índice PK de cervecerías y cada sonda de esta fuente de filas cuesta 0.11 y devuelve una fila, ¿verdad? Puedes ver eso aquí en la parte inferior. Esas son algunas estadísticas bastante importantes sobre cómo lo estamos ejecutando. Y luego pasaremos al siguiente aquí. Bueno, eso fue todo, lo siento. Eso es un poco de explain analyze. En su mayor parte, eso es lo que me gusta revisar cuando estoy viendo consultas, especialmente las que tienen un rendimiento lento. En Will Autograph QL con el ORM que crea sus propias consultas porque así es como se ejecuta. Puede ser difícil leer estas consultas realmente largas que crea. Si volvemos aquí a esto, ya sabes, este SQL generado está cortado, estas son consultas realmente largas que crea. Así que tienes que buscar y trabajar a través y trabajar en cada parte de esta consulta para entender qué está haciendo. Y como puedes ver, estas son mucho más complejas que nuestras consultas más pequeñas. Así que tienes que trabajar en estos planes de ejecución para entender, ¿sabes, dónde estás gastando tu tiempo? ¿Dónde estás realmente gastando el tiempo? Entonces, una de las cosas, si miramos, vamos, vamos por aquí un poco. Lo que veremos aquí son bucles. Puedes ver esto. Esta es la cantidad de veces que tiene que recorrer para obtener todos los data de esta parte en particular o parte de los data, ¿verdad? Entonces, si hay una parte donde puedes decir, está bien, vamos a obtener cien, ya sabes, 10 filas, pero tenemos que recorrer cien mil veces, eso va a ser un problema. Va a ser muy lento. Y entonces, cuando esto, ya sabes, si ves algo así, vamos a querer ver por qué tenemos que recorrer eso tantas veces. Tal vez necesitemos agregar un índice allí. Los índices en YouCubite son, muy, muy ventajosos. Los usamos todo el tiempo. Ya sabes, si estás familiarizado con Cassandra, tenemos nuestra API de Cassandra, si eres un usuario de Cassandra tal vez anteriormente, el índice puede ser un poco difícil. Nuestros índices son consistentes, así que animamos a las personas, si ves algo como un escaneo secuencial, necesitamos resolver eso y probablemente agregar un índice a eso porque no queremos escanear toda la tabla. Agregamos un índice, podemos aumentar en gran medida la velocidad de las consultas. Recientemente tuve un cliente, y tenía una tabla y hizo un join en una columna en particular que estaba presente en dos tablas diferentes. Ahora, en una base de datos monolítica singular de Postgres, eso no será malo, ¿verdad? Porque simplemente va a ir a esa única base de datos, recorrerla, encontrar datos y volver. Y YouGuy, no era tan malo. Creo que volvía en cuatro, 500 milisegundos. Pero una vez que agregamos ese índice, comenzó a volver en dos milisegundos, ¿verdad? Así que puedes ver que fue un impacto inmediato solo agregando ese índice. En algunos otros casos, y particularmente en un caso de GraphQL, estaba trabajando con un cliente y teníamos consultas que tardaban minutos porque se estaba uniendo a un par de tablas diferentes. Tuvimos que trabajar en ello, puede ser bastante intenso mientras intentas trabajar en cómo estamos obteniendo los data y uniendo estas tres tablas diferentes y trabajando en algunos de estos planes de explain analyze. Y nuevamente, a medida que hemos trabajado en y descubierto dónde estamos gastando el tiempo, especialmente donde estábamos tratando de agregar estos diferentes columnas, nos dimos cuenta de que, oh, estamos gastando todo este tiempo tratando de recopilar los data para esta columna en particular, lo estamos recorriendo muchas veces, ¿verdad? Así que agregamos un índice allí, y fue genial. Quiero decir, no genial, pero hicimos que la consulta se ejecutara en solo un par de segundos en lugar de 1.5 minutos.

Y eso fue solo agregando un índice. Ahora tomó un poco más de tiempo, tuvimos que trabajar un poco más en ello para que funcione correctamente. Pero ese fue otro ejemplo.

Y el último, no puedo compartir estas consultas porque son datos de clientes, pero me gusta hablar de ellas, es que incluso ajustar el orden de unión, ¿verdad? Si estás revisando y tratando de entenderlo, tuve un cliente que estaba uniendo un par de tablas el orden de unión, era una consulta complicada, tardaba, creo, uno y medio segundos en regresar y necesitaban que fuera, en milisegundos, ¿verdad? Necesitaban que regresara en un par de cientos de milisegundos. Así que simplemente ajustamos el orden de unión de la consulta misma para Yugabyte. Y eso permitió que disminuyera bastante. Creo que lo redujimos de 1.5 segundos a tres o 400 milisegundos. Y eso fue aceptable para ese cliente en particular.

Entonces, esa es la otra última parte que menciono, ¿cuáles son sus SLA, qué tiempos debe cumplir? A veces, el ORM crea la consulta de la mejor manera que cree que debería ser. Y muchas veces eso puede ser, estos están construidos principalmente para Postgres, sus bases de datos de una sola instancia de Postgres. Y por lo tanto, con Yugabyte, querrá echar un vistazo a dónde está gastando su tiempo, contáctenos, envíenos un mensaje, lo ayudaremos, eche un vistazo a algunos de estos. Y podemos intentar guiarlo sobre cómo utilizar mejor estos en un sistema distribuido como Yugabyte. Así que eso es prácticamente todo lo que tengo.