Construyendo APIs GraphQL sobre Ethereum con The Graph

Genial. Entonces, sí, este será un masterclass donde construiremos una API GraphQL en la parte superior de una red blockchain, y la red en la que vamos a construir en la parte superior es Ethereum. Y esto probablemente esté fuera del alcance de la mayoría de las charlas o talleres que se dan aquí. Definitivamente es muy diferente a todo lo que había hecho cuando empecé a aprender estas cosas. Pero creo que se está volviendo cada vez más relevante, supongo, con la aparición de muchos trabajos y oportunidades diferentes que están ahí fuera. Y es como una nueva área para explorar que tal vez acompañe todo el conocimiento existente que tienes sobre GraphQL y cómo se puede usar. Así que si estás interesado en explorar oportunidades en el espacio de blockchain, o el espacio de Web3, o incluso con muchas de las empresas tradicionales como Stripe, PayPal y Meta y todas estas empresas que añaden cosas de blockchain, esto podría volverse relevante para nuestro día a día trabajos, quién sabe. Pero dicho esto, esto se va a dividir en dos partes. Así que voy a hacer una presentación. Y también voy a hacer un taller y el taller lo compartí en el chat anteriormente. Así que deberías ver un enlace a eso. Es un repositorio de GitHub que vamos a seguir. Y aquí está. Ampliemos un poco aquí. Genial. Mi nombre es Nader Dhabat. Soy un ingeniero de relaciones con desarrolladores en Edge and Node. Edge and Node es una startup de blockchain creada por el equipo detrás del Protocolo Graph que es de lo que vamos a hablar hoy. Y hacemos muchas cosas diferentes. Apoyamos este protocolo desde la perspectiva de ser ingenieros de software que construyen y mantienen la infraestructura para este protocolo. También hacemos herramientas de Web3. Hacemos código abierto de Web3. Estamos creando un par de aplicaciones de Web3 que van a ser de código abierto. También hacemos conciencia de Web3 y capital de riesgo. Así que una de las cosas que hago mucho es enseñar a la gente cómo construir cosas y compartir arquitecturas de referencia y cosas así. El Graph es lo que vamos a usar. Y es uno de los muchos protocolos de infraestructura web de Web3 que existen. Y es un protocolo de indexación para consultar redes blockchain como Ethereum e IPFS. Entonces, ¿qué significa eso realmente? Bueno, cuando pensamos en bases de datos tradicionales, se crean y se construyen para ser de manera eficiente para que podamos consultar y guardar datos. Así que una base de datos tradicional

Entonces, lo que los desarrolladores solían hacer en el pasado era tomar estos protocolos de cadena de bloques, decidir los datos que necesitaban y construir sus propios servidores de indexación centralizados donde iban y recopilaban todos estos datos, los guardaban en una base de datos y abrían su propio punto de conexión de API encima de eso.El problema con esto era que era muy intensivo en recursos y en ingeniería, y también rompía toda la idea y los principios de seguridad en torno a la descentralización, porque los datos de la cadena de bloques se supone que son la fuente de verdad.Entonces, ¿cómo se hace realmente esto descentralizado? Si estás centralizando en una base de datos para leerla.Graph es un protocolo de indexación que permite a los desarrolladores construir estas API que leen todos estos datos, los indexan de manera descentralizada.Y aparecen en una red de nodos entre pares.Y luego los desarrolladores, una vez que los han implementado, pueden abrir sus puntos de conexión de API para que cualquier otro desarrollador construya aplicaciones front-end u otras aplicaciones encima de ellos.

