Description
Is there an existing issue that is already proposing this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe it
We are building sub-graphs for use in a Federated supergraph. The sub-graphs we are currently authoring with nestjs because we favor its simple / code-first approach to authoring graphql API's.
When we import these graphs into our supergraph all our queries appear at the top-level and the product we are using does not support namespacing of sub-graphs explicitly and it is not currently on their feature roadmap. In an ideal scenario our federated super-graph solution would support the namespacing and we would not need to worry about that in our sub-graphs, but unfortunately in our scenario we are instead stuck needing a workaround in the interim.
Some of the suggested workarounds so far are unfavorable because they involve running an extra proxy server between our supergraph and sub-graph, which adds complexity.
The feature we would like to request in nestjs is the ability to namespace queries and mutations within the sub-graph using NestJS constructs.
So to use the Apollo Namespacing by separation of concerns, an example scenario our initial subgraph would look similar to where a sub-graph with these operations:
type Mutation {
createUser(profile: UserProfileInput!): User!
blockUser(id: ID!): User!
createUser(comment: CommentInput!): Comment!
deleteUsre(id: ID!): Comment!
}
Could be namespaced to group similar operations:
type UsersMutations {
create(profile: UserProfileInput!): User!
block(id: ID!): User!
}
type CommentsMutations {
create(comment: CommentInput!): Comment!
delete(id: ID!): Comment!
}
type Mutation {
users: UsersMutations!
comments: CommentsMutations!
}
This would enable us in our supergraph to much more ergonomically organize our self-authored graphs, by applying to namespace on the sub-graph prior to importing to the supergraph.
Describe the solution you'd like
We are not heavily opinionated on how it may be implemented, so long as it is relatively simple. One solution would be to add an option to the Query and Mutation attributes e.g.
To augment NestJs:GraphQL:Resolvers::Code first resolver
@Resolver(of => Author)
export class AuthorsResolver {
constructor(
private authorsService: AuthorsService,
private postsService: PostsService,
) {}
@Query(returns => Author, { namespace: 'authors' })
async author(@Args('id', { type: () => Int }) id: number) {
return this.authorsService.findOneById(id);
}
@ResolveField()
async posts(@Parent() author: Author) {
const { id } = author;
return this.postsService.findAll({ authorId: id });
}
}To augment: To augment NestJs:GraphQL:Mutations::Code first
@Mutation(returns => Post, { namespace: 'authors'})
async upvotePost(@Args({ name: 'postId', type: () => Int }) postId: number) {
return this.postsService.upvoteById({ id: postId });
}
Teachability, documentation, adoption, migration strategy
It may be feasible to add a section to the NestJS GraphQL docs "Namespace", reference the Apollo docs on Namespacing by separation of concerns, then provide code samples similar to the augmented queries in the proposed solution demonstrating how to apply namespacing to the existing samples on documentation.
What is the motivation / use case for changing the behavior?
Concrete use-cases would be to help organizee sub-graphs where there are large amounts of queries. It would also make scenarios such as our much simpler where we are authoring sub-graphs to be imported into large super-graphs where support for adding namespaces doesn't exist on the supergraph.