InfoGraph Product Proposal
Abstract
InfoGraph will be a data analysis tool built on The Graph protocol. It will allow its users to create custom dashboards with little to no technical knowledge. Dashboards will track data on one or more of The Graph subgraphs and present insights via various charts & infographics. Dashboard creators will be able to publish their dashboards publicly/privately (as in Github), and their target users will be able to use them for their analysis needs.
Motivation
Getting useful insights from The Graph currently requires technical expertise. Users need to understand the subgraph schemas, write GraphQL queries and possibly use data analytics libraries to put the data into a useful format. The majority of those steps can be generalized, and an application with an easy-to-use interface ─that enables end users to make analyses that they couldn’t easily make otherwise─ can be developed.
Target Audience
Analysts/traders/investors who may or may not have technical ability.
Feature Overview
Visual Dashboard Editor
InfoGraph’s default dashboard creation environment; is an easy-to-use, no-code drag-n-drop graphical user interface to create & edit data dashboards that are connected to desired subgraph(s) and present results in various charts & other widgets.
Several presets will be made available based on our estimation of the most wanted datasets & use cases. These presets will be constantly updated based on user feedback & usage statistics.
Examples of graphical components that will be easily added to dashboards:
- Charts such as histograms, line/area/pie charts, heatmaps, and more
- Widgets for sorting, filtering, enriching & manipulating data
An AI assistant to help with the dashboard development process is planned as well.
Computed Datasets
While the data available in existing subgraphs will be sufficient for the needs of most users, we also predict that a significant part of our users will want to use data that can be computed using their target subgraph(s) even if not readily available.
GraphQL is very powerful and flexible when it comes to data fetching but less so for data manipulation. Therefore, an additional layer must be introduced for such computations. This additional layer is intended to be the analog of the use of SQL in relational databases (and compatible systems such as Dune Analytics).
As mentioned in the previous section, the visual interface is already planned to include widgets for enriching & manipulating data. But for the cases where those widgets might fall short of covering a demanding user’s needs, we also want to offer a more advanced interface that gives users with technical ability unlimited power. That interface, of course, is code. Some people like to joke that the most useful component in no-code apps is “that little box where you can write code.” We wouldn’t want to deprive our users of it, even if we will develop a visual interface that will cover as many scenarios as possible without resorting to code.
Our little box is going to be an optional advanced feature that will store the code of what we call the “subgraph data transformation middleware .” This middleware will receive the data from the source subgraph(s), and its output will be sent to the visual dashboard editor. Hence the users will be free to manipulate/aggregate the data with complete freedom before it is handed over to the visual dashboard editor for further processing & visualization.
The planned language for this feature is Javascript because of its popularity, ease of use, and familiarity among the GraphQL community.
The users of this feature will be presented with the options of:
- Writing custom Javascript code where they can map/filter/reduce the source data as they wish.
- Writing in a Javascript subset DSL that will be specifically designed for the types of transformations that this feature is intended to be used for, à la MongoDB’s aggregation pipeline (which we might also directly adopt): https://www.mongodb.com/docs/manual/core/aggregation-pipeline/
Subgraph Editor
In addition to the ability to create computed datasets, InfoGraph will also offer interfaces to create brand-new subgraphs.
There will be both visual and code variants for this subgraph editor.
We want to offer this as an additional feature as, in some cases:
- The data may not be readily available in the existing subgraphs.
- Compared to the features mentioned above, the implementation cost of a new subgraph may be lower.
- The performance may be higher.
Also, this feature is useful in its own right and will help the community to create more useful subgraphs.
Social
Users will be able to:
- Give access to other users to collaborate with them on the dashboards they own
- Follow dashboard creators of their choice to be updated on their actions, such as the publication of new/updates on existing dashboards
- Like, comment on, and share the public dashboards of their choice
- Fork public dashboards of their choice to create their own variants
- Curate dashboard lists
- Create portfolio pages to showcase their work
Subgraph Caching
Subgraph data will be cached periodically for better performance as well as to control the cost of querying. Users will also be able to export this data if they wish. Since it is quite tedious to get a not-small amount of data directly from the subgraphs currently, this feature will improve user experience.
However, in case the user wants to get the data directly from the subgraph (instead of the InfoGraph cache), possibly because of centralization concerns, they will be able to query the subgraphs directly.
Business Model
Our primary focus is to address the need within The Graph community and develop a tool that simplifies the creation of informative infographics directly from subgraphs. Consequently, we don’t intend to monetize this venture as a standalone business; we see it as a contribution to The Graph ecosystem. If The Graph Foundation agrees that such a tool is needed, we are prepared to undertake its development and ongoing management.
Timeline
We anticipate a development period of approximately six months. Of course, these will depend on the agreed-upon details. We will give a more strict range and deadline after specifying the acceptance criteria.
To break down the development timeline, we propose two phases. The first phase, lasting two months, will involve creating the core structure and a demonstration dashboard. This demo product will serve as proof of our capabilities to deliver the full-scale version.
In the second phase, we aim to implement most of the features outlined in our product proposal. We can discuss the inclusion of other features in a potential phase 3.