Graphql-engine: namespace remote schemas or conflict resolution with remote types/fields

[tirumaraiselvan]

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 this namespace.

This would allow using Remote Schemas with generic fields like user.

[beepsoft]

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?

[tirumaraiselvan]

The API can be similar to https://hasura.io/docs/1.0/graphql/manual/schema/custom-field-names.html#custom-field-names

[faboweb]

Upvote namespacing of remote schemas. Makes linking staging and production instances way easier.

[tirumaraiselvan]

Another way is to nest remote schemas inside a namespaced field like

query {
  remote_schema1 {
    hello
  }
}

Originally posted by @samuelcastro here: https://github.com/hasura/graphql-engine/issues/4809

[samuelcastro]

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.

[tirumaraiselvan]

We have an RFC here: https://github.com/hasura/graphql-engine/pull/4821

We will begin the implementation very soon.

[Narigo]

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?

[ntx-ben]

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!

[tirumaraiselvan]

Closing this in favour of #5863