[RFC] Chaining GraphQL Queries / Mutations

[soorajshankar]

Chaining GraphQL Queries / Mutations

Problem

1. How to find products greater than the average price?
2. How to handle the creation of the patient record, medical history entries, and prescription details in one mutation?\

Ability to chain graphql queries/mutations can open up different ways to think about API, right now relationships are the only way to do this, and that can only work with direct field mapping and mapping to an input argument is not possible atm. Currently in these situations, developers make multiple queries from the client to join data which is costly.

1. Current GraphQL limitations lead to multiple network calls, egress, affecting performance and cost.
2. Certain mutation scenarios, like nested inserts and API-level transactions, are not fully supported.

Motivation:

• Simple mental model for performing complex queries
• Reduce load/complexity in frontend (doing queries one by one has both code maintenance cost and performance cost of loading unnecessary data)
• Less feature development for Hasura (no need for complex read or write APIs)
• Why now? Considering we are now defining v3 and re-iterating, it would help us to scope in this problem and validate the need of considering this.

Approaches

1. Chained Queries in Payload: Ability to chain queries &/ mutations in the query payload (GraphQL spec incompatible)

query  MyQuery($avg:  Int  )  @chained  {
  products_aggregate  {
    aggregate  {
      avg  {
        price 
      }
    }
  }
  products(where:  {price:  {_gt:  $avg}})  {
    name
    id
    price
  }
}

// variables

{
  avg:  "$.products_aggregate.aggregate.avg.price".  //json  path  of  value
}

2. Backend-Defined Chaining Logic: This is a thought on top of the first idea - the difference is just that the above logic is stored in the backend (like RESTified endpoints) and executed as a single graphql query.

3. Extending Relationships : Ability to define relationships from & to generated types (like aggregates, where clause, limit etc.)

   • Right now, the relationships field mappings are limited to metadata types, and generated input/output types are not supported - which makes it difficult to logically join queries.
   • With this ability, complex and transactional queries can also be achieved.
   • Problems like How to find products greater than the average price? can be solved with this.

[manasag]

Do #1583 and #2657 relate to this proposal?

[soorajshankar]

Do #1583 and #2657 relate to this proposal?

While there are similarities between this proposal and #1583, the scope of the problem we address extends further. Proposal #1583 allows you to query data after executing a mutation. In contrast, this proposal not only facilitates querying data after a mutation but also enables passing values from the preceding mutation or query to the subsequent one. This expansion opens up new possibilities for data access, especially when dealing with complex use cases.

[oscar6echo]

This expansion opens up new possibilities for data access, especially when dealing with complex use cases.

One use interesting use case would be filter then group_by.
Currently an SQL function is necessary - this is fine but requires more work/knowledge.

[manasag]

We are looking into how Hasura can provide a framework to perform orchestrations of any kind (across databases, actions, etc). The current thought is to do via easy to use functions in the Typescript connector (these functions essentially represent any query present in your Hasura supergraph). One can now call these functions in any order or chaining.

More on this approach can be tracked in this issue #10247