-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
namespace remote schemas or conflict resolution with remote types/fields #3518
Comments
This would be definitely a great feature! I'm just having a situation where two of my remote schemas both a provide a query operation "list" and these, of course, clash in Hasura. And even if names do not clash, remote schema operation names are somehow "polluting" the Hasura schema and it would be better to have a definite name to appear for them in the schema to more easily identify which operations belong to a remote schema and which are native Hasura operations. @tirumaraiselvan Do you have an estimate when such namespacing could be available? |
The API can be similar to https://hasura.io/docs/1.0/graphql/manual/schema/custom-field-names.html#custom-field-names |
Upvote namespacing of remote schemas. Makes linking staging and production instances way easier. |
Another way is to nest remote schemas inside a namespaced field like
Originally posted by @samuelcastro here: #4809 |
Yes, as @tirumaraiselvan mentioned I think grouping schemas by namespace would be more manageable and/or readable, I don't like the idea of prefixed names. Is there any work in progress around this or this is still in a discussion phase? I think this is a critical issue, I'm using different graphql services providers and I'm starting to get worried about this conflicting problem. Thanks. |
We have an RFC here: #4821 We will begin the implementation very soon. |
Could creating a proxy server that takes a GraphQL schema, adds a prefix to all queries and mutations and forwards incoming calls to the remote schema be a feasible workaround? Or is it more involved as all the type definitions would have to be changed as well? |
Hi @tirumaraiselvan, Any updates on this? We are facing this issue with trying to use Remote Joins at the moment. We have many services internally exposing a GraphQL API, all aggregated under one instance of Hasura ("master" Hasura) using Remote Schemas, for public consumption. We want to use Remote Joins in some of those services. So for ex., Service A, B and C are all publicly exposed in our "master" Hasura via Remote Schemas. Now, Service A will use Remote Joins to Service B, so it will add Service B as a Remote Schema. However, in "master" Hasura, we cannot use Service A as a Remote Schema anymore because "master" Hasura is already using Service B as a Remote Schema. Please let me know. Thanks! |
Closing this in favour of #5863 |
Should we ask for an optional
namespace
input from the user while adding Remote Schemas and then every type and field in the RS is prefixed with thisnamespace
.This would allow using Remote Schemas with generic fields like
user
.The text was updated successfully, but these errors were encountered: