3 ms·

I've read comments here on HN that the server side of graphQL is notorious hard to implement, the resolvers end up being really complicated or slow. Anyone car

• andrewingram 9y ago
  2 years of experience, it's easy. As long as you resist the temptation to build clever abstractions too soon, there's nothing hard about it.
• 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.