Para explicarlo un poco más, una base de datos tradicional podría verse así, donde tenemos una base de datos, hemos construido un punto de conexión de API encima de eso, tal vez una función sin servidor o algún tipo de servidor.Vamos a enviar una solicitud a esta API.Luego leerá los datos.Luego los procesará, tal vez en un retorno.Y luego traerá esa respuesta de vuelta al cliente.Pero de nuevo, no podemos hacer esto cuando leemos datos directamente de la cadena, porque la cadena se considera la base de datos.Así que realmente no tenemos esta capa de cómputo en el espacio de la cadena de bloques.Entonces, ¿cuáles son algunos otros ejemplos de indexadores en la vida real?Bueno, Google o cualquier motor de búsqueda es un indexador.Cuando queremos encontrar información en la web, no podemos simplemente visitar todos los sitios web porque hay millones de sitios web ahí fuera.Entonces, ¿cómo encontramos la información que necesitamos?Bueno, Google y otros motores de búsqueda tienen esta idea de un sistema de indexación donde rastrean toda Internet, encuentran los datos relevantes, los almacenan en sus propias bases de datos centralizadas y luego abren un punto de conexión de API encima de eso, ya sea a través de una API real con la que podemos interactuar desde una aplicación, o en el caso de Google, simplemente tenemos un sitio web que podemos visitar.Y cuando ingresamos un término en el sitio web, va a sus bases de datos y busca lo que estamos buscando, y luego devuelve la conexión al sitio web que nos gustaría ver.Entonces, Google está indexando y poniéndolo disponible para ser consultado por nosotros en el front-end. Otro ejemplo es una biblioteca.Cuando vamos a una biblioteca, no caminamos por toda la biblioteca durante cuatro horas buscando el libro que queremos.Hay un sistema de indexación donde el sistema decimal Dewey o algo así nos puede decir exactamente dónde buscar un libro, y luego podemos ir directamente y encontrar ese libro.Entonces, en un sentido similar, estos subgrafos API se encuentran entre el contrato inteligente y la interfaz de usuario y permiten a los desarrolladores consultar y obtener diferentes tipos de datos que pueden necesitar para su aplicación típica.Así que tienes estos diferentes tipos de, um,

¿Cómo se ve un esquema de GraphQL en el graph? Bueno, se ve igual que cualquier otro esquema gráfico con tal vez una pequeña diferencia que tenemos un par de directivas diferentes que son nativas del graph. Una es la directiva ad entity. Y esto simplemente significa que este es un tipo de data que queremos que sea consultable y que queremos guardar en la red. Entonces, un usuario será algo que podemos consultar simplemente agregando esta directiva ad entity. Y luego también tenemos la directiva ad derived from que nos permite crear relaciones. Entonces queremos poder crear una relación de uno a muchos entre usuarios y tokens. Y luego queremos tener una relación de uno a uno entre el token y el usuario. Y ambos están declarados aquí en este esquema de GraphQL.

Y cuando estemos listos para implementar, simplemente usamos la CLI para ejecutar graph deploy. Y luego podemos probarlo en la interfaz de usuario. Tenemos un editor gráfico real y un GraphQL playground y podemos simplemente comenzar a usar el punto final allí. Y luego también tenemos la capacidad, si lo deseamos en ese momento, de implementar esto en la red descentralizada. Porque tenemos un entorno de preparación, puedes pensar, donde podemos probarlo e incluso usarlo en nuestro front-end. Y luego tenemos el paso final si deseas publicarlo en esta, esta, en la red y permitir que otras personas también lo utilicen allí.

Entonces simplemente se te proporciona un punto final gráfico, al igual que cualquier cosa que probablemente hayas usado en el pasado donde tienes la capacidad de elegir con qué cliente de graph quieres trabajar. Te daremos esto y luego defines tu consulta. Creas tu cliente y comienzas a interactuar con él. Nada diferente a cualquier cosa que probablemente hayamos usado en el pasado con GraphQL. Una vez que tengas ese punto final, estás listo para comenzar.

Dicho esto, vamos a comenzar a trabajar en la masterclass. La masterclass está en github.com/debit3/building-a-subgraph masterclass. Y también he proporcionado el enlace.

Y parece que Lara también tiene un enlace allí de nuevo. Aquí es donde vamos a comenzar. Y la API de NFT que vamos a construir es para Foundation, y Foundation es un mercado bastante genial para el arte digital. Y verás que siempre hay cosas interesantes y a veces extrañas aquí. Así que esto es lo que vamos a consultar.

Y otra cosa genial acerca de Foundation es que tienen un portal para desarrolladores. Entonces, si vas a fnd.dev, compartiré ambos enlaces aquí. En realidad, sí. Fnd.dev es el portal para desarrolladores de Foundation. Y aquí puedes ver si eres un desarrollador y quieres construir algo sobre sus contratos inteligentes, tienen un enlace a sus contratos y su documentación aquí. Estos son sus contratos inteligentes.

