Skip to content
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

Support for namespacing queries and mutations #3105

Open
1 task done
serdmanczyk opened this issue Dec 6, 2023 · 0 comments
Open
1 task done

Support for namespacing queries and mutations #3105

serdmanczyk opened this issue Dec 6, 2023 · 0 comments

Comments

@serdmanczyk
Copy link

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.

@kamilmysliwiec kamilmysliwiec transferred this issue from nestjs/nest Dec 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant