In phase 2 we have to evaluate subgraphs and answer these questions about a subgraph:
- How would you describe what the subgraph does?
- Does this subgraph look production ready?
- Does this subgraph look like it would be useful to others?
- What changes would you make to the schema including additions or modifications to entities, fields, field types, relationships, or any other improvements?
- Are there any other subgraphs that do similar things? How does this one compare?
- Identify the degree of completeness, complexity and accuracy of the implementation
Based on the WorkShop Video provided to us and on my own experience I will tell you some tips which will help you in answering the above questions.
So Basically there are three major components of any subgraph:
1) The GraphQL Schema
The subgraph schema is Store structure of your entities. The schema for your subgraph is in the file schema.graphql. GraphQL schemas are defined using the GraphQL interface definition language.
A simple single entity schema for an token to store info would be like:
2) The Subgraph Manifest
The subgraph manifest subgraph.yaml basically defines which smart contract you want to index. Also what events in that smart contract you want to listen to.
3) The Mappings
The mappings transform the Ethereum data that you are sourcing into entities defined in your schema. Mapping file is written in typescript and can be found in src/<file_name>.ts file.
Now we know what a subgraph is mainly made of, lets see what to look for while evaluating a subgraph:
- Before going into the subgraphs and its component, You must fully understand which contract this subgraph is for.
- Go to the github look into the code for subgraph, In the subgraph manifest you can find the contract address, go to etherscan and go through the contract.
- See the front end of the website
- Now you know which subgraph it is and how it is being used, Its time to dig deep into the subgraph itself
- I always start looking into the schema first, it will give a clear idea of what we are storing and what is useful to us.
- Then Go through manifest file and see what event it is listening to
- And then go through each mapping file to dig deep
- If the mapping is simple like one to one mapping. Eg: We are just getting data from blockchain and putting into our entity then the complexity of the graph is low.
- But if we are aggregating stuff lets say we have a total volume today field for a token in the schema . To provide value to this field we may have to aggregate all the transaction. Complexity of this graph would be rather high.
- At last dont forget to give suggestion for improvement for example you could say this entity should have one more field and how that field gonna provide value to the subgraph.
At last fill the form and wait for the phase 3 to kick in :)
