#95 Open-Source DApp API - Milestone 1
We believe that the DApps ecosystem will benefit from a common core API that each parachain can integrate (and extend) to index and expose their chain data for future consumer facing applications (e.g. a wallet, explorer, or other dApp).
There will be 3 individually proposed milestones delivering open source projects, packages, and associated learning material to help decentralised app developers start building applications on Polkadot/Kusama
Who
This is a joint proposal between two parties - SubQuery/OnFinality and Fearless Wallet/SORAMITSU
What
- Create an Open-Source SubQuery Project for Common Data
- Document and Publish Learning Material and Tutorials
Outcomes
- Improve the Interoperability of DApps and Parachains
- Attract and Support More Developers in Kusama
Milestone 1
This proposal is for the 1st milestone only.
Design and publish the proposed common GraphQL API definition for Kusama that the remainder of this proposal will deliver. This will be published using a GitHub repository and a GraphQL documentation tool (like Graphdoc).
We will then reach out to the community for consultation and ideas around how we can improve this API (and the models within it) for more general use across different types of dApps.
Show More
Report
Through a collaborative process, OnFinality and Fearless Wallet have worked together to design a common API interface and its first implementation for Polkadot/Kusama.
Our view is that this API should be able to provide applications with a sufficient (but read-only) view of all key data within the chain. E.g. a developer could use it to create their own chain explorer without needing to directly query chain data.
We’ve published the core API interface here on this public GitHub Repository and have also published it using GraphDoc to this website for ease of access. You’ll need to mainly look into the schema.graphql file, as this is where the bulk of the relevant work has been done (see background in our documentation). Additionally, we’ve extended it for Kusama/Polkadot specific use cases (e.g. staking rewards and more) in it’s first real implementation here on this public GitHub Repository. Similarly, this implementation is published here.
One key thing to note with our core API interface is that the design should largely work across any parachain. We’ve written it with existing parachains like Karura and Moonriver in mind. As an example, you can see this approach with the way we can handle multiple assets on AccountBalanceHistory.
You’ll see that there are some open issues in each Github repository. These APIs are intended to be constantly iterated and improved over time (with considerations to backwards compatibility). We invite the Polkadot community to provide feedback directly via GitHub in the form of issues and pull requests.
This looks like an API I have been waiting for, and it has much to offer being a collaborative effort. Some simple questions, if that's ok:
- How will this differ in respect to the current subscan API for example?
- Is the intention that users would be able to install this on their own archive node to use or will it be available via public end points? (or both?)
Q1. I haven't gone deep into the Subscan API myself but here are a few things:
- Community owned - this API design will be open source and guided by the community as much as possible
- Configurable - The API and the SubQuery services required to run it are open source. You'll be able to fork this repo, make changes to suit your application, and then run it yourself for your own bespoke needs in only a hour or so.
- Less integration effort - We've head anecdotes that integrating with Subscan takes time, and with a new parachain team joining each week (at the moment) we wanted to provide an alternative with potentially less implementation time. We're already working with parachain teams (see Acala, Bifrost, and Darwinia) and we've had plenty of practice integrating SubQuery with custom chains
- Deterministic - SubQuery only allows you to index data that is on chain and deterministic. We don't plan to provide non deterministic data through this API (like prices etc)
Q2. Both
- SubQuery's indexing and query service are open source and always will be. A individual can run their own infrastructure in docker or by using common cloud resources (some of our customer do). See our setup guide
- The SubQuery team provides a free managed service where we will run this in our managed environment and provide access via public endpoints.
Thanks @james_bayly for the details, this is what I hoped you'd say - a move in the right direction for sure.
Discover similar proposals
