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

An example with modular folder structure #394

Closed
vladinator1000 opened this issue Jul 19, 2019 · 2 comments
Closed

An example with modular folder structure #394

vladinator1000 opened this issue Jul 19, 2019 · 2 comments
Labels
duplicate This issue or pull request already exists

Comments

@vladinator1000
Copy link

vladinator1000 commented Jul 19, 2019

Hey y'all, I'm working on a nice example I'd like to eventually put in the docs / book, but I'm a little stuck on making it modular.

The current minimal example looks nice, but it quickly gets cumbersome to have a bunch of definitions in one massive file. Here's what I'm trying to do roughly:
image

Structuring a project this way will make it easier to add new functionality to a GraphQL project made in Juniper. The only problem I'm having is I don't know how to "merge" these separate schemas into one schema at the end at compile time.

I've created a little repository to illustrate the goal: https://github.com/savovs/juniper-schema

A minimal example would be if you have more than one module.
i.e. in a module hello:
schema.gql

type Query {
   hello(name: String!): String! @juniper(ownership: "owned")
}

mod.rs

use juniper;
use juniper_from_schema::graphql_schema_from_file;
use super::Context;

graphql_schema_from_file!("src/graphql/hello/schema.gql");

pub struct Query;

impl QueryFields for Query {
  fn field_hello(
    &self,
    executor: &juniper::Executor<'_, Context>,
    name: String,
  ) -> juniper::FieldResult<String> {
    Ok(format!("Hello, {}!", name))
  }
}

And in a module users:
schema.gql

type Query {
  # The directive makes the return value `FieldResult<String>`
  # rather than the default `FieldResult<&String>`
  currentUser: String! @juniper(ownership: "owned")
}

mod.rs

use super::Context;
use juniper;
use juniper_from_schema::graphql_schema_from_file;

graphql_schema_from_file!("src/graphql/users/schema.gql");

pub struct Query;

pub struct User {
  name: String,
}

impl QueryFields for Query {
  fn field_current_user(
    &self,
    executor: &juniper::Executor<'_, Context>,
  ) -> juniper::FieldResult<String> {
    let user = User {
      name: String::from("Ferris"),
    };

    Ok(format!("The current user is {}.", user.name))
  }
}

These modules can contain anything you want. There's just one thing I couldn't figure out.
How would you then "plop" their Query and Mutation types into the root query and mutation types of the root schema?

Like, for example in the root graphql module of the repo I linked:

use juniper;

mod hello;
mod users;

pub struct Context;
impl juniper::Context for Context {}

pub struct Query;

#[juniper::object(
    Context = Context,
)]
impl Query {
    // ..hello::Query
    // ..users::Query
    // ^ How do I put the contents of these here at compile time?
    // The idea is to have a nice folder structure separated by concern.
}

pub struct Mutation;

#[juniper::object(
    Context = Context,
)]
impl Mutation {}

pub type Schema = juniper::RootNode<'static, Query, Mutation>;

I think having this would enable us to make more scalable projects. I've already used this folder structure in a JavaScript-based GraphQL server in production and it's great. Really easy to add stuff to.

@vladinator1000 vladinator1000 changed the title Making an example with modular folder structure An example with modular folder structure Jul 19, 2019
@vladinator1000
Copy link
Author

Basically, I'm trying to do this: https://graphql-modules.com/

@theduke
Copy link
Member

theduke commented Jul 22, 2019

This is currently not possible. See #182.
Maybe something could also be done on the juniper-from-schema side.

Closing as a duplicate.

@theduke theduke closed this as completed Jul 22, 2019
@theduke theduke added the duplicate This issue or pull request already exists label Jul 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants