hasura / hasura/graphql-engine

[RFC] Chaining GraphQL Queries / Mutations

Open
#10,058 4 comments 13 reactions 0 assignees View on GitHub
c/v3-engine k/rfc k/v3-backlog v3
Dominant language
TypeScript
Stars
32.1k
Forks
3k
PR merge metrics
PR metrics pending

Description

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.
3. 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)

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

// variables
```js
{
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.

Contributor guide

Open the contributing guide

Research direction

Start with the Problem, Motivation, and Approaches sections, then review the GraphQL specification constraints noted for payload chaining. Compare the three proposed directions and determine the intended scope, compatibility, and transaction requirements; done means the RFC has a decided approach and clear implementation boundaries.

Written by the indexing model from the issue text.

Assessment

Tech stack
graphql
Domain
api, backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.