Y esto es algo interesante de trabajar con blockchain y web tres y cosas así, que prácticamente si una aplicación está desplegada, sabes, estamos tan acostumbrados a pensar que un backend es propietario y que no podemos realmente usar el backend de otra persona a menos que ellos creen explícitamente una API realmente buena para que la usemos. Como tal vez queramos usar una API de Twitter. Y es muy limitada en el sentido de que no podemos realmente hacer todo lo que Twitter puede hacer. Y un día pueden decidir simplemente cerrar esa API también. ¿Verdad? Así que no es algo en lo que podamos depender para construir un negocio. Pero con los contratos inteligentes, estos son completamente abiertos y públicos. Entonces, si alguien construye una aplicación y la despliega, entonces cualquier persona en el mundo puede construir sobre eso y saber que estará allí dentro de un año y cinco años. Así que básicamente estamos diciendo, Oh, estas personas han construido este contrato inteligente. Queremos usarlo y queremos usarlo de esta manera. También puedes construir tu propio frontend sobre esto. Así que básicamente estamos tomando su backend y lo estamos usando. Y puedes hacer eso con cualquier aplicación de blockchain. Si tienes su dirección de contrato, que es completamente pública y abierta y en casi todas las circunstancias, diría yo. También tienen sus propios subgrafos. Así que puedes ver aquí que tienen el enlace a su subgrafo principal y algunos ejemplos de consultas y cosas así. Dicho esto, solo quería compartir eso, pero vamos a construir nuestra propia API sobre eso. Para comenzar, simplemente voy a ir aquí a `getting started` y dice abrir el servicio de alojamiento de Graph y voy a iniciar sesión. En realidad, ya he iniciado sesión. Así que podría cerrar sesión y luego volver a iniciar sesión.

Muy bien. Y lo que queremos hacer después de iniciar sesión y crear una cuenta es crear un nuevo subgrafo. Entonces aquí, en la esquina superior derecha, tenemos este botón para agregar un subgrafo. Así que voy a hacer clic en eso. En realidad, voy a ver si puedo hacer esto un poco más pequeño para que la gente pueda verlo mejor. De acuerdo, genial. Muy bien. Así que voy a hacer clic en 'Agregar un Subgrafo' y aquí podemos darle al subgrafo un nombre y un subtítulo. De acuerdo. Así que voy a llamar a este subgrafo un subgrafo de Foundation o algo así. Puedes llamarlo como quieras. Parece que ya tengo uno con ese nombre en mi cuenta, así que lo llamaré también subgrafo de Foundation. Eso es porque ya he hecho este taller antes y luego solo lo llamaré como subgrafo de Foundation. De acuerdo. Así que hemos ingresado solo el nombre y la descripción o el nombre y el subtítulo y podemos hacer clic en crear subgrafo. Voy a hacer clic en ocultar para que no lo agregue al explorador de subgrafos porque he creado muchos, pero si quieres, puedes decidir si quieres hacerlo o no. Bien, una vez que hayamos hecho eso, ahora tenemos nuestra interfaz de Boilerplate que podemos empujar esencialmente, así que ahora podemos ir a nuestra CLI y comenzar a construir el subgrafo localmente. Para hacer eso, voy a abrir mi línea de comandos y voy a npm instalar el CLI de Graph. Así que solo voy a copiar y pegar eso. Ya tengo esto instalado, solo voy a instalarlo de nuevo allí solo para mostrar a todos los que puedan estar siguiendo. De acuerdo, genial. Una vez que el CLI de Graph esté instalado, deberías poder ejecutar simplemente 'graph' y aquí deberías ver alguna salida. Y si hago algo como 'graph help'. Puedes ver algunos de los diferentes comandos que puedes ejecutar. Y vamos a comenzar con 'net' y 'net' inicializará un nuevo subgrafo. No solo eso, sino que hay un par de formas en las que puedes ejecutar 'graph init'. Por ejemplo, puedo simplemente ejecutar 'graph' y 'net' por sí solos. Siguiendo aquí, vamos a hacer un comando más detallado. Pero si solo hacemos 'graph net', nos guiará a través de todas estas diferentes preguntas. Como por ejemplo, qué protocolo Ethereum es como la máquina virtual de Ethereum, podríamos implementar en el servicio alojado o en el subgrafo studio.

