Support delegation to sub fields

[schickling]

Currently schema delegation is only possible for root fields but not for subfields which becomes necessary when for example a most fields are wrapped in a viewer root object.

Here is a syntactical suggestion for how the API could look like:

const resolvers = {
  Query: {
    me: (parent, args, ctx, info) {
      return myBinding.query.viewer({ someArg: true }).user({ otherArg: false }, info)
    }
  }
}

Thoughts about implementation:

• Requires deeper refactoring to support both Promise interface (.then()) and method chaining (especially tricky to support correct typing). See chromeless for similar example.
• The last invoked method in the method chain needs to know about the previous calls (implement possibly via some kind of cache) which is then "wrapping" the resolver info object with the tree path described by the previous method chain calls (this also needs to work without an info object passed in)
• Requires partial rewrite of the static binding generator

Note: The same applies to subscription delegation.

[Urigo]

Thank you for reporting.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!

---

In the context of that particular issue - GraphQL Mesh uses a few interesting mechanisms like transforms and handlers, including using the new schema stitching introduced in GraphQL Tools v6 and Apollo Federation.
You can reuse underlining APIs, transform them in however way you like.
I believe it should give you a nice experience and power of delegation but if you think what you expected is in some way is missing in GraphQL Mesh, please feel free to open a new issue on the GraphQL Mesh repo.

We're looking forward for your feedback of how we can make your experience even better!