You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Remote schema stitching and execution requires every remote service run as a GraphQL Server exposed over a HTTP-based API. In a microservices-based architecture where those remote services are only involved in service-to-service communication, leveraging HTTP as the transport introduces a fair amount of unnecessary overhead. Consider adding a way to leverage other back-end efficient transport protocols to communicate between the root GraphQL API server and the remote services.
The text was updated successfully, but these errors were encountered:
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!
Posting as a possible enhancement per conversation with @schickling on the Slack channel:
Remote schema stitching and execution requires every remote service run as a GraphQL Server exposed over a HTTP-based API. In a microservices-based architecture where those remote services are only involved in service-to-service communication, leveraging HTTP as the transport introduces a fair amount of unnecessary overhead. Consider adding a way to leverage other back-end efficient transport protocols to communicate between the root GraphQL API server and the remote services.
The text was updated successfully, but these errors were encountered: