Modular definition of schemas (extensibility) about graphql-tools

[lucasconstantino]

Here is a small project I've being working on https://github.com/lucasconstantino/graphql-modules/

[tomitrescak]

Hi, I created a package that allows for modular definition of graphql schemas. It can be found here. Would be great if something like this would be in the core ;)

https://www.npmjs.com/package/apollo-modules

[helfer]

@tomitrescak your package looks interesting, but I'm a bit confused because it seems to do more than just let you create a schema in a modular way. For example, there's also a function to create input types from output types, and a function to modify options based on the request.

I think it would be best if modular schema creation was limited to just the schema itself, and allowed you to start with a base schema and then extend that with modules. Unfortunately that would require modifications to graphql-js or monkey patching a schema. If I were to implement it, I think I would just try monkey patching an existing schema, but that could be rather tedious programming work and is probably pretty error-prone.

[gadicc]

I'm also very interested in this, relating back to apollographql/apollo#28. It's currently a lot of work for devs to add "apollo packages" (packages that include their own schema). I know it's possible to gradually construct the typeDefs via imported arrays, but there's no way to add root queries and mutations.

I was going to propose the following API:

const es = makeExecutableSchema(...);

es.addType(name, definition);
es.addRootQuery(name, definition);
es.addRootMutation(name, definition);
es.remove*(name, definition);

This is break from the common way of setting up everything in advance, and instead does a lot at "runtime", making it more efficient for HMR and potentially allowing for "runtime packages" (that are installed in a running app).

But if I understood correctly, the proposal here is much better. However, @tomitrescak, I couldn't quite understand from the README what it would look like. Any chance of an example somewhere of how both an app, and package, would use this with each other?

[tomitrescak]

@gadicc I have recently updated the documentation.

My "solution" thinks a lot about importing modules from the packages.
All you need to do is import all modules from the package when you are constructing your schema:

import { addModules } from 'apollo-modules';
import { makeExecutableSchema } from 'graphql-tools';
import { modules } from 'my-package'; 

const modules = addModules(modules);

// build your schema 
const schema = makeExecutableSchema({ typeDefs: modules.schema, resolvers: modules.resolvers);

Using the below definition of modules, you can even specify how given module changes context on each request in modifyOptions function:

interface ApolloModule {
  // definition of types 
  schema: string;
  // definition of queries
  queryText?: string;
  // implementation of queries
  queries?: Object;
  // implementation of type resolvers
  resolvers?: Object;
  // definition of mutations
  mutationText?: string;
  // implmentation of mutations
  mutations?: Object;
  // allows you to modify apollo Options (e.g. context) based on current request
  modifyOptions?: (req: any, apolloOptions: ApolloOptions) => void 
}

The REAL downside of this approach is that this would have to become a "standard" as you need to construct your whole schema using apollo-modules and you cannot combine approaches.

[stubailo]

This is a great solution, for now we have these directions as well: http://dev.apollodata.com/tools/graphql-tools/generate-schema.html#modularizing

I think adding the following specific feature will resolve the rest of the needs for which one would currently need apollo-modules: #182

But I'm excited about continued innovation in schema development!