GraphQL Library & Support

Description

Integrating a chainable, function based library for interfacing with Arweave’s GraphQL library would be a great feature to have for the project. The following are a proposed implementation for interfacing with GraphQL.

Proposed Implementation

Initializing a GraphQL query

const arweave = Arweave.init({ ... });
const result = await arweave.query({ ...options }); // Initializes a new query

GraphQL options

arweave.query({
  // Default has the full GraphQL object
  output: `{
     cursor
     node {
        ...
     }
  }`,
});

Select by Tag

arweave
  .query()
  .tag({
    name: 'name',
    values: ['values'],
    sort: 'ASC',
  })
  .tag({ ... }); 

Limit and After

arweave
  .query()
  .after('cursor')
  .limit(10);

Sort by block height

arweave
  .query()
  .sort('ASC');

Block range

arweave
  .query()
  .blocks({ min: 0, max: 10 });

Owners

arweave
  .query()
  .owners([...addresses]);

Recipients

arweave
  .query()
  .recipients([...addresses]);

By block ID

arweave
  .query()
  .blockId([...]);

[t8]

The utility isn’t necessarily for making writing queries easier per say. Rather, it would a way for developers to query GraphQL with built-in tools. Or, at least, that is why I’m in favor of this proposal.

Additionally, I’m not attracted to hardcoding the gateway. Pulling this data from the current Arweave instance could allow for dynamic gateway switching in the future. Not sure if/what @TheLoneRonin’s plans were for this. I suppose someone could still do all of this manually, but at the very minimum, building the query function and supporting the GraphQL object appeals to me the most.

Regarding documentation: @TheLoneRonin actually published a very well-written and comprehensive docs site for exactly this! You can find it here.

As a workaround to native arweave-js implementation, @johnletey created a super useful library for querying GraphQL by simply providing the query object: https://github.com/johnletey/arGQL

[CDDelta]

Additionally, I’m not attracted to hardcoding the gateway. Pulling this data from the current Arweave instance could allow for dynamic gateway switching in the future. Not sure if/what @TheLoneRonin’s plans were for this. I suppose someone could still do all of this manually, but at the very minimum, building the query function and supporting the GraphQL object appeals to me the most.

I’m not sure I entirely follow you here. Are you referring to having the result of the GQL query change at runtime depending on the gateway schema? I think a great benefit of GraphQL is that query results changing is checked for and protected against. I guess we just have different project goals 😅

Regarding documentation: @TheLoneRonin actually published a very well-written and comprehensive docs site for exactly this! You can find it here.

I was more referring to documentation directing/instructing devs on setting up a GraphQL code generator. I love having type-safety with my queries and I think more people should use it. The code generator can also be configured to generate a client object which you use to perform all your queries. It’s awesome.

The utility isn’t necessarily for making writing queries easier per say. Rather, it would a way for developers to query GraphQL with built-in tools. Or, at least, that is why I’m in favor of this proposal.

This makes sense. Having it built into the SDK certainly makes things easier to start with. I’m just not sure it would be a scalable approach in the long term for larger projects or a more complex gateway schema.