¿Qué es The Graph, cómo crear subgráficos y cómo ayuda esto a mi dApp?
La mayoría de las dApp de Ethereum tienen dos partes en su Infraestructura (Versión Simple):
- Front-end (Ejecutado en el navegador)
- Un Nodo de Ethereum (Interfaz de la red de ETH)
Cuando una transacción ocurre en Ethereum, emite un evento. El Front-end revisa estos eventos y actualiza el UI. Las dApps pueden hacer tipos limitados de consultas a un nodo Ethereum para mostrar datos en el front-end.
Pero las dApps no pueden vivir sólo de transacciones, eventos y esas consultas mínimas. Para proveer una experiencia total del usuario, una dApp necesita procesar, al menos, sus propios datos para mostrar la actividad particular de un usuario en particular, construir un perfil de usuario, mostrar las analíticas y permitir múltiples características… Ahora, ¿cómo podemos hacer todo esto?
Un número de equipos de desarrollo de dApps están haciendo esto, construyendo sus propias soluciones personalizadas, raspando datos de la blockchain, rastrear eventos, transacciones y almacenarlos en una base de datos centralizada tradicional. Pero, queremos confiar en la minimización de la web3, ¿verdad?
Resumiendo el problema:
”Las dApp necesitan datos indexados para realizar consultas a larga escala para permitir una forma completa de la Experiencia del usuario en una forma que minimice la confianza”
Aquí entra: The Graph
¿Qué es The Graph?
El equipo de The Graph está resolviendo este problema, construyendo un protocolo descentralizado que será autorizado por Graph Nodes, procesando eventos de Ethereum y almacenándolos como datos indexados que, las dApps, pueden consultar a través del endpoint API.
El Protocolo de Graph recae en una categoría que referimos como solución de lectura-escalabilidad de capa 2. Su propósito es permitir que las aplicaciones descentralizadas (dApps) consulten los datos públicos de la blockchain, eficientemente y sin confianza, a través de un servicio así como las blockchains y el Internet en sí mismo opera como una utilidad pública. Esto es con el interés de minimizar el rol de la infraestructura frágil y centralizada, vista en muchas arquitecturas de aplicaciones “descentralizadas” de hoy en día. Especificación del Protocolo Graph
Estos índices (“subgráficos”) están, actualmente, siendo alojados por el equipo de The Graph. Pero en el futuro, estos índices vivirán totalmente en la red descentralizada de Graph Nodes.
¿Cómo funciona The Graph?
Profundicemos un poco para entender cómo The Graph funciona:
- dApps (a través de sus contratos inteligentes) crean transacciones Ethereum, el cual emite eventos.
- Graph Nodes escanea cada bloque Ethereum, buscando eventos.
- Graph Nodes encuentra eventos para tus subgráficos en los bloques Ethereum y ejecuta los controladores de asignación proveídos. Estos mapeos deciden cómo los datos son almacenados y actualizados en Graph Nodes.
- Your dApp puede consultar estos datos a través de las APIs de GraphQL, las cuales son traducidas por Graphs Nodes para buscar los datos indexados.
Así que, ¿qué estamos esperando? ¡Construyamos un Subgráfico!
Construyamos un Subgráfico
Usemos una muestra de un contrato inteligente con un proyecto Truffle y construir un subgráfico.
Graph Explorer
Usando Graph Explorer, puedes explorar otros subgráficos construídos por la comunidad. También podemos consultar subgráficos usando el UI Graph Explorer.
Necesitamos crear una cuenta de Graph Explorer y obtener un Token de Acceso, el cual será usado mientras desplegamos nuestro subgráfico en Graph Nodes (alojado por el equipo The Graph). Así que, vamos a crear una cuenta en Graph Explorer.
Crea un subgráfico usando la UI de Graph Explorer con el nombre “ejemplo”.
Ahora necesitamos instalar Graph-CLI en nuestro sistema (estoy usando Ubuntu 16.10):
sudo yarn global add @graphprotocol/graph-cli
Ahora, vamos a crear un ejemplo de subgráfico usando el siguiente comando:
graph init buddies2705/example-subgraph example-subgraph
// Sintáxis del Comando
graph init <GITHUB_USER>/<SUBGRAPH_NAME> <DIRECTORY>
// Aquí, el Directorio es opcional, si no lo pasas creará un directorio con SUBGRAPH_NAME
Instalemos la dependencia y generemos los mapeos:
//Instala las Dependencias
Yarn
//Genera los Mapeos
yarn codegen
Establezcamos Auth usando el Token de Acceso (podemos obtener este Token de Acceso desde el panel de control de Graph Explorer):
graph auth https://api.thegraph.com/deploy/<ACCESS_TOKEN>
Ahora podemos desplegar nuestro subgráfico en Graph Explorer usando el siguiente comando:
graph deploy --debug --node https://api.thegraph.com/deploy/ --ipfs https://api.thegraph.com/ipfs/ buddies2705/example
//Puedes ver que estamos usando buddies/ejemplo donde "buddies2705" es mi
//nombre de usuario de github and "ejemplo" es el nombre creado de nuestro subgráfico usando
//el UI de Graph Explorer.
Ahora abre Graph Explorer y podrás ver tu subgráfico. También puedes consultar tu subgráfico también usando el UI de Graph Explorer. Puedes ver los endpoints para interactuar, programáticamente, con tu Subgráfico.
URLs de API de Subgráfico GraphQL
Debajo del Capó
Profundicemos más y entendamos qué sucedió “Debajo del Capó”. Tenemos un proyecto Truffle con un contrato Gravity.sol, el cual es simplemente creado usando Gravatar (tu Avatar en el internet) en Ethereum.
Este contrato está emitiendo dos eventos:
-
NewGravatar: cuando un nuevo Gravatar es creado -
Updaetd Gravatar: Cuando un Gravatar existente es actualizado
event NewGravatar(uint id, address owner, string displayName, string imageUrl);
event UpdatedGravatar(uint id, address owner, string displayName, string imageUrl);
Si indexamos estos dos eventos de Datos, podemos responder consultas como:
- ¿Cuántos Gravatars fueron creados el año pasado?
- ¿Cuántos Gravatars, en promedio, son actualizados diariamente?
- ¿Cuál es el top 10 de sitios de alojamiento de imágenes para todos nuestros Gravatars? (Será IPFS 😎)
- ¿Cuáles son los nombres más comunes para los Gravatars?
Algunas de estas consultas necesitan ejecutarse en los datos del contrato completo desde el momento que el contrato fue desplegado, y esto no es posible desde las consultas regulares de web3. Necesitas datos indexados.
Con The Graph, puedes crear mapeos para indexar estos Datos, los cuales vivirán en los Datos almacenados (actualmente Postgres). Así que, veamos cómo los mapeos son creados:
Archivos Importantes
Primero veamos el subgraph.yaml, el cual define todos los mapeos :
specVersion: 0.0.1
description: Gravatar for Ethereum
repository: https://github.com/rodventures/gravity-subgraph
schema:
file: ./schema.graphql
dataSources:
- kind: ethereum/contract
name: Gravity
network: mainnet
source:
address: '0x2E645469f354BB4F5c8a05B3b30A929361cf77eC'
abi: Gravity
mapping:
kind: ethereum/events
apiVersion: 0.0.1
language: wasm/assemblyscript
entities:
- Gravatar
abis:
- name: Gravity
file: ./abis/Gravity.json
eventHandlers:
- event: NewGravatar(uint256,address,string,string)
handler: handleNewGravatar
- event: UpdatedGravatar(uint256,address,string,string)
handler: handleUpdatedGravatar
file: ./src/mapping.ts
Veamos los campos importantes en este archivo:
-
dataSources: las fuentes de los Datos tendrán todos los contratos inteligentes que quieras rastrear (en nuestro caso, es sólo 1).
Todos los otros campos son autoexplicativos, así que veamos el campo eventHandles, el cual define nuestros mapeos:
eventHandles: en este campo, definiremos nuestros mapeos. Añadiremos eventos y funciones, los cuales manejarán esos eventos. Por ejemplo, definimoshandleNewGravatarpara nuestro eventoNewGravatar.file: este campo tendrá nuestro archivo Mapping, que contiene las funciones del controlador el cual esmapping.tsen nuestro caso.
mapping.ts es donde implementas los eventos de controlador… Estos eventos de controlador se ejecutarán cuando nuestro evento Gravatar es emitido, creando entidades y salvándolas en la tienda, como las hemos descrito en nuestras funciones del evento de controlador.
import { NewGravatar, UpdatedGravatar } from './types/Gravity/Gravity'
import { Gravatar } from './types/schema'
export function handleNewGravatar(event: NewGravatar): void {
let gravatar = new Gravatar(event.params.id.toHex())
gravatar.owner = event.params.owner
gravatar.displayName = event.params.displayName
gravatar.imageUrl = event.params.imageUrl
gravatar.save()
}
export function handleUpdatedGravatar(event: UpdatedGravatar): void {
let id = event.params.id.toHex()
let gravatar = Gravatar.load(id)
if (gravatar == null) {
gravatar = new Gravatar(id)
}
gravatar.owner = event.params.owner
gravatar.displayName = event.params.displayName
gravatar.imageUrl = event.params.imageUrl
gravatar.save()
}
Como puedes ver, estamos importando dos archivos: Gravity.ts y Schema.ts, ambos archivos son generados cuando ejecutamos yarn codegen. Estos archivos contienen tipos, lo cual hace que trabajar con contratos, eventos y entidades sea fácil. También tenemos schema.graphql, el cual contendrá entidades.
type Gravatar @entity {
id: ID!
owner: Bytes!
displayName: String!
imageUrl: String!
}
Nuestro archivo schema.ts es generado usando este schema.graphql y nuestro archivo Gravity.ts es generado basado en el contrato inteligente Gravity.sol.
Estos son muchos conceptos de GraphQL. Si no sabes sobre GraphQL revisa aquí, pero puedes construir un subgráfico básico con un entendimiento mínimo de GraphQL.
Construye un subgráfico para tu dApp
Si estás ejecutando una dApp, probablemente te has enfrentado a este problema de Datos.
Abajo están los pasos los cuales necesitas seguir para construir un subgráfico personalizado para tu dApp (como fue descrito arriba).
- Instala Graph-CLI y otras dependencias
- Crea un subgraph.yaml
- Crea schema.graphql
- Genera los archivos schema
- Crea un archivo Mapping con los eventos de controlador
Comandos Útiles
Graph-CLI expone comandos útiles que puedes archivarlos bajo package.json.
Hemos construído un subgráfico básico FOMO3d, ¡revísalo!
Conclusión
La mejor propiedad que las personas aún no reconocen, es que la Infraestructura Web3 permitirá aplicaciones autónomas del internet, las cuales pueden ser sustentadas, en el futuro previsto, sin necesidad de mantenerlas.
Web3 - Construye, Despliega, sin necesidad de Mantener
La descentralización y la confianza minimizada es un problema difícil de resolver. El equipo de The Graph está intentando hacer esto y construir una parte importante de la infraestructura de una dApp. Si estás construyendo una dApp escalable, ¡deberías ver el protocolo The Graph!
Sobre QuikNode
QuickNode está construyendo una infraestructura para apoyar el futuro de la Web3. Desde el 2017, hemos trabajado con cientos de desarrolladores y compañías, ayudando a escalar dApps y proveyendo nodos de alto rendimiento. Estamos trabajando en algo interesante desde hace algunos meses y lo estaremos lanzando pronto así que, ¡suscríbete a nuestro boletín para más actualizaciones!
Este artículo fue escrito por Gaurav Agrawal y traducido por Delia Viloria T. Su original se puede leer aquí.
Sería genial escucharte en nuestro Discord, puedes contarnos tus ideas, comentarios, sugerencias y dejarnos saber lo que necesitas.
Si prefieres puedes escribirnos a @web3dev_eshttps://twitter.com/web3dev_es en Twitter.
Discussion (0)