Entonces, Sub Graph Studio es para la red descentralizada, donde se va a implementar en el servicio alojado, porque es como un entorno de pruebas donde podemos probar cosas. Podemos darle un nombre al subgrafo y nos hará todas estas preguntas. También podemos proporcionar muchas de esas preguntas por adelantado. Eso es lo que vamos a hacer con el comando con el que vamos a trabajar aquí, donde decimos 'graph a net'. Y luego pasamos algunas banderas diferentes.

Lo primero que queremos pasar es el contrato de origen. Este será la dirección del contrato inteligente de Foundation. Entonces decimos '--from contract' y pasamos la dirección. Queremos pasar la red porque hay docenas de redes que admitimos en una máquina virtual de Ethereum. Entonces admitimos Polygon, Avalanche, Celo, Arbitrum, Optimism, todas estas diferentes redes. Entonces queremos especificar 'Ethereum mainnet'. También podemos pasar el nombre del contrato, porque un solo contrato inteligente puede contener múltiples contratos que forman parte de ese contrato único. Creo que este contrato no solo tiene el token, sino también otros contratos diferentes dentro de él. Entonces el que queremos usar es el contrato del token. Y luego tenemos esta bandera de indexación de eventos. Esto será completamente nuevo para cualquiera que no esté familiarizado con cómo funciona la blockchain o cómo funciona Ethereum. Pero déjame describirlo para que tenga un poco más de sentido. Y también vamos a profundizar en esto un poco más. Y espero que al final de esto, tengas una buena idea de qué son los eventos.

Cuando pensamos en una API de GraphQL, por ejemplo, un buen ejemplo de a qué podría relacionarse esto con lo que estamos acostumbrados es que en una API de GraphQL, tenemos esta idea de una suscripción, ¿verdad? Podemos configurar una suscripción de GraphQL. Entonces, cuando se realiza una mutación, podemos suscribirnos a esos eventos. Y cada vez que alguien crea un nuevo elemento en nuestra base de datos, se dispara ese evento. En Ethereum, hay algo muy similar a eso en tu contrato inteligente, puedes crear eventos desde dentro de un contrato cada vez que se realiza una acción. Entonces, si alguien quiere decir que cuando se crea un nuevo token, queremos emitir un evento. Y en ese evento, queremos pasar argumentos similares a una suscripción de GraphQL, donde tienes los argumentos de mutación, podemos hacer eso. Entonces, básicamente vamos a decir, okay, en este contrato, sabemos que hay eventos y queremos decir automáticamente que nos importan esos eventos y queremos indexarlos. Y al hacer esto, nos darán automáticamente un código de boilerplate que nos ayudará más adelante. Y eso es todo lo que diré al respecto por ahora. Pero tal vez echemos un vistazo rápido a los contratos inteligentes de Foundation y veamos cómo se ven estos eventos.

Entonces, si voy a EtherScan, que es cómo se puede ver el código de diferentes contratos, y voy al contrato aquí, cuando voy al proxy, que es básicamente, este contrato se comunica con otro contrato, pero este es el contrato principal. Y voy a buscar MIT. Tenemos un evento que está ocurriendo aquí donde tenemos este contrato ERC 721. Y tenemos esta transferencia MIT. Y luego, si tenemos una transferencia MIT, probablemente tengamos un evento de transferencia. Y el evento de transferencia es como describir este evento, y se define el evento y luego se emite el evento. Entonces, estos son los eventos con los que estamos trabajando. Otro dato interesante es que con EtherScan, si tienes la dirección, generalmente puedes encontrar el código del contrato inteligente, que es básicamente como la base de código con la que estás trabajando.

