Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use Alias with custom binding #169

Closed
james-ff opened this issue Oct 23, 2018 · 2 comments
Closed

Cannot use Alias with custom binding #169

james-ff opened this issue Oct 23, 2018 · 2 comments

Comments

@james-ff
Copy link

Hello,

I'm using graphql-binding on top of postgraphile to build custom backend functions for my graphql api. I often shorten some of the long auto-generated names for relationship fields for ease of use on the frontend. This works fine with postgraphile on its own, but when called through a binding it errors when an Alias is used to rename one of the fields. I've tested a number of times and it is indeed caused by the use of an Alias. Bindings works fantastically for my use case, but not being able to use Aliases is a bit of a hindrance.

Binding use example (this is exposed in my api under the query field name "test")

binding.query.allCustomers({}, info, { context })

This is ok:

query {
  test {
    nodes {
      firstName
    }
  }
}

This errors only with bindings:

query {
  test {
    nodes {
      name: firstName
    }
  }
}

Can anyone shed some light on this issue? And confirm / deny if this affects all use cases of bindings or is specific to my use?

Cheers.

@RoryKelly
Copy link

It is possible to use alias with graphql-bindings. I am currently using it in my own project.

just cast the returned object to any and you can access the alias fields.

const allCustomers : any = binding.query.allCustomers({}, info, { context })
const name = allCustomers.test.nodes.name

@Urigo
Copy link
Collaborator

Urigo commented May 26, 2020

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 - You should check out out Postgraphile example and aliases are generally supported.

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

@Urigo Urigo closed this as completed May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants