This article is the final part of a 3-piece series:
- The Graph and Its Contribution to dApps and Blockchain Development
- Demonstrate Subgraph Structure on 2key Subgraph “The Graph”
- One Referral Graph to Rule Them (Blockchains) All — Using 2 Subgraphs on 2key dApp to generate the referral map
What is the referral map?
The 2key content tracking system:
- Tracks the virality and progress of your campaigns.
- Manages the campaigns and provide feedback for your influencers.
The referral map reflects the 2key tracking system and allows you to view the social path of your content.
Each node in the referral map tells a story about how users engage with the campaign:
- Did the user sign in, or is participating a guest?
- Who shared the campaign?
- Who made a purchase (conversion)?
- Who are your influencers?
- How are funds distributed among your users?
After exploring the graph-node technology, we at 2key saw the potential of combining the information from our two blockchains to generate the referral map much faster.
Why we created our own infrastructure to use graph-node
We at 2key realized that we could benefit from using the graph-node’s indexing power with our complex smart contract state machines, which are spread on two blockchains. So, we committed to the graph-node technology and set up an in-house infrastructure for running graph-node to support the smart contracts deployed on our managed blockchain.
Currently, it is fully integrated into our application.
Note: “The Graph”-hosted solution for graph-nodes only allows hosting Subgraphs on Ethereum’s Mainnet/Testnet. In addition, it does not support indexing privately maintained blockchain infrastructure like 2key does.
Before using graph-nodes, generating the referral map, required sending multiple calls for both public and managed blockchains to generate each node in the referral map.
Now, we use only two calls, one per Subgraph, to generate the referral map in our dApp. Those calls fetch all the needed information and remove the burden of endless calls to fetch the current state directly or indirectly with the Backend.
Public contracts query example:
campaigns(where:{id:"0x68007f3133d7ed8008ab2c3a9e7880d9490597e5"}){
id
_owner{
id
_web3Address
_name
_email
_fullName
_walletName
}
_rewards{
id
_amount
_user{
id
_web3Address
_name
_email
_fullName
_walletName
}
}
_joins{
_to{
id
_web3Address
_name
_email
_fullName
_walletName
}
_from{
id
_web3Address
_name
_email
_fullName
_walletName
}
}
_conversions{
_fiatAmountSpent
_ethAmountSpent
_status
_tokens
_participate{
id
_web3Address
_name
_email
_fullName
_walletName
}
}
}
Plasma contracts query example:
campaigns(where:{id:"0x68007f3133d7ed8008ab2c3a9e7880d9490597e5"}){
_visitors{
_referrer{
id
_handle
_web3Address
}
_visitor{
id
_handle
_web3Address
}
}
}
After fetching the two calls, we merged it on the Frontend to create one referral map.
