No way to get requested fields inside resolver

[auwtch]

Problem:
Inefficient microservice/database queries.
If I need to return 100 orders with their clients, I have to make 101 requests to microservices (1 for batch of orders, 100 for their clients (one per each order)).

Scheme (simplified):

type Query {
  orders: [Order]
}

type Order {
  id: ID
  client: Client
}

type Client {
  id: ID
  name: String
}

Query:

query GetOrders {
  orders {
    client {
      name
    }
  }
}

Resolvers:

func (r *Resolver) Orders() []*orderResolver {
	data, err := Request(orderService, "Order.List", &Args{}) // returns batch
	...
	return // batch of 100 order resolvers
}

// 100 client resolvers - 100 requests
func (r *orderResolver) Client() *clientResolver {
	data, err := Request(clientService, "Client.Get",&Args{) // returns one 
	...
	return // a client resolver
}

Instead, I'd like to know (in the order resolver) that the field with clients has been requested.
So I could make one batch request at the order resolver level.

Something like this:

func (r *Resolver) Orders(ctx context.Context) []*orderResolver {
	data, err := Request(orderService, "Order.List", &Args{}) // returns batch
	if ctx.Value("fields")... {
		  clients, err := Request(clientService, "Client.List",&Args{) // batch
        }
	...
	return // batch of 100 order resolvers witch clients inside
}

So I get 2 request.

[neelance]

This is definitely a feature we should think about. Is there anything like that in the graphql-js implementation?

I am a bit worried that this can cause people to write bad resolvers. One nice attribute of GraphQL are all those consistency guarantees it provides.

[nicksrandall]

I agree that this could cause people to write bad code resolvers, but it could also help write efficient resolvers. For example, one could use that information to prevent an unnecessary "join" in his/her db query if the user didn't ask for any of those fields. Also, it could give user the ability to log which fields are being requested most frequently and then perform optimizations on those fields (like pulling from redis-cache rather than db).

The last variable passed to graphql resolvers in graphql-js has lots of info about the schema, fields, ect...

see: https://github.com/graphql/graphql-js/blob/master/src/type/definition.js#L489

[neelance]

@nicksrandall Do you know any example code that uses this feature with graphql-js?

[nicksrandall]

@DenisNeustroev Facebook has a recommendation on how to solve the n+1 problem with a technique called DataLoader. I have taken a stab at implementing this technique in go here: https://github.com/nicksrandall/dataloader.

@neelance I am not aware of any examples of people using the schema info in a resolver but I haven't done much research on the subject.

[F21]

Being able to see what fields were requested would make it super easy to select a specific list of columns when performing an SQL query in a resolver. That means, we don't have to get all fields (SELECT * FROM) which could be more efficient.

[mvpmvh]

I know context can be a divisive topic in go, but reading the graphql spec had me wondering: if a resolver gets 3 args (i.e. obj, args, context), could a server implementation stuff the selection set in there? Off the top of my head I was thinking if the context knew the selection set and knew what in the selection set had already been resolved, it could save on extra requests

[tj]

I have a similar issue, need a way to either defer the resolution so I can produce a query, or some way to access the nested fields of the query to properly form the query instead of simply filtering results a very expensive query (or possibly unknown, in which case it's impossible). Anyone come up with a workaround?

EDIT: I ended up hacking it in. I think ideally there could be an optional preparation pass to the set of resolvers, or some similar set of structs, letting you construct the queries necessary first. Some variant of that haha.