ProjectX IDE Proof of Concept
This video goes over the IDE’s front-end and GraphQL back-end, showing a few demo queries and subscription messages along the way,
In an article we published last month, we detailed our plans for bringing GraphQL onto L3 Atom. We’ve been working hard to develop a proof-of-concept that will allow our users to play around with our back-end in a variety of different ways all through a single GraphQL endpoint. We’ve now launched that proof of concept, and it’s available for anybody to use and start playing around with our data lake. It can be accessed here:
The front-end is an embedded version of Apollo Sandbox, a GraphQL IDE that is typically used by developers to test their endpoints. It features a schema visualiser and the ability for queries to be constructed without typing any code, as well as GraphQL subscriptions, a feature that we’ve taken advantage of on our back-end.
You’ll notice a button that will prompt you to sign-in with Metamask. This isn’t a working feature yet; it’s simply a proof of concept for what will come in the future. Clicking on this button will (assuming you have Metamask installed) prompt you to connect your wallet and then sign a message
This is effectively how the sign-in process will work — by signing a random nonce, you can prove to our back-end that you possess the private key to the wallet you’re claiming to own. In the full release of the IDE, we aim to let users sign-in completely via Web3 technology, not having to remember a username-password combination and trusting us with keeping that secure. This method of singing-on doesn’t require us to store any sensitive information like your private key, and so it’s a popular method used by dApps.
We’re running an Apollo GraphQL server for our back-end. Apollo handles a lot of the work for us, and has some nice features that make scaling easier as we bring in more data sources. It’s also the industry standard, and so has an abundance of resources and documentation. As of right now there are three main data sources that the server will route requests to/from, and so we’ll detail them below.
Making a query for the
lobEvents type or the
trades type will route your request to our historical data base which is partially in-memory, partially on disk. Apollo interacts with the database via a REST call, passing through your requested fields and filters to not get more data than it needs to (doing most of the processing on the database’s side instead of on the GraphQL server’s side). As this is a proof of concept, only the past 5 seconds of data will be shown. Keep in mind, however, that even in that time frame, you’ll still get a plethora of trades and LOB events data as you’ll be collecting from 10 exchanges at once (unless if you filter it down). An example query is shown below which queries the prices and sizes from both the LOB events and trades that have occurred over this 5 second time frame.
Our on-chain types route your queries directly to an Ethereum node which makes the appropriate JSON RPC call to get the data you need. e.g., if you’re querying a block, the server will call the
get_block method, getting the full transaction data alongside it. Similarly, you can get account balances and transaction data by passing in the address and transaction hash, respectively. An example query with all fields is shown below.
While most implementations of GraphQL serve only queries, there exist libraries and frameworks that allow for live data to be served, typically via Websockets. For this PoC, we support GraphQL subscriptions for our live trade data. Users can send subscription messages specifying which exchange they want to subscribe to the trades of, and, of course, can fully specify which fields they want in their response body. Think of this feature as similar to our standard websocket server, except it has the customization features of GraphQL An example subscription message is shown below which subscribes to Binance’s live trades.