We are in the process of porting over our project JOBGRADER onto Bitfinity. As we are using GraphQL on our other implementations and we believe that this is a de facto standard in WEB3, we are asking this forum regarding plans or implementations in Bitfinity so far regarding GraphQL.
A possible solution would be to set up a custom node from the community as described here:
What are your thoughts about this?
I would love to see Graph Protocol indexers built on the IC, it’s something I’ve been wanting to see for a few years now. I have a lot of experience with GraphQL on the IC having built Sudograph. I’m happy to answer questions.
Hi Jordan,
Great to hear from you.
I looked into Sudograph and it seems to be one part of the puzzle.
When it comes to Bitfinity there would be either the need to get in touch with the guys from GraphQL to ask them for indexing it, or Dfinity or the community set up a node for indexing. I am too new into Dfinity to tell if such an indexer could work inside a canister, but I would doubt it as the index can grow quite fast.
Have you seen this tutorial: Deploy Subgraphs to Any EVM. Using Docker, The Graph, Graph-Node and… | by Leon Do | Coinmonks | Medium
I guess if we use the RPC from the Bitfinity network, then we would be one step further.
How much data is the indexer going to be holding?
| Minimum Specs | Recommended Specs | Maxed out Specs | |
|---|---|---|---|
| CPU | 16 vcore | 64 vcore | 128+ vcore |
| RAM | 32 GB | 128 GB | 256/512+ GB |
| Storage | 300 GB SATA SSD | 2 TB NVME | 8+ TB NVME RAID 10 |
@lastmjs Important to understand is that this would be a globally usable service for the whole IC and Bitfinity ecosystem and not for a single application/project. I guess you are aware of the capabilities of GraphQL, so you sure know that this should be a top priority to get more devs into the space.
Would be tough to just put into a single canister…probably a multi-canister approach would be necessary, which is also tough.
Why would this be difficult to handle with both a single canister and multi-canisters?
A single canister probably does not have enough storage capacity and might run into other computational resources limits, and multi-canister is incredibly complicated due to lack of atomicity across canisters when performing update calls, and the added complexity of having to shard the database essentially.
Cool project.
You could probably have graphQL indexers that index data from individual smart-contracts hosted on the IC. The whole EVM would be a challenge though. 100GB limit within a canister currently.
I see it the same way that it would be a challenge @Maxfinity. I am not deep enough into canisters to evaluate. Another way would be to attach a storage like S3. I do not know the capabilities of canisters in terms of storage.
As long as the network is not heavily used, the GraphQL will not need that amount of storage, but I do not know if the extension of storage is possible at a later stage.