Module
Modules can be either local type definitions and resolvers, or a remote schema. Both can be freely combined and stitched together.
A module can expose the following values:
- name
- typeDefs
- resolvers
- extendTypes
- extendResolvers
- mocks
- mount
- transforms
- context
- dependencies
- onStartup
- onShutdown
Naming
A GraphQL module needs a unique name, compatible with NPM naming restrictions, as a module can also be published as an NPM package.
Structure
A module can be a single file, a folder with an index.js
, or an NPM module. Themis is aware of the package.json
file, which can specify the entry point of the module. Themis will use the name of the package for the module. A common structure for a module is:
module-root
├── index.js
├── resolvers.js
└── schema.js
You can see how a basic module looks like in the Getting Started guide.
typeDefs
Parsed GraphQL type definitions. A plain text schema can be parsed with graphql-tag for example, which is also exposed by Themis.
resolvers
Resolvers to be mapped on the type definitions to create an executable schema.
extendTypes
To extend types of other modules, we must provide these in addition to possible local types. Must be used in conjunction with extendResolvers
.
extendResolvers
Extends the existing resolvers of other modules.
Dependencies
A module can express the dependency on another GraphQL module by exporting a list with module names.
Example with dependencies:
module.exports = {
name: 'custom-article',
typeDefs,
resolvers,
dependencies: [
'user',
'remote-article',
]
}
GrapqhQL module dependencies can be specified in a package.json
as well with the gqlDependencies
key as a list of module names.
Schema Delegation
The schemas from all modules are made available in the resolver context
as the reserved attribute schemas
, which is a map with the module name as a key and the executable schema as a value.
Assume you have two modules, article
and teaser
, then you can access the teaser schema in an article resolver for schema delegation like so:
(parent, args, ctx) => {
// ctx.schemas['teaser']
}
Transforms
Both a local and a remote module can export transforms
, which will be applied after creating an executable schema. Read more about it in the Transforms docs.
Context
The context
can be either a function or an array of functions, which will be called in a request/response query cycle. The function may return an object to be merged with the remaining context. Context functions will be called in the order the modules are loaded. Context functions from the configuration file are called before all others. If different context functions try to expose the same key on the context, they may override each other.
A context
function gets an object with the req
and res
of the query. When using Subscriptions, the object will contain the connection
key.
Lifecycle Hooks
Lifecycle hooks allow to execute something onStartup
, just before the server will be mounted at the given port and onShutdown
, after a kill signal has been received (SIGTERM|SIGNINT).