Should GraphQLRequest parse operation_name from the query?

[cjvk]

As I read the GraphQLRequest docs (and how we've implemented), the caller is expected to populate operation name (well it's optional, so "expected" isn't quite the correct word), which will then be automatically deserialized. From the perspective of a caller, isn't it somewhat odd to send the query, the input data, and also the operation name?

The server could parse the operation name from the query - and this is how our server code works, as a backup. But this seems suboptimal, since the code has to be written by all clients.

Is it possible for the Juniper library to do the parsing, and populate operation_name?

[tyranron]

@cjvk query parameter is essentially a document, not just a single operation. operationName parameter, if specified, contains the name of the exact operation from query document, the client wants to execute.

It's not something invented by juniper creators and maintainers. We're just trying to align with existing spec of GraphQL ecosystem, to integrate naturally into it. See GraphQL Over HTTP spec for details.

The server could parse the operation name from the query - and this is how our server code works, as a backup. But this seems suboptimal, since the code has to be written by all clients.

It's not like the server could or couldn't. The GraphQL spec specifies the exact algorithm the server should follow: 1, 2, 3

Is it possible for the Juniper library to do the parsing, and populate operation_name?

I guess, no.

First, the query parsing doesn't happen in GraphQLRequest, because it only holds raw data of the request. The parsing itself happens when the GraphQLRequest is executed via juniper::execute().

Second, even if we do that somehow, it seems to be just not right, because GraphQLRequest is a representation of an exact input from the client, we shouldn't dare to customize in any way.

If you do really need operation name detection, you should use the GetOperation() method declared by GraphQL spec for that. As juniper doesn't expect library users to dig into internals, it's somewhat hidden at the moment. But something like this should do the job:

let req: GraphQLRequest = from_whatever_source();
let document = juniper::parser::parse_document_source(document_source, &schema)?;
let operation = juniper::executor::get_operation(&req,query, req.operation_name.as_ref())?;

You also need to use master for this, as the 0.15 juniper sadly doesn't allow access to query inside GraphQLRequest.

It seems more feasible to me, in future releases of juniper, to make the execution process more granular, so the results of its stages may be easily reused by library users.