Beyond cryptocurrency tokens, the blockchain also enables analysts to get a clearer picture of practically any GameFi project, NFT, marketplace, or DeFi protocol, thanks to Footprint.
At Footprint, we’ve created a methodology that compiles and meaningfully aggregates the raw blockchain data. And this applies to programming integrations.
Let’s first talk about programming integration methods. There are a few different ways to work with blockchain data, and your chosen approach will depend on your specific needs and goals. Here is a quick overview:
A blockchain explorer is a website or tool that allows you to view the data stored on a blockchain. This can be a quick and easy way to access information about specific transactions, blocks, and other data on the blockchain.
Blockchain explorers can be a useful tool for accessing and viewing data stored on a blockchain, but they do have some limitations for software integrations. Here are a few examples of things that blockchain explorers may lack:
While blockchain explorers can be a helpful way to access and view blockchain raw data, they do have some limitations that you should be aware of before deciding to implement your solution infrastructure based on them.
Setting up your own indexer to work with blockchain data can have several advantages and potential disadvantages. Here are a few examples of each:
Advantages:
Disadvantages:
Overall, setting up your own indexer to work with blockchain data can provide greater control and customization, but it can also be a complex and expensive process. It’s important to consider the advantages and disadvantages carefully before deciding if this is the right approach.
Using a third-party indexer to work with blockchain data can have several advantages and potential disadvantages. Here are a few examples of each:
Advantages:
Disadvantages:
In summary, using a third-party indexer to work with blockchain data can be a convenient and effective option, but limited and sometimes lack customization.
The goal of Footprint is primarily to lower the bar for entering analytics and working with web3 data. This approach is a balance between ease of use and flexibility. That is why one of our services is DaaS (Database as the service type). Before we take a closer look at the advantages of our service, we will also look at another implementation option for the indexer, namely a self-written solution or SDK.
In the next chapters, we will explore the core feature that read-only blockchain APIs should have. We will look at the problem from different angles and consider alternative solutions. Some of the most important features of blockchain APIs include the following:
Ease of use and flexibility are two important features of blockchain APIs. A blockchain API that is easy to use will make it easier for developers to start building blockchain-based applications, allowing them to quickly prototype and test their ideas without spending a lot of time learning how to use the API.
Flexibility, on the other hand, refers to the ability of a blockchain API to support a wide range of use cases and applications. A flexible blockchain API will allow developers to access different parts of the blockchain and build applications that interact with different types of smart contracts and other blockchain-based assets. This can be especially important for developers looking to build applications that can be used in various industries and contexts.
Overall, having a blockchain API that is both easy to use and flexible can make it easier for developers to build innovative and useful applications that can take advantage of blockchain technology’s unique features and capabilities.
Ease of use and flexibility is ensured by our data organization, which affects all aspects of interactions with the Footprint ecosystem. Footprint has an API built on top of this data model that allows users to build full-fledged data pipelines for data analysis and machine learning applications. We call it a Data API. We are simultaneously supporting two types of API and two sub-types within one of them to cover most of the cases: Rest API and SQL API.
REST API allows us to quickly integrate an application since each endpoint is a pre-built, hard-coded script that we have identified as one of the most popular. All endpoints come with easy-to-use tools for filtering, sorting, and pagination.
Thanks to the SQL API’s more adaptable interface, you can obtain this for more specific cases. One benefit of using the same SQL queries in both the web application and the API is that it can simplify development and maintenance. By using the same queries in both interfaces, developers can avoid the need to write and maintain separate sets of queries for the web application and the API. This can save time and effort and reduce the risk of errors or inconsistencies between the two interfaces.
Additionally, using the same SQL queries in both the web application and the API can make it easier for developers to create a seamless user experience. By using the same queries, developers can ensure that the data accessed and manipulated by the web application and the API is consistent, allowing users to switch between the two interfaces without encountering any inconsistencies or disruptions.
Many alternative analytics solutions allow the user to analyze different networks according to various levels of requirements. However, for the most part, alternative solutions tend to go to extremes, implementing either a very flexible product that requires knowledge of query languages or even programming languages or a very simple interface with prepared scripts and, accordingly, low flexibility.
Solutions like Moralis and Quicknode only have a REST API interface. Even though there are many endpoints, it still limits the developer in the flexibility of the data returned.
Dune has recently introduced its API. This asynchronous solution implies the preliminary existence of a query on the platform under a certain id (dune.com/query/{{query id}}), by which it is possible to execute queries in the form of SQL. The key limitation of this solution is the need to pre-modify the SQL on the platform so that the updated query is subsequently executed.
Chainbase releases SQL API in the same way as Footprint. Still, unlike Footprint, Chainbase does not have such sophisticated ETL, so SQL queries can only be executed for raw transactions.
Blockchain APIs should be able to handle large volumes of data and transactions, allowing developers to build applications that can be used by many users simultaneously.
The Footprint team has made several architectural upgrades since its launch in August 2021, thanks to its span ability to explore and iterate on technology. In less than a year and a half, the team has been able to implement these changes successfully. This is a testament to the team’s skill and expertise in technology and data science.
Through experimentation, Footprint iteratively made three global architectural updates, ultimately arriving at an architecture that meets the requirements of the platform’s various use cases. More information on the evolution of the implementation can be found in the next article:
Within Footprint, there are two modes for executing queries to the SQL API — synchronous and asynchronous. API calls to the synchronous endpoint imply the SQL query will be executed by the Footprint servers as soon as an HTTP request is received from the application, thereby maintaining the connection. This makes sense when using lightweight requests, as in this case, the application does not have to wait long for execution. The details can be found on the following page:
For heavy requests, it is recommended to use an asynchronous request. Unlike a synchronous one, the client application does not have to maintain a connection with the server during execution. Instead, it can get the request-id immediately, according to which, after some time, separately get the execution results. As part of the asynchronous API, two-step should be covered to fetch the data — the following endpoint will be used to send an “order” for SQL execution:
The second step is to send a request to receive results by the identifier obtained when accessing the previous endpoint. The endpoint for this second step is described on the following page:
DuneV2 changes the whole database architecture. Dune is now transitioning away from a PostgreSQL database to an Instance of [[Apache Spark]] hosted on [[Databricks]]. Only asynchronous API.
Blockchain APIs should be compatible with a wide range of programming languages and development environments so that developers can use the tools and frameworks they are most familiar with.
REST is easier to integrate since each programming language has many libraries that provide comfortable work with this type of API. However, in the end, both SQL APIs and REST work over HTTP, so the development experience is almost identical regarding sending a request by default.
As we have analyzed, in most cases, it is enough for an application to use ready-made DaaS solutions for the reason that they can return abstractions (not just raw data) and save a lot of time and money, as they ultimately allow teams to focus not on infrastructure but on the value of the product. Going through various solutions in the DaaS market,
Footprint seems to be the most optimal to integrate, as it has the most flexible model for generating requests while being both easy to use and also having the modern open-source data stack under the hood, which ensures uninterrupted and, most importantly, fast execution of the most complex requests.