De acuerdo, genial. Entonces, dicho esto, vamos a copiar todo esto aquí. Y lo vamos a pegar aquí. Así que tenemos nuestro gráfico CLI instalado. Vamos a decir GraphINIT desde el contrato, red main net, nombre del contrato token, e indexar eventos. Y aquí elegiremos un servicio alojado del protocolo Ethereum. Y creo que tengo todas estas cosas aquí. Así que servicio alojado, nombre del subgraph. Esto va a ser una combinación de tu nombre de usuario y el nombre del subgraph que definiste anteriormente. Así que si voy al panel aquí, y simplemente copio el slug aquí, que es DaBit 3 slash foundation subgraph two, eso debería funcionar. Y luego el directorio debería ser el nombre del subgraph. Y luego la red debería establecerse automáticamente en la dirección del contrato principal que también se establecerá automáticamente. Y luego el nombre del contrato también debería establecerse. Así que deberíamos poder establecer el nombre del subgraph y luego todo lo demás debería definirse automáticamente para nosotros. Y luego, desde aquí, solo esperamos unos segundos. Y lo que deberíamos tener ahora es un esqueleto que se ha generado para nosotros. Así que voy a mirar en mi directorio, y veo que tengo este foundation subgraph too. Así que adelante y cambia a ese directorio. Y lo abriré en mi editor de texto.

De acuerdo, así que tenemos nuestro subgraph creado. Y tenemos mucho código que ya ha sido generado para nosotros. Pero vamos a explorar las tres partes principales que componen este subgraph. Una de ellas es el esquema GraphQL. Y este va a ser nuestro modelo de datos. Podemos eliminar todo eso por ahora. No necesitamos ningún código de eso. También tenemos nuestro archivo subgraph.yaml. Si alguna vez has escrito infraestructura como código en algo como AWS o cualquier configuración en yaml, probablemente entiendas qué hace yaml típicamente. Por lo general, es algún tipo de configuración. Podría ser como código de configuraciones. En nuestro caso, es casi como infraestructura como código en el sentido de que cuando desplegamos esto en la red, el indexador lee este archivo para saber qué hacer con esta base de código. Así que el subgraph.yaml contiene toda la configuración que vamos a necesitar. Se nos proporciona un poco de plantilla. Así que voy a eliminar esas entidades porque no las vamos a usar. También vamos a eliminar muchos de estos controladores de eventos. Pero no nos preocupemos por eso ahora mismo. Lo que queremos hacer, supongo que a continuación, es volver a nuestro taller. Y ahora voy a pasar al esquema gráfico. Aquí es donde definimos las entidades que queremos almacenar y hacer consultables. Entonces, cuando miramos este sitio web de Foundation, ¿cómo podría ser el modelo de datos que queremos? Bueno, automáticamente vemos estas entidades como esto, podríamos pensar en esto como una entidad. Este es un token que tiene una imagen y una descripción, tiene un precio, tiene todo este otro metadato a su alrededor. Así que podríamos decir, bueno, para cada una de estas imágenes o estas obras de arte, podríamos decir que esto va a ser un token y luego el token tiene diferentes propiedades. Así que para nosotros, podemos simplemente decir, bueno, queremos un tipo de token. Y luego queremos que los diferentes campos de ese token sean los diferentes metadatos asociados con eso, que queremos guardar. Y también podríamos querer crear una relación entre tokens y usuarios, porque podríamos querer hacer clic en un usuario como este y ver todos los diferentes tokens que han creado. O podríamos querer hacer clic en un usuario y ver los tokens que poseen. Así que eso es lo que también vamos a hacer, vamos a tener un tipo de usuario, el usuario tiene una relación entre los tokens que posee y los tokens que ha creado. Usando este modelo de datos, que no es tan grande, podemos tener un modelo de datos para nuestra API, que es de aproximadamente 16 líneas de código. El token va a tener un ID, que será un identificador único.

También tendrá un ID de token, el ID de token será el ID que se genera por el contrato inteligente. Entonces, si alguien crea un nuevo token, el contrato automáticamente les asigna ese token, la URI de contenido será la URI de la imagen real. Y luego también tenemos una ruta IPFS del token, que será la dirección IPFS de ese token también. Tenemos un nombre de token, y luego tenemos la marca de tiempo de creación, que será el tiempo de bloque en que se creó este token. Y luego tenemos la relación entre el creador y el propietario. Y finalmente, tenemos el usuario, que es bastante básico. Lo único que nos importa realmente es el ID. Bueno, no es realmente lo único que nos importa. Es lo único que tenemos que saber sobre un usuario, porque todo lo que el usuario va a darnos cuando se autentique es su dirección de billetera. Y eso será su ID. Y ahora también podemos crear una relación entre los tokens del usuario que ha comprado y el token que ha creado. Así que podemos guardar esto y volver a nuestro subgraph.yml. Y ahora podemos completar nuestras entidades. Así que tenemos una entidad de token y una entidad de usuario. Así que puedo simplemente decir token y usuario.

