Remote Schema Custom Types Not Included in Hasura 2.0 Schema

[aaalexliu]

We have a remote schema running "apollo-server-express": "^2.18.2". We define our types using "nexus": "^1.0.0".

Previously, using Hasura 1.3.3, if our server exposed custom types, for example:

type Result {
  id: String!
}

enum Stage {
  start
  finish
}

These custom types would be stitched into our Hasura schema and could be accessed by introspection, thereby allowing us to use Hasura as a central source of truth for all GraphQL types.

However, in Hasura 2.0, if these types are not directly related to a query or mutation, these types are not included in the Hasura schema.

We noticed that the apollo server root level types Mutation and Query are also excluded. Instead, they are added into Hasura's mutation_root and query_root.

For example, if we have a mutation in our remote schema:

type Mutation {
  start_job(id: String!): Result!
}

In Hasura we can introspect:

type mutation_root {
  start_job(id: String!): Result!
}

type Result {
  id: String!
}

But enum Stage is not available.

We've also noticed that if we enable HASURA_GRAPHQL_ENABLE_REMOTE_SCHEMA_PERMISSIONS, Hasura does give us an option to attach permissions to un-exposed remote schema types, but when we try and add a permission, Hasura fails with the error:

Saving permission failed
"Query" has to be an object type

Our current workaround is putting these custom types in placeholder query so we can access them by introspection.

Would appreciate any help!

[SameerChorge94]

Any updates on this issue? i'm facing same issue in hasura cloud version v2.0.9-cloud.1

[ghost]

Issue is still persistent in V2.2.0.

Requires further triage by DS team.

[ghost]

Hello @aaalexliu -

I am trying to get running with this one here at Hasura. The behavior you're describing is intentional within the GraphQL engine so my question below is meant to help justify making this deliberate change:

Can you please provide some currently relevant user stories that can explain how this would be of benefit?

[namoscato]

Thanks for the reply, @dennislaviolette. @aaalexliu and I work together, so I'm happy to provide more context on our use case.

In short, these "custom types" enable us to share GraphQL server types / configuration with our client-side React / TypeScript application. Obviously in most cases, such types are attached to root-level queries or mutations; however, we have a few scenarios in which this is not the case:

1. Enums that derive root-level query shape but are not referenced directly. For example, we have a PermissionSubject enum declared in our GraphQL server, and it's useful to get client-side TypeScript feedback as those values change.
2. Object configurations that describe the shape of persisted background job state. In practice, these background jobs are initiated by some root-level mutation, and the client-side application subscribes to updates of such state.

This was a definitive behavior change with Hasura v2 (that tripped us up throughout the upgrade from v1.3.3). At the very least, I would recommend including something about this in the upgrade notes.

As this is now "intentional" behavior with Hasura v2, do you have any recommendations to support these use cases? As @aaalexliu mentioned, we're just throwing these types in a placeholder query at the moment, which isn't ideal longterm.

/cc @BenoitRanque