Understanding the Apollo Default Resolver

According to documentation for Apollo’s GraphQL-tools:

You don’t need to specify resolvers for every type in your schema. If you don’t specify a resolver, GraphQL.js falls back to a default one…

The documentation goes on to state that the default resolver will look for a property on the parent object with the field name that’s being resolved. If that property is not a function, the value of the property is returned. But if the property does contain a function, then the default resolver calls it, and “passes the query arguments into that function.”

It wasn’t clear to me exactly what this meant, so I did some experimenting. Read more on Understanding the Apollo Default Resolver…

Building a Family Tree with GraphQL – Part 2: Adding New Resolvers

In my last post, I described how you can build flexible APIs with GraphQL, using a family tree API as my demonstration. The implementation of the API was fairly simple, and I was able to traverse the graph of relationships between different people in the data set.

In this post, I’ll demonstrate how we can extend the same API to solve a problem with the first version. We can create new resolvers to fix a particular problem, but due to the nature of GraphQL, the same resolver can be used across many different queries. This unlocks more potential for the API without any extra development effort. Read more on Building a Family Tree with GraphQL – Part 2: Adding New Resolvers…

Optimizing GraphQL Queries with DataLoader

In my post about GraphQL and the Apollo server tools, I primarily focused on setting up a simple GraphQL schema and set of resolvers, but did not go much deeper. The main example in that post defined a findBy method which simulated hitting a database, but for the sake of brevity, this detail was largely overlooked.
Read more on Optimizing GraphQL Queries with DataLoader…