Hi! I had been thinking for a while about putting together an App that creates ERC-20 based subgraphs using the latest library from Open Zeppelin.
Fig.1 Users can add their deploy token (wrong labeled in the image as “API Token”) for a specific previously created subgraph (1). After pasting an ERC-20 token address (2), a request is sent to a backend where graph-cli is already installed (3), replacing the contents of the Open Zeppelin library. This is then pushed to Studio (4), and shown to the user in the original App (5)
For this to work, the App needs to deploy on behalf of the user, which requires the Subgraph deployKey that you only get access to via the Studio. We can either ask users to go to Studio and create the subgraph and copy the deployKey, or to simplify things I can log in on behalf of my users by forwarding the login signature to https://api.studio.thegraph.com/graphql using login as the operationName and afterward get the deployKey via the currentUser query. It might not be obvious, but by doing this, the App would require users to “trust” the backend does not man-in-the-middle the whole traffic. Not very aligned with web3 values.
(Unfortunately, due to CORS (yes, even using mode: 'no-cors'), a web App can not log in to Studio directly, and the server would simply return a 500 HTTP status code error)
Here are a few questions related to this tool:
- Does it make sense within the community to have something like this? Are we interested on onboarding subgraphs created by perhaps not-so-technical users?
- Are third-party/community solutions expect to create Apps that run a backend that talks to the Studio API and behave like proxies between client-server communication?
- Is TheGraph team thinking in allowing CORS-based calls to
api.studio.thegraph.com so any front-end can reach TheGraph Studio backend w/o relying in the Studio?
- Would it be better for the project to develop these sorts of apps as add-ons (i.e. via a chrome extension, desktop app or similar) to enhance the existing functionality of the Studio rather than building apps that replace/enhance it from scratch?
- Is the team thinking of exposing an official API for the Studio? Right now anyone can reverse engineer the calls that the client is doing, but it would be better to have an official one.
As a final question, albeit a more philosophical one, what happens if the Studio or its API go down? Considering the latest events in Uniswap where some access to specific tokens were blocked mostly by the UI, would it be fair to say that right now we are still relying on the Studio to provide users with gateways to deploy subgraphs within the ecosystem? I know everything is open source and that there’s a Subgraph for Subgraphs, but asking whether there’s an option for further decentralization on a doomsday-like scenario.
Thanks and looking forward to the feedback!
7 Likes
Hello Jose!
This is a very interesting idea, thank you for exploring this! I wanted to share a few thoughts:
Here is what happens for now when you use the classic flow to publish a new subgraph to the network:
- You create a subgraph in Subgraph Studio
- You deploy the subgraph code using the CLI (it basically compiles a subgraph to WebAssembly and generate an IPFS hash for it) - for this step we require a
deployKey and the subgraph-slug to match it against the Studio
- Then you can use the Studio to publish the subgraph to the decentralized explorer calling the
publishNewSubgraph method in our contracts
The Studio is here to make the life of developers easier but is not required to publish new subgraph (neither is the deploy key).
Based on your idea, what you would have to do to bypass those steps would be to:
- Generate automatically the subgraph code when the user submit its token address (using OpenZeppelin template)
- Compile the subgraph code to WebAssembly (to replicate what we do in the CLI). The Graph CLI is open-source so you can explore how we are doing it.
- Generate an IPFS hash for it and propagate it to the IPFS network
- Then let your users call the
publishNewSubgraph method by passing their address as a parameter and the deployment hash you just generated
By doing so you won’t have to interact with the Studio to create and publish subgraphs.
Let me know if you have any questions!
Baptiste
2 Likes
Thanks for the quick reply!
This is awesome! I wasn’t aware of TheGraph smart contracts so this was exactly the pointer that I needed. To be clear, you mean this publishNewSubgraph function right? I can see how this is being done in the cli tool, and the mainnet GNS.sol contract address (0xaDcA0dd4729c8BA3aCf3E99F3A9f471EF37b6825) should be enough to get started (or I’ll play with the Rinkeby one for testing).
As I’m used to the legacy explorer, what’s the usual ETA for a subgraph to be indexed by any Indexer, and where that information can be requested in TheGraph architecture? I’m assuming the Subgraph of Subgraphs, but yet another pointer wouldn’t hurt 
For example, assuming I create a GRT token indexer using OZ’s library with today’s block, how quickly could my App query from somewhere (that same contract?):
- The Subgraph ID of the successfully published Subgraph?
- An available endpoint for it to start querying data?
Last but not least, I’m assuming the Studio is setting up the billing addresses workflow to also simplify address, but what’s the architecture for using any Web3 address and filling it w/Polygon bridged GRT so it can use it for query? Where I am going is that ideally the wallet used to query is something that’s poolable or that can be sent money to by anyone using the App.
If you have a link to have a general overview of all the protocol architecture (ie Smart Contract, the Studio FE, the Studio API, etc) I’ll happily read it on. There’s a notion.so link in the contracts repository but seems to be only available to the Edge & Node team. Thanks!
Hey Jose, good to see you here!
To answer some of your questions:
- Indexers decide according to different considerations which subgraph to index, mainly how much GRT is signalled. Read more about it here: Curator | Graph Docs. That said, there is no guarantee that a indexer indexes your subgraph. Which brings me to the next point:
- So one of the main questions for us to answer is: Do we want to open up the Subgraph Studio indexer, so people can create/deploy subgraphs there programmatically for testing? As you already said, it is currently possible with reverse engineering and circumventing the CORS.
Currently, the Dapp-teams create a API key and pay for the query fees on behalf of their users. Eventually, users will start to pay for their queries by themselves. So if you add the function to your app, that users can add their personal API key, that would give bonus points.
I am also open to walk you through our whole stack in a Zoom session. Feel free to DM me on any channel so we can arrange a meeting.
1 Like
Hey @schmidsi, thanks again for the chat! I had some important learnings worth sharing here:
- The Studio provides an initial indexing ability to subgraph developers thanks to an Indexer provided by TheGraph. However, in an isolated setting (i.e. an external app), this can not be guaranteed w/o having to signal the subgraph or deploying it via an indexer.
- Subgraph developers are incentivized to publish meaningful subgraphs as they have the option to be the first* ones to signal and benefit the most from the queries done against them. Thus, quality over quantity approach makes sense the most, which is hard to guarantee via a noCode tool, since it could be easily spammed w/o any guarantee for indexers.
Based on these learnings, I’ll tweak the proposal to instead of pushing for noCode tooling, deploy specific subgraphs as recipes that can be used either within an app (that would deploy be in charge of deploying specific subgraphs) or that anyone can use. I’ll mark this thread as closed and come up with a different proposal in a separate one. Thanks, everyone!
3 Likes