Lo siguiente que queremos hacer es continuar modificando nuestra configuración. Ya hemos hecho las entidades de token y usuario. Ahora necesitamos actualizar nuestros controladores de eventos, así como nuestra dirección y nuestro bloque de inicio. Así que vamos a seguir adelante y saltar aquí y luego haremos los controladores de eventos en un momento.

Cuando implementemos este subgrafo, se dirigirá a este contrato inteligente aquí. Va a buscar todas las transacciones que hayan ocurrido. En realidad, va a ir a la dirección del contrato original. Creo que está aquí. Va a empezar a buscar todas las transacciones que hayan ocurrido para este contrato inteligente. Pero no sabe dónde empezar en la blockchain porque, ya sabes, la transacción original que ocurrió, la primera transacción que ocurrió, puede que no se dé cuenta de eso. No necesita empezar desde ahí y leer todo lo que ha ocurrido desde entonces. Así que si quisieras hacer eso, simplemente lo implementarías tal como está. Pero en su lugar puedes decir, OK, cuando se implementó este contrato, estaba en este número de bloque. Y luego queremos empezar desde ese número de bloque porque realmente no nos importa ningún data que se haya almacenado antes de eso porque nuestro contrato no estaba allí antes de eso. Así que podemos definir el bloque de inicio simplemente estableciendo el número de bloque aquí. Y en lugar de retroceder todo el camino, simplemente empezará en el bloque desde el cual se implementó este contrato o desde donde hayas establecido que sea el bloque de inicio.

Lo otro que queremos hacer es actualizar la dirección del contrato a esta dirección aquí. Y eso es porque cuando fuimos a este contrato hace un momento y miramos la dirección del contrato real, leímos que esto era un contrato proxy. Y esto es muy, digamos, un poco advanced para la mayoría del resto del masterclass en el sentido de que esto entra en cómo podrías hacer un contrato inteligente actualizable. En lugar de tener el contrato que implementaste como la fuente de verdad, puedes básicamente hacer que apunte a otro contrato y luego actualizar la ubicación de ese contrato. Así que cuando hagas actualizaciones, puedes estar apuntando a otro contrato. Eso es lo que hace este contrato. Así que cuando lo inicializamos, queríamos indexar los eventos de un contrato, pero cuando lo implementamos, queremos indexar en realidad un contrato diferente. Por eso estamos actualizando esta dirección. Y finalmente, los únicos dos controladores de eventos que nos interesan son estos dos. Tenemos 'token IPFS path updated' y 'transfer'. Así que voy a volver a esto y voy a encontrar esos dos eventos, que van a ser estos dos en la parte inferior. Así que puedo pasar eso actualizado y transfer y voy a eliminar todo el resto de estos. Así que ahora tenemos alrededor de 27 líneas de código. Así que hablemos de estos controladores de eventos.

Entonces, mencioné que en el contrato inteligente, tenemos estos eventos que se emiten y en una API de GraphQL que tiene suscripciones. Tienes estas suscripciones que están escuchando eventos que se emiten, tal vez en una API de GraphQL. Y luego, en tu aplicación cliente, vas a manejar ese evento. Es posible que escuches ese evento. Y cuando ocurre ese evento, es posible que hagas algo localmente, o algo así.

Básicamente, estamos diciendo que cuando se active este evento, queremos escucharlo y manejarlo llamando a otra función. Pero la función en realidad se encuentra en nuestra API y en nuestro subgrafo. Así que tenemos dos eventos de los que nos vamos a preocupar en nuestra API. Uno es el evento de transferencia. Y esta función se dispara o se emite este evento cuando alguien crea un nuevo token. Y también se emite cuando alguien transfiere un token de una parte a otra. Así que cuando creas un nuevo token, esto se disparará. Y luego, cuando esa persona lo mueve a otra parte, se disparará. Y cuando se activa ese evento, básicamente estamos llamando a esta función handle transfer que veremos en un momento.

