Support sending `operationName`

[onionhammer]

OperationName is useful for logging purposes, frameworks like HotChocolate have a built-in field to handle it

Describe the solution you'd like
Pass operationName in the request payload

Describe alternatives you've considered
using a customFetch operation and extracting the operationName from the queries sent in

Additional context
Add any other context or screenshots about the feature request here.

[onionhammer]

Hi @lynxtaa - is it possible to get this merged in the next couple months? If not I will have to figure out an alternative library/maintain a fork for now before I roll usage of this library into production - we currently rely on being able to see the operation name for monitoring performance of our queries

[lynxtaa]

Hi @onionhammer ! Thanks for the MR, I'll review it next week :)

[lynxtaa]

I have some troubles understanding why this feature is needed. The client doesn't need to send an operationName, the name of the operation would still be accessible on server after parsing the query. Right now I'm using Apollo Server and operationName is easily accessible for logging and tracing. Could you please provide more info?

[onionhammer]

I have some troubles understanding why this feature is needed. The client doesn't need to send an operationName, the name of the operation would still be accessible on server after parsing the query. Right now I'm using Apollo Server and operationName is easily accessible for logging and tracing. Could you please provide more info?

Interesting, HotChocate server does not automatically extract that from the body of the query, I will do a little more research and get back to you tomorrow.

[onionhammer]

Per the GraphQL Spec: https://spec.graphql.org/October2021/#GetOperation()

GetOperation(document, operationName)
If operationName is null:
If document contains exactly one operation.
Return the Operation contained in the document.
Otherwise raise a request error requiring operationName.
Otherwise:
Let operation be the Operation named operationName in document.
If operation was not found, raise a request error.
Return operation.

So it looks like as long as you send the operationName when multiple operations are being sent, this client should be good, otherwise it wont follow the spec

[lynxtaa]

Sorry for the delay @onionhammer . I see that we have two cases:

1. Single operation in a query

In that case the operationName field is not required and I don't see any valid reason to support it. I would suggest you getting it server-side from the query.

2. Multiple operations in a query

In that case the operationName field is required and the solution in #87 won't work. To support multiple queries we must somehow allow passing an additional operationName field when calling client.request(...) to allow the library user to choose the operation. At this moment I'm not sure how to implement it. As I see graphql-request have similar issue graffle-js/graffle#64

[onionhammer]

The example I provided won't work 100% of the time, but the method in the pr would allow the user to put in the proper name of the operation

As far as my needs go, I have been able to extract the operation name from the server (for single queries)

[lynxtaa]

As far as my needs go, I have been able to extract the operation name from the server (for single queries)

That's great! Glad to hear it :)

Thanks for bringing this issue. When writing this lib I didn't know that the spec allows multiple operations in the same query. I'll keep this issue opened, maybe I'll manage to add the support for it later

[coratgerl]

Also need this feature for testing purposes with Playwright to wait for the response from a query or mutation. Currently, I can't ensure that the result of a query or mutation is received.

PS: The library is excellent and well-architected; it's just missing this feature for my current needs :(

[onionhammer]

I had to stop using this library because of this.

[lynxtaa]

@coratgerl If you're intercepting requests using Playwright you could parse the query inside the request body and get operationName:

import { Kind, parse } from 'graphql'

const body = JSON.stringify({
	query: `query ExampleOperation { foo }`,
})
const document = parse(JSON.parse(body).query)
const operationDefinition = document.definitions.find(
	def => def.kind === Kind.OPERATION_DEFINITION,
)
const operationName = operationDefinition?.name?.value
console.log(operationName) // ExampleOperation

[coratgerl]

Yes thank you, do you think that a similar parse can be included in awesome-graphql-client ?

[lynxtaa]

I'm keeping dependencies minimal (zero at the moment) and try not to depend on graphql library.

Maybe implementing interceptors support would help so that developers could add any functionality they want. But it seems not much better than the code example, still developer experience would suffer.

Or maybe it's time to depend on graphql parser and extract the operationName.

It's a tough choice. Sorry for all the inconveniences and slow progress on this issue