tirumaraiselvan / graphql-engine

Blazing fast, instant realtime GraphQL APIs on Postgres with fine grained access control
https://hasura.io
Apache License 2.0
2 stars 0 forks source link

Support nested remote fields for remote relationships #8

Closed tirumaraiselvan closed 5 years ago

tirumaraiselvan commented 5 years ago

We should allow to join with fields like:

 query {
    stripe (account_id : $account_id) {
            subscriptions(sub_id : $sub_id) {
                 leaf1
                 leaf2
             }
      }
}

This will involve changing the metadata API to something like:

type: create_remote_relationship
args:
  name: message
  table: profiles
  hasura_fields:
    - stripe_account_id
    - stripe_sub_id
  remote_schema: my-remote-schema
  remote_field: 
    stripe:
      arguments:
        account_id: "$stripe_account_id"  <- i specify this in the UI
        group: "$g"  <- i specify this in the UI
      field:
        subscriptions:
          arguments:
            sub_id: "$strip_sub_id"  <- i specify this
           -- sub_timestamp: <- result: i want this field
           -- sub_order <- result: and this
chrisdone commented 5 years ago

Indeed. That format sounds sensible to me. So that would directly correspond to the real graphql format.

chrisdone commented 5 years ago

Also, could remote_field become remote_fields? Given that it's an object in your example, we could pull more than one field from the same remote. That sounds reasonable?

We could also move to that format now (for PR 2) or a PR 1.5 to be like:

  remote_field: 
    stripe:
      arguments:
        account_id: "$id"

This syntax would match our existing functionality, but be directly extendable into your addition of the fields, when we get to that.

tirumaraiselvan commented 5 years ago

Also, could remote_field become remote_fields? Given that it's an object in your example, we could pull more than one field from the same remote. That sounds reasonable?

For simplicity, I think it's reasonable (reasoning / implementation wise) to expect one relationship -> one field. If somebody needs to call more than one field then let them create another relationship.

We could also move to that format now (for PR 2) or a PR 1.5 to be like:

Yes, we can do that in PR 1.5

tirumaraiselvan commented 5 years ago

VALID

query {

  user {
    id
    name
    stripe_account_id
    strip_sub_id
    stripeSubRel {
      sub_id
      sub_last_timestamp
      sub_status
     }
}

VALID

query {

  user {
    id
    name
    stripe_account_id
    strip_sub_id
    stripeSubRel (sort_sub_by: "sub_last_timestamp") {  --- `sort_sub_by` comes from `subscriptions` field
      sub_id
      sub_last_timestamp
      sub_status
     }
}

INVALID

query {

  user {
    id
    name
    stripe_account_id
    strip_sub_id
    stripeSubRel (group: "creation_timestamp") {    --- `group` argument comes from `stripe` field and not from `subscription` field
      sub_id
      sub_last_timestamp
      sub_status
     }
}

INVALID

query {

  user {
    id
    name
    stripe_account_id
    strip_sub_id
    stripeSubRel (sub_id: "xyz") {    --- `sub_id` argument comes from relationship info
      sub_id
      sub_last_timestamp
      sub_status
     }
}
tirumaraiselvan commented 5 years ago

closed by #16