Submit custom GraphQL queries from Provider

[danielbate]

Currently we interact with GraphQL endpoints supplied by the node via wrapped operations provided by graphql-codegen, these are then exposed to SDK consumers via wrapped provider functions (Provider.getVersion(), Provider.getBlockNumber() etc). This potentially restricts the information we are providing to consumers or means they have to go around the SDK to query the node. We should provide a way for consumers to submit their own custom queries.

Potential implmentation in Provider

/**
 * Passes a custom document and variables via the provider
 */
async customQuery(query: DocumentNode, variables: Record<string, unknown>): Promise<unknown> {
  return this.operations.query(query, variables);
}

[danielbate]

In #3047 I reused a lot of what we already have in the SDK to create a custom query, we could do something similar but more flexibly. Have a public function on the provider that takes a document and variables and passes the whole thing to requester, similarly to how we already build our operations.

[petertonysmith94]

SDK Query Optimization Issue Documentation

Current Problem

Public Auto-Generated GraphQL Client

• The SDK's auto-generated GraphQL client, provider.operations, is currently a public property.
• This client serves two purposes:
  1. Internal needs of the SDK
  2. Usage by frontend applications

Breaking Changes

• Removing any queried field is considered a breaking change.
• Reason: External consumers might be directly using the auto-generated client and relying on specific fields.

Ideal Solution

Make provider.operations Private

• This change would allow for non-breaking optimizations within the SDK.

Alternative Options for Consumers

Two proposed alternatives for SDK consumers:

1. Auto-generate Their Own Clients

   • Consumers would create clients tailored to their specific querying needs.
   • This approach mimics the SDK's current method.

2. Implement Ad-hoc Type-safe Queries

   • Allow consumers to write custom queries through the TypeScript SDK.
   • Example usage:

     provider.client.query('chain', { 
       name: true, 
       consensusParameters: { 
         chainId: true 
       } 
     });

Challenges with Implementation

Previous Discussions

• The second approach (ad-hoc type-safe queries) has been discussed internally multiple times.

Proof of Concept Attempt

• A proof of concept was implemented for the ad-hoc query approach.
• Findings:
  • Implementation might be possible but would be a significant undertaking.
  • Main challenge: Ensuring correct API functionality and type inference for all GraphQL query types.

Complexity Levels

• Implementing type safety for nested queries is relatively achievable.
• Supporting more complex GraphQL features (e.g., union types) is significantly more challenging.

Lack of Existing Solutions

• No suitable library was found that could automatically handle all required functionalities.

Conclusion

The current structure of the SDK's GraphQL client presents a barrier to query optimization. While potential solutions have been identified, implementation remains complex and resource-intensive. Further research and development may be necessary to find a balance between maintaining backwards compatibility and enabling more efficient query structures.

[petertonysmith94]

Any thoughts on this @FuelLabs/frontend?

[nedsalk]

graphql-zeus looks really promising and might be the library that would enable both this and #1570 in one go.