Y la única otra función de la que nos preocupamos es la función handle token IPFS path updated. Y eso significa que si alguien tiene un token y cambia la ruta IPFS, queremos poder manejar esa actualización y realizar ese cambio localmente. Estos dos controladores de eventos se encuentran en el archivo SRC mapping.ts, y hay mucho código de plantilla generado para nosotros aquí, podemos eliminar eso. Y aquí es donde vamos a escribir la lógica del negocio para manejar estos dos eventos. Pero antes de hacer eso, podemos usar la CLI de Graph para generar algo de código que nos ayudará allí. Así que si vuelvo a la terminal y simplemente ejecuto graph code gen, esto inspeccionará nuestro esquema de GraphQL y generará algún código que nos será útil. ¿Qué hará ese código? Bueno, hay dos cosas que vas a hacer en estos mapeos. Cuando piensas en lo que estamos tratando de lograr aquí, estamos diciendo, OK, tenemos este contrato inteligente, estamos describiendo los datos que queremos indexar, y lo estamos implementando en una red de nodos y esa red va a leer este subgrafo. Y va a pasar y va a guardar los datos que queremos guardar, y luego vamos a poder consultar eso desde nuestro frontend. Bueno, ¿dónde se guardan estos datos? Bueno, se guardan en el propio nodo. Así que puedes pensar en un nodo como alguien que ejecuta un servidor. Correcto. Pero, pero se ejecuta en varios lugares. Entonces, en este servidor, podríamos tener una base de datos y en esta base de datos queremos guardar información. Entonces, una de las cosas que vas a hacer aquí es simplemente guardar información en ese nodo.

Lo otro que podrías hacer desde estas funciones es llamar de vuelta al contrato inteligente, porque podrías necesitar información adicional del contrato inteligente que no se obtiene de los argumentos. Así que cuando emitimos un evento, podríamos tener alguna información sobre lo que está sucediendo allí, pero es posible que no tengamos toda la información. Por lo tanto, es posible que necesitemos comunicarnos tanto con el nodo de Graph para leer y escribir datos, como con el propio contrato inteligente para leer datos. Dicho esto, eso es más o menos una idea de lo que estamos a punto de hacer.

Adelante, vamos a escribir algo de ese código. Y eso estará aquí en los mapeos de assembly script. Voy a importar las dos importaciones que necesitamos. Estos dos eventos en la parte superior, el evento de actualización de la ruta IPFS del token y el evento de transferencia, son simplemente tipos que se utilizarán para la seguridad de tipos. La CLI genera tipos para que los usemos. Y la única interfaz real con la que vamos a interactuar aquí para hacer cualquier tipo de llamada a la API es este contrato de tokens. Y esto básicamente nos proporciona un enlace que nos permite comunicarnos con el contrato inteligente para leer información. Podemos solicitar información al contrato inteligente utilizando algún ID de token, por ejemplo. Esta API generada 'slash token' nos permite comunicarnos con el contrato inteligente. Y luego, estas APIs generadas 'slash schema' nos permiten comunicarnos con el nodo de Graph. Desde el nodo de Graph, podemos leer y escribir datos. Y eso es más o menos lo que estas dos APIs nos permitirán hacer. Podemos decir token.save o user.save, y así sucesivamente, o token.load, y así sucesivamente, lo cual haremos en breve. Bien, la primera función con la que podríamos trabajar será la más pequeña de las dos. 'tokenURIUpdated', esto va a recibir un evento. Lo primero que haremos es cargar el token desde el nodo de Graph. Esto significa que este token ya existe, y si existe, queremos seguir adelante. Si no existe, simplemente salimos de esta función. Decimos token.load, y en este evento tenemos este objeto params que tiene un ID de token, por lo que básicamente estamos obteniendo el ID de token del evento 'handle tokenURIUpdated'. Y si vamos aquí a subgraph.yaml, vemos que tenemos el primer argumento, que es un entero, y este será el ID de token. Eso es realmente lo único que nos importa, es el ID de token. Si el token no existe, salimos. Si existe, luego actualizamos la ruta IPFS del token con event.params.tokenIPFSPath que viene a través de este evento. Obtenemos el ID de token, consultamos ese token, luego actualizamos la ruta IPFS del token y luego llamamos a token.save. Y esto guarda esos datos de vuelta en la base de datos.

