Proposal: Allow variable assignment

[MikeRalphson]

This would allow chaining the result of a query into the input of a mutation, and therefore atomic operations (from the point of view of the client).

A query containing a variable assignment would be considered a pseudo-mutation and would therefore run serially with the other mutation(s).

It may be useful to be able to retrieve the value of variables from a pseudo-schema-object in the result of a mutation.

Related to #88

[leebyron]

I'm not sure I understand what you're suggesting. It would be helpful to see an example of the query you would like to write following this proposal.

[MikeRalphson]

@leebyron the kind of combined query/mutation I have in mind would simply obviate the need for a second round trip to the server in a case such as this, where an input to the mutation is required which can only be obtained as the result of an earlier query:

{
  repository(owner: "Mermade", name: "openapi_specifications") {
    issues(last: 1) {
      edges {
        node {
          $id := id
        }
      }
    }
  }
}

mutation comment($cmid: String!, $id: ID!, $body: String!) {
  addComment(input: {clientMutationId: $cmid, subjectId: $id, body: $body}) {
    clientMutationId
    commentEdge {
      node {
        databaseId __variables {
          $id
        }
      }
    }
  }
}

Variables:

{
   "cmid": "1234",
   "body": "New comment body"
}

The query and mutation may have to be wrapped together, or the query be performed nested within the mutation, syntax is unimportant at this stage.

I don't know if the @export feature described in this issue is being proposed as a part of the GraphQL language?

[bbakerman]

This issue would require another capability and that is the ability to run 2 operations at once, which the spec does not yet allow.

Variable assigment via say @export would only be available if multiple operations are allowed

[SevInf]

We actually have a use for this feature for A/B testing. Right now we have the following problem: we have the feature flags exposed as graphql type and we want to exclude part of the query based on the picked variant. In the end, we want to have something like this:

query Q {
    article {
          ...WidgetA # query this only feature flag is active
          ...WidgetB # query this only feature flag is inactive
    }
}

Right now our options are:

1. Overfetching:

query Q {
    featureFlags {
         isFeatureActive
    }
    article {
          ...WidgetA
          ...WidgetB
    }
}

In this case, we always fetch all necessary data for both WidgetA and WidgetB and decide which one to show on the frontend.

2. Moving feature flag outside of graphql:

query Q($isFeatureActive: Boolean!) {
    article {
          ...WidgetA @include(if: $isFeatureActive)
          ...WidgetB @skip(if: $isFeatureActive)
    }
}

With @export directive we could've still had our feature flags inside of GraphQL schema and avoid overfetching:

query Flags {
    featureFlags {
         isFeatureActive @export(as: "isFeatureActive")
    }
}

query Q($isFeatureActive: Boolean!) {
    article {
          ...WidgetA @include(if: $isFeatureActive)
          ...WidgetB @skip(if: $isFeatureActive)
    }
}

Right now we are trying to implement this variant on top of existing server and client libraries but would be nice to see it standardized.

[leebyron]

Rejecting in favor of #375 / #377