3 ms·
I've implemented three graphql backends - one wrapping a rest api, one wrapping mongo, and one wrapping postgres. The key, just like in rest, is to keep the dif
by strken 9y ago
I've implemented three graphql backends - one wrapping a rest api, one wrapping mongo, and one wrapping postgres. The key, just like in rest, is to keep the different layers isolated. If your resolvers never do anything more complicated than parsing arguments and passing them to the next layer, it's hard to make them complicated. One project parses the graphql ast and there's a small performance gain from that, and another batches identical requests with Facebook's DataLoader library, but those are done behind the scenes and don't end up polluting the resolvers, and to be honest they probably weren't necessary.
Most of the resolvers end up looking something like
{
type: FooType,
args: {
fooId: GraphQLString,
...paginate.args,
},
resolver: createRESTResolver(
({ fooId }) => [`${services.foo}/:fooId`, { fooId }]
).use(paginate),
}
but if I was doing it again I'd probably abstract the creation of the entire field rather than just the resolver.