Splitting Root Schema to multiple Schemas

[kunjee17]

First of all Sorry, as I m new to Rust language and framework so I might be asking totally dumb question.

I am already working in GraphQL project having 100s of queries and mutations. It is TypeScript / JavaScript based project. So, there we can easily merge all things in single big fat schema as root node.

I tried similar thing with Juniper but was unable to do it. I thought multiple impl of Query will work as it is, but it didn't. Don't know if I m using rust wrong way or juniper is doing some magic.

If only one Query or Mutation is allowed it would be difficult to accommodate too many queries and mutations. I have gone through documentations and examples couple of times but couldn't find any solutions.

It would be great if someone can point me to right direction for the same. Do let me know if any details are unclear or missing.

[jmpunkt]

For me it is not clear what "merge" means in this context. I would assume that merge means that two queries Q1 and Q2 should be merged path wise? For example, if the path a.b.c exists in Q1 and path a.b.d in Q2, then merge(Q1, Q2) = a.b.{c,d}. If that is the case, then this should not be possible with Juniper, at least with the code generation approach. In general, it is not possible to define Q1 and Q2 independent and combine their code generation result. We faced a similar problem in #553.

However, maybe you could provide a small example and describe your desired behavior.

[kunjee17]

@jmpunkt sorry that it is not clear. Let me take https://typegraphql.com/ example.

@Resolver(Recipe)
class RecipeResolver {
  constructor(private recipeService: RecipeService) {}

  @Query(returns => Recipe)
  async recipe(@Arg("id") id: string) {
    const recipe = await this.recipeService.findById(id);
    if (recipe === undefined) {
      throw new RecipeNotFoundError(id);
    }
    return recipe;
  }

  @Query(returns => [Recipe])
  recipes(@Args() { skip, take }: RecipesArgs) {
    return this.recipeService.findAll({ skip, take });
  }

  @Mutation(returns => Recipe)
  @Authorized()
  addRecipe(
    @Arg("newRecipeData") newRecipeData: NewRecipeInput,
    @Ctx("user") user: User,
  ): Promise<Recipe> {
    return this.recipeService.addNew({ data: newRecipeData, user });
  }

  @Mutation(returns => Boolean)
  @Authorized(Roles.Admin)
  async removeRecipe(@Arg("id") id: string) {
    try {
      await this.recipeService.removeById(id);
      return true;
    } catch {
      return false;
    }
  }
}

I can write similar n number of classes. And eventually they are merged as on root object that is served as GraphQL point.

Now, in juniper case.

impl Query {

    fn apiVersion() -> &str {
        "1.0"
    }

    // Arguments to resolvers can either be simple types or input objects.
    // To gain access to the context, we specify a argument
    // that is a reference to the Context type.
    // Juniper automatically injects the correct context here.
    fn human(context: &Context, id: String) -> FieldResult<Human> {
        // Get a db connection.
        let connection = context.pool.get_connection()?;
        // Execute a db query.
        // Note the use of `?` to propagate errors.
        let human = connection.find_human(&id)?;
        // Return the result.
        Ok(human)
    }
}

This is the one and only Query impl I can have.

I was looking something like having

impl UserQuery {}
impl ProductQuery{}
imp Query [...UserQuery, ...ProductQuery ]

Sorry for little mix of Rust and TypeScript. I m new to Rust and TypeScript is day job language. But I guess you get the point. If I have all the queries in one big fact impl Query {} it would be very difficult to manager that single file. So, there a way or alternative for same?

[jmpunkt]

So to be clear, you define two queries, then all fields in the these two queries should be in the RootQuery. So we define the queries.

struct UserQuery;

#[juniper::graphql_object]
impl UserQuery {
     fn user(&self, user: UserId) -> User { todo!() }
}

struct ProductQuery;

#[juniper::graphql_object]
impl ProductQuery{
    fn product(&self, id: ProductId) -> Product { todo!() }
}

Then after the "merge", the RootQuery should be the following.

#[juniper::graphql_object]
impl RootQuery {
     fn user(&self, user: UserId) -> User { todo!() }
     fn product(&self, id: ProductId) -> Product { todo!() }
}

Sadly there is no way to tell Juniper to merge these objects. Implementing such behavior in Juniper should be possible.

For this example, the easiest workaround with Juniper would be

pub struct RootQuery;

#[juniper::graphql_object]
impl RootQuery {
     fn users(&self -> UserQuery { UserQuery }
     fn products(&self) -> ProductQuery { ProductQuery }
}

or with a different syntax but the same object

#[derive(juniper::GraphQLObject)]
pub struct RootQuery {
     users: UserQuery,
     products: ProductQuery,
}

impl RootQuery {
    pub fn new() -> Self {
        Self {
             users: UserQuery,
             products: ProductQuery,
       }
    }
}

Your GraphQL query requires an additional path segment (users or products).

[kunjee17]

@jmpunkt thanks for explaining. I guess I did get my answer. I was looking for similar thing. I don't mind path segment until things stays clear.

You can close this issue. Please do the honors. :)

[LegNeato]

We had previously discussed something like serde's flatten...would that do what you want?

[kunjee17]

@LegNeato I guess you are asking @jmpunkt . Sorry to pitch in, but you are right. Something similar to serde's flattern .

PS: It might need warning or error message if there is duplicate schema definition. Like findById in users and findById in products. Normally graphql peple don't use this kind of names but JavaScript / TypeScript gives that kind of check while merging schema.

[kunjee17]

@LegNeato @jmpunkt side question. Any plans to add this flatten option in Juniper? Obviously not now but in future before some concrete release?

[tyranron]

@kunjee17 @LegNeato @jmpunkt I think the new design described in #553 will solve this issue too without providing any flattening capabilities. Simply, it will allow to specify multiple impl blocks, which can be defined in different modules, so the "merge" will happen naturally.

[kunjee17]

@tyranron that would be great to have. BTW I did tried to have different Query impl block but it crashed. I m new to rust and juniper so it is more difficult for me to find the real issue.

Dumb question. That is incoming feature right. Or I just missed something already there in Juniper ?

[tyranron]

@kunjee17 it will be incoming feature if community and maintainers will decide so. At the moment it's only a possible incoming feature 🙃

Current juniper implemetation doesn't contain such capabilities.

[kunjee17]

@tyranron thanks for reply. It would be nice to have such feature. Let's see what community and maintainers decide. :)

[kunjee17]

@tyranron @LegNeato @jmpunkt is it possible to achieve something like this in Rust. Below code is from Scala.

val api1 = graphQL(...)
val api2 = graphQL(...)

val api = api1 |+| api2

It will merge all the root in one big root. And I m not asking about current feature but in general probable feature.

[tyranron]

@kunjee17 i think, yes.

enum UnitedApiQueryRoot {
    Api1(Api1QueryRoot),
    Api2(Api2QueryRoot),
}

But at the moment, juniper doesn't provide capabilities to derive code for this use case automatically. So, you need to implement GraphQLType manually for this enum, where you can provide the merged information about two APIs.

[kunjee17]

@tyranron neat. I should give it a try to this as well. Thanks for info.