Modular definition of schemas (extensibility)

[tomitrescak]

Hi, I'm actively working with apollo and loving the experience. I just want to contribute with an opinion on a possible improvement of schema handling. What I feel that is a drawback of the current approach is the monolithic definion of Apollo schema, which does not provide extensibility through packages. It is quite difficult to produce modules or import packages that add on top of current functionality (e.g. authentication packages, system modules and more).

What would be great is to have the possibility to define functionality per domain element, where each domain element would export the list of:

schema
resolvers
queries
queryResolvers
mutations
mutationResolvers

With a current approach it is possible to define only schema and resolvers and import it into Apollo, queries and mutations got left behind. I got this working in my apollo-mantra project but it's a rather silly solution which heavily depends on my custom functionality and makes no sense to share it. Would you consider implementing something like this in core?

[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!

[lucasconstantino]

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