Subgraph Evaluation: the new life of curators
On the second Phase of Curations, curators need to evaluate the subgraphs and answer the main question — Does this subgraph look production ready?
To do it, at the beginning curators need to take a look at these subgraph items and describe the subgraph:
- “Subgraph name” and the user who created it. Using this name we can search in The Graph Explorer other subgraphs that do similar things, especially we need check duplicates in names, that is why we need to see the user who created subgraph.
2. “Syncing (100%)” and the number of blocks listed.
This represents how current this subgraph is, and if it is fully synced to the mainnet or the network which it resides on, then it will be “synced”. Some subgraphs could be in the process of “syncing” which just means they are catching up to the number of blocks released by the blockchain so they are current.
3. “Github” and the URL below shows the link to where the subgraph code resides, and you can check this link to better understand the code structure and its complexness. For investigation, we can open “subgraph.yaml” to get some more basic information about the subgraph.
4. “ID” contains the id of the subgraph manifest (subgraph.yaml) that is stored in IPFS. The manifest is a good place to assess the accuracy of the subgraph by ensuring that the correct contracts are referenced, the most updated ABI files are being used and the correct event/call handlers are inputted. It also shows how raw data is mapped to entities helping us assess whether the naming convention of entities is easy to understand.
5. “Queries(HTTP)” shows us how the user can query that specific subgraph.
6. “Network” refers to which network the subgraph resides on, and when it says “mainnet” it shows that the subgraph is production ready since it is not located on a testnet like Kovan or Rinkeby.
7. “Last updated” is the time the subgraph was last modified.
8. “Created” is the time when the subgraph was built.
9. “Entities” define the data that will be included in the subgraph. You can check it in the related Graph docs. It may be useful to imagine entities as “objects containing data”, rather than as events or functions.
10. “Project description”, which tells us about the project the subgraph is built for.
Now that we have a basic understanding of those different categories, let’s look at the rest of the Uniswap subgraph page.
The next step is to understand the status of the subgraph. Does this subgraph look production-ready? In order to answer this question there are some point to follow:
1. Evaluate the playground, run a query to verify if the subgraph is working fine.
2. Evaluate the Manifest file, which is a set of instructions on how to build the subgraph and is called subgraph.yaml. We need to verify which network is in use and if the contract address is the production one (for the etherscan research).
3. Evaluate the schema The schema will provide information on how complete and how useful the subgraph is. It will show the entities that can be queried and the values that are held within each entity.
4. Evaluate the GitHub code. Verify is the number of contributors in the GitHub repository. The idea is to check if there is a team supporting the subgraph.
Thanks for reading!
If you’re interested in learning more about The Graph, check these resources:
· Telegram
· Discord
