This month in curation #17 | July 22

This month:

  • The Graph Client is the best way to interact with The Graph. It will save developers immeasurable time and energy!

  • Harmony support is added on the Hosted Service.

  • The Graph integrates with EPNS

  • A brief summary of GIP-0034 and GIP-0035




The Graph Client 1.0

The Graph Client 1.0 was announced at Graph Day. It was presented by Uri Goldshtein, founder of The Guild.

Uri highlighted a guiding idea in the development of The Graph Client: Utilizing the best tools should also be the easiest. The Graph Client is not only the best way to interact with The Graph, it’s the best way to interact with GraphQL in general. It will save developers immeasurable time and energy!

  • The presentation of The Graph Client was recorded, and can be found here. I highly recommend watching this and the other presentations from Graph Day. The playlist can be found here.


Documentation, examples and tutorials

With ease of use as a guiding principle, The Graph Client has very thorough documentation.

  • GitHub. GitHub repo for The Graph Client

  • Architecture. This readme gives an overview of The Graph Client Architecture, both in Standalone mode and when integrating with a GraphQL client. It also illustrates Subgraph composition and different Subgraph execution strategies (Fetch strategies)

  • Examples. This folder contains no less than 12 examples, each showcasing different features.

  • Tutorial. This tutorial by graphql.wtf outlines how to use The Graph Client to automatically generate a fully typed SDK to query the Ethereum network.



Features

In this section, we take a look on some of the features of The Graph Client 1.0

  • Fetch strategies

    • The Graph Client adds support for multiple fetch strategies: timeout, retry, fallback, race and highestValue
  • Client-Side Composition

    • The Graph Client has built-in support for client-side GraphQL Composition powered by GraphQL-Tools Schema-Stitching. This feature can be leveraged in order to create a single GraphQL layer from multiple Subgraphs.
  • Cross-chain Subgraph Handling

    • This feature makes it possible to utilize similar subgraphs as a single source. This is specifically developed for Cross-chain Subgraph Handling.
  • Local (client-side) Mutations

    • Due to the nature of Graph-Client setup, it is possible to add client-side schema, that you can later bridge to run any arbitrary code. This is helpful since you can implement custom code as part of your GraphQL schema, and have it as unified application schema that is easier to track and develop. This means you can add any GraphQL operation (query, mutation, subscriptions).
  • Automatic Pagination.

    • The Graph Client comes with automatic support for pagination. You do not need to make multiple queries when fetching larger datasets
    • See Automatic unlimited pagination for more info
  • Typescript support

    • The Graph Client CLI comes with a ready-to-use configuration for GraphQL Code Generator and it can generate TypedDocumentNode based on your GraphQL operations.
  • Automatic Block Tracking

    • The Graph Client implements automatic block tracking using number_gte
      filter of graph-node. This automates the process of fetching and tracking the block number of entities.
  • Build time validations & optimizations

  • Integration with @apollo/client and urql



The Graph’s Hosted Service has completed a beta integration with Harmony Protocol

  • Harmony is a layer-1 blockchain using sharding and Effective Proof of Stake to achieve scalability, security, and decentralization.

    • Effective Proof of Stake encourages decentralization of validators, and sharding shares the network’s load among validators, delegators, and users.Security against single shard attacks is achieved by leveraging 250 nodes per shard and cryptographic randomness to re-shard regularly.
  • To learn more about Harmony, see: Harmony.one | Messari Report | Whitepaper

  • Read the full announcement on Twitter



The Graph integrates with EPNS

  • EPNS (Ethereum Push Notifications Service) is a notifications protocol which enables web3 users to receive notifications. Using the protocol, dApps, smart contracts or services can send notifications to web3 users in a platform agnostic fashion (mobile, web, or user wallets).

  • This integration enables subgraph developers to trigger customized notifications from within subgraphs.



Graph Improvement Proposals


GIP-0034: The Graph Arbitrum devnet with a new rewards issuance and distribution mechanism | Forum | HackMD | PR#571 | PR#582

  • This GIP introduces a new deployment of The Graph Protocol to the Arbitrum One Layer 2 blockchain.

  • It proposes a plan to run the protocol on Ethereum mainnet (L1) together with the protocol on L2 instead of fully migrating in one go.

    • The community would gradually move to L2 by starting with a “devnet” phase, in which indexing rewards are disabled, and then slowly increasing the amount of rewards in L2.

    • To enable this, this GIP also proposes a change to how rewards are issued and distributed: instead of minting on the RewardsManager when allocations are closed, rewards would be pre-minted with a drip function in a new Reservoir contract. This function must be called at least once per week, and sends a configurable amount of the rewards to L2.



GIP-0035: GraphQL @Live queries | Forum

  • To provide an easier querying protocol for real-time data, this proposal would implement @live queries as part of the GraphQL interface of The Graph.

  • This GIP describes The Graph’s real-time querying policy and a new suite of tools to help dApp developers query real-time data from their Subgraphs.

  • The GIP outlines the differences betweenSubscriptions and @live queries. The GIP recommends using the latter approach.

    • With Subscriptions, the consumer is limited to the event that caused the change, and it requires managing complex filtering before getting to the actual data changes.

    • GraphQL @live queries is an extension of a regular GraphQL query { ... }, with just an added directive on specific fields. Subgraph developers and dApp developers can often be different entities. As a subgraph consumer, you are unable to manage the events, schema, or definition of a subgraph. With @live queries, the power of choosing the real-time views is in the hands of the consumer. Example:

      query tokens {
        pairs {
          token1 {
            id
            name
            decimals @live
          }
        }
      }
      
    • For more information, make sure to read the entire proposal in the Forums.

4 Likes