Jan 10
The Graph — Google of Blockchain
Today, MochiLab will introduce the use and usage of this platform.
Talking about querying data on blockchain, many people will think of using Ether.js or Web3.js to query logs in the past. We also initially used this query log, for small data and less nested recursion, it is quite simple and effective. Like when we encountered a number of nested and complex queries, we lost a lot of time and sometimes made errors. Then we researched and was suggested to use The Graph and when we used it, we found it really useful. If you’re passionate in Blockchain, let us introduce it to you!
Introduction
The Graph is a decentralized protocol used for indexing and querying data from blockchains, first from Ethereum. There are some types of data that are difficult to query directly, so The Graph was born to support this.
For example, with a well-known Dapp like CryptoKitties, there will be a fairly simple question that is:
“How many CryptoKitties does a particular Ethereum account have? When was a particular CryptoKitty born?”
In the above question, we can easily use the balanceOf and getKitty functions defined in the contract to know the above information.
But there will be a more difficult question that is:
Who are the owners of those CryptoKitties created between January and February 2018?
To answer this question, you have to get all Birth events and then call the OwnerOf function of each Crytokity that was created. Even though a question sounds so simple, for ordinary Dapps it can take hours, even days to get results. Indexing blockchain data is difficult because the data architecture, the structure of errors or untitled blocks further complicates this process and makes it not only time consuming but also difficult in terms of technical aspects. Retrieve blockchain data accurately.
The Graph was born to solve this problem by building a service that stores indexed blockchain data. These data are (“subgraphs”) which can then be queried using a GraphQL API like calling regular APIs. This brings convenience to Dapp programmers and also improves user experience because query tasks are now cached and indexed, helping to significantly increase query speed compared to normal often.
How does the Graph work?
The Graph indexes the index based on a subgraph description called the subgraph manifest. The subgraph description will define which smart contracts a subgraph needs to subscribe to, the events in the contracts, and how to map these events data to The Graph to store it in the database.
Once the subgraph manifest has been written, the Graph CLI will be used to store those definitions on IPFS and then the hosted service will start indexing the subgraph’s data.
Below is a detailed diagram of the flow data of a deployed subgraph manifest, this example is a transaction on Ethereum
Flow will be performed according to the following steps:
- A Dapp that adds data to Ethereum through a transaction on a smart contract
- Smart contract will emit one or more events during transaction processing
- The Graph Node is constantly scanning new Ethereum blocks to find the data the subgraph needs
- The Graph Node looks for matching Ethereum events in these blocks and executes the mapping handlers defined in the subgraph manifest. Mapping is a WASM module that creates or updates the data of entities that the Graph Node stores after being queried from Ethereum events.
- Dapps that want to query data that have been indexed and stored by Graph Node will need to use the GraphQL endpoint node. Now it’s Graph Node’s turn to translate GraphQL queries into store data queries to fetch the data here, taking advantage of the store’s indexing capabilities.
- After receiving the data returned, the Dapp will show it to the user
- A cycle repeats itself
The usage of the Graph
There are two ways we can use the graph for development:
1. It manually builds a graph node locally then deploys the subgraph and executes the query in the Ganache test environment
2. To deploy the subgraph directly to the node of The Graph to then query. This way, we can redeploy to update the subgraph
- https://thegraph.com/docs/define-a-subgraph
- https://thegraph.com/docs/graphql-api
- https://thegraph.com/docs/quick-start#hosted-service
Both have the same architecture that will have a Graph Node and then deploy Subgraph on it to query data. In the scope of this article, my main goal is to teach people to deploy a subgraph and then execute the query. So Mochi will gradually follow the 2nd way to the 1st way. MochilLab also has the link pinned above everyone can see and follow those steps.
Like the link, we attached above is something we need to read to understand before we want to write and deploy a subgraph for ourselves.
Define Subgraph
This is the part that defines the data that will be stored and indexed. This subgraph will include a number of main files such as:
1. subgraph.yaml : is a file containing the config subgraph manifest
2. schema.graphql: is a GraphQL schema that defines what data should be stored and how this data can be queried from GraphQL.
3. AssemblyScript Mappings: These are AssemblyScript codes that will convert events in the blockchain that it hears into entities according to the schema that we have defined in the schema.graphql file (its name is usually mapping.ts )
Before going into the details of the main contents of this section, we will need to install the Graph CLI to use for building or deploying a subgraph.
# NPM
npm install -g @graphprotocol/graph-cli
# Yarn
yarn global add @graphprotocol/graph-cli
Follow MochiLab here:
Follow Mochi.Market here:
Website | Twitter | Telegram Chat | Announcement | Medium | MochiPad
In upcoming days, MochiLab will boost our interaction on existing channels to create more practical values for the community, on the other hand, expand new channels such as Tiktok, Youtube…
Let’s look forward to our next information!
