Use GraphQL.js to create schemas, this library adds a few light-weight decorators that make object definitions less verbose.
There are a lot of other graphql-schema builders that use decorators. (see Alternatives below) This one is minimal. The goal is to use the graphql library directly, instead of trying to wrap it or add to it. This library simply adds a few decorators that solve the key painpoint in using GraphQL.js, namely needing to define an object twice, once for the graphql schema, and again for your internal model. thin-graphql-decorators
allow you to simultaneously define a class
and GraphQLObjectType
.
import { GraphQLSchema } from "graphql";
import { asGQLObject, Field, ObjectType } from "thin-graphql-decorators";
@ObjectType()
class Query {
@Field()
hello(name: string): string {
return `Hello ${name}!`;
}
}
const schema = new GraphQLSchema({
query: asGQLObject(Query)
});
For more examples see test.ts
npm i --save thin-graphql-decorators graphql
Enable these 2 flags in your tsconfig.json
{
"compilerOptions": {
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
...
The decorators take a single argument that allows you to configure the graphql type. For the most part they are a strict subset of the GraphQL.js naming conventions. See index.ts for the configuration interfaces.
Field
, Param
, InputField
all have a convenience variant that makes the type non-null or a list.
B
- _B_ang! i.e.new GraphQLNonNull(t)
ort!
L
- _L_ist i.e.new GraphQLList(new GraphQLNonNull(t))
or[t!]
LB
- a list that is not null i.e.[t!]!
i.e. FieldB
means a field that cannot be null !
i.e. ParamL
means an argument that is a list [..!]
If you have a circular dependancy, the conf
can be wrapped in a thunk. i.e.
@ObjectType()
class Foo {
// before
@FieldL({ type: Bar })
circular?: Bar[];
// after
@FieldL(() => ({ type: Bar }))
circular?: Bar[];
}
Bind the decorated parameter to the schmea context
.
Bind the decorated parameter to the schmea info
.
Given a class that was decorated with @ObjectType()
return it's GraphQLObjectType
instance.
Does this library do to little? Here are some of the alternatives I evaluated before building this library:
- type-graphql - It's the most popular. It does a lot and is framework like.
- typegql - Lighter weight than type-graphql.
- decapi - A fork of typegql that adds more stuff.
- graphql-schema-bindings
- metanoia
NOTE: At this time, TypeScript does not emit very detailed type information that can be used for reflection. So all decorators will be limited by how much they can infer types. I.e. cannot detect a list type, or the Promise resolve type.
MIT