Group Queries/Mutation under context/name in code first schema

[adjiandov]

Hello,
Currently when adding @GraphQLAPI class with @query and @mutation methods and having multiple of these at the end in the generated schema all of the queries and mutations are grouped under Query root and Mutation root.
It would be nice to be able to group them logically by some context/name as it can be done in the schema first approach with separate schema files.

[phillip-kruger]

Not to sure what you mean. Are you sure this is allowed in the spec https://spec.graphql.org/draft/ ?

[adjiandov]

Yes in the spec it is referred as MyQueryRootType and MyMutationRootType and having several of those e.g. CustomerRootType, UserRootType and all queries related to customer will go under CustomerRootType and all queries related to user will go under UserRootType.

[phillip-kruger]

Can you share a link ?

[adjiandov]

Sure, here it is: https://spec.graphql.org/draft/#sec-Schema

[phillip-kruger]

That is just naming the roots, not have mulitple, right ? We hardcode the root (query, mutation, subscription) and can maybe allow you to name them, but as far as I can see you still only have those 3. Or am I missing something ?

[adjiandov]

In that case is there a way to define multiple schemas?

[jmartisk]

Can you even specify multiple roots for an operation type?

schema {
  query: MyQueryRootType1
  query: MyQueryRootType2
}

Is this legal? It's not clear to me from the spec. It doesn't say whether the same OperationType can be repeated in a SchemaDefinition, but it doesn't look right to me.
Or how else would you do it?

[phillip-kruger]

No that is not legal as far as I know. We did "hack" this with our "group feature" a while back, but that will be removed as this is really hacky and against the spec.

[phillip-kruger]

See this: https://github.com/smallrye/smallrye-graphql/tree/main/server/tck/src/test/java/io/smallrye/graphql/test/apps/grouping/api

And then https://github.com/smallrye/smallrye-graphql/blob/main/server/tck/src/test/resources/tests/grouping/query/input.graphql

But as I said this will probably be removed in a future version

[adjiandov]

And is it possible to have some groupings with the help of Type?
so that the schema looks something like:

type Query { customers: Customers users: Users }

And then the actual queries and GraphQLApi will be defined within these types?
I have seen this in another schema first approach for sure, but cannot remember at the moment the name of the GraphQL implementation.

[phillip-kruger]

If you have two queries in your code, one for customers and one for User you should get that.

[jmartisk]

Like this?

type Query { 
   customers: CustomersQueries 
   users: UsersQueries
} 

type CustomersQueries {
   customerQuery1: String
   customerQuery2: String
}

type UsersQueries {
   userQuery1: String
   userQuery2: String
}

That I think is legal, but we don't provide a way to do this. It would also make querying a bit complicated because you would have to include the 'group' name in the query

query {
   customers {
      customerQuery1
   }
}

[t1]

I haven't tried, but it could be possible to create such a schema with something like this:

@GraphQlApi
public class Queries {
    @Query public CustomersQueries customers() { return new CustomersQueries(); }
    @Query public UsersQueries customers() { return new UsersQueries(); }
    public String customerQuery1(@Source CustomersQuery ignored) { ... }
    ...
}

The classes CustomersQueries and UsersQueries would be empty.

[phillip-kruger]

And that is (kind of) what groups are doing (see the links to the groups tck above)

[t1]

I've seen them before but didn't get the mechanism. If you @Name an API class, it becomes a group? That's quite neat, actually!

Why do you say it was against the spec? It's not covered by the MP GraphQL Spec, but it's not forbidden, is it? And it's perfectly valid GraphQL, isn't it?

[phillip-kruger]

I think the problem came in with Mutations. How will that work ? We can also look at how it implemented, as that can maybe just improve and then I'll feel better about it.

[adjiandov]

@jmartisk yes this is exactly what I was looking for. Yes querying will be more complex, but navigating through the schema in large scale projects will be much easier.

[phillip-kruger]

Well the other option is to break up your app in multiple apps... or the grouping feature would give you what you want, or basically an empty object (customers) that only has source fields on ... But I would not optimize for easy schema reading. The main purpose for the schema is not to make it readable for humans. By naming your queries properly, the user can still navigate the schema easily.

[phillip-kruger]

I am going to move this to a discussion rather than an issue