Y ahora hemos actualizado nuestro token. Y luego, la única otra función que tenemos es la función handle transfer. Así que adelante y cópiala. Esta es la función de la que hablé que se llama cuando se crea un nuevo token y también cuando alguien transfiere un token a otra persona. Así que digamos que venden el token o simplemente lo mueven, lo mueven a otro lugar, se lo dan a otra persona. Hacemos algo muy similar aquí. Primero cargamos el token utilizando el ID del token que viene del evento. Y comprobamos si el token no existe. Si el token no existe, esto significa que es un token recién creado. Así que debemos crearlo. Llamamos a token. Lo siento. Llamamos a un nuevo token pasando el ID. Esto crea un nuevo token. Luego agregamos las propiedades de creador y ID del token. Así que tenemos eso que también viene del evento. Y esa es realmente la única información que tenemos hasta este punto. Sin embargo, también necesitamos más metadatos sobre este token que no están disponibles en el evento, porque si vamos a este evento, vemos que solo tenemos, um, la dirección de origen, la dirección de destino y el ID del token, pero también queremos tener otra información sobre el token. Es posible que queramos la URI de contenido, la ruta IPFS del token, el nombre y la marca de tiempo de creación. ¿De dónde viene esa información? Bueno, eso viene del propio contrato inteligente. Ahora nos vamos a conectar al contrato inteligente aquí y luego vamos a comenzar a obtener información. Queremos la URI de contenido, la ruta IPFS del token y el nombre del token. Y luego, la marca de tiempo de creación en realidad proviene de event.block.timestamp, que está disponible en cada transacción que ocurre. Eso es mucho, pero, um, básicamente acabamos de decir, bueno, si no hay un token, queremos crearlo y ahora vamos a establecer al propietario y vamos a guardar eso en el nodo de Graph, y luego continuaremos y veremos si hay un usuario, entonces no hacemos nada. Si aún no hay un usuario, vamos a crearlo. Ese es el evento handle transfer. Tenemos estos dos eventos. Ambos se definen en nuestro subgraph.yaml. Um, y ambos manejan eventos que se disparan desde el contrato inteligente. Creo que eso es todo.

Entonces, si seguimos adelante y guardamos eso, deberíamos poder probarlo. Así que a partir de ahí, hemos escrito todo el código que necesitamos para que esto funcione. Así que podemos ejecutar una compilación para probar que nuestra compilación funcione ejecutando 'graph build'. Y si esto funciona, deberíamos poder seguir adelante y desplegar.

Entonces, la compilación funciona correctamente. Así que voy a volver ahora al panel de control aquí. Voy a necesitar este token de acceso en un momento. Así que voy a ejecutar 'graph off' y luego, uh, este punto final. Y luego necesito pegar mi token de acceso. Así que solo voy a decir 'graph off' el punto final y el token aquí y esto debería autenticarme para poder desplegar allí. Ahora debería poder ejecutar simplemente 'yarn deploy'. Y esto debería ejecutar 'graph build' y luego desplegar nuestro subgraph. Y luego lo que va a suceder es que, una vez que esto esté desplegado, el proceso de indexación debería comenzar de inmediato.

Entonces ahora automáticamente vemos que tenemos la sincronización. Parece que ya está sincronizado, lo cual es bastante rápido. Parece que ya está sincronizado, lo cual es bastante rápido. Así que 100% sincronizado, 13 millones de bloques, 159,000 entidades, y eso fue muy rápido, en realidad. De acuerdo. Entonces, todos estos data ahora deberían estar sincronizados. Entonces, lo que podemos hacer ahora es comenzar a ejecutar consultas. Podría decir que quiero obtener los tokens. Y ahí lo tenemos. Vemos que los data están regresando. Tal vez queramos hacer esto de manera un poco diferente, porque no queremos obtenerlo en ese orden. Podríamos decir ordenar por ID y luego la dirección de orden será como descendente. Y ahí tenemos, como la idea de $99.99. Y si voy, solo voy a copiar este contenido, URI.