Spec Improvement for the broader GraphQL Ecosystem about graphql-multipart-request-spec HOT 4 OPEN

I'd like to add that the spec currently defines that the graphql query itself as well as the mapping for the files are json encoded. Since the GraphQL spec does explicitly not define an encoding, this spec shouldn't either. An example would be that a server uses CBOR instead of json for the "normal" GraphQL queries but then has to decide if it should require the mapping for the files to be cbor too or json.

This is not great and would cause different behaviour across implementations where one expects json and the other the same encoding as everywhere else.

from graphql-multipart-request-spec.

Also why not expand the spec for responses? There are probably some cases where a external cdn is too much but just putting the stuff directly in a field in the response isn't great either.

from graphql-multipart-request-spec.

@Erik1000 regarding #55 (comment)

the [GraphQL multipart request] spec currently defines that the graphql query itself as well as the mapping for the files are json encoded. Since the GraphQL spec does explicitly not define an encoding, this spec shouldn't either.

The official GraphQL Foundation GraphQL over HTTP spec (still a draft) does in fact require servers and clients to support JSON:

Servers and clients over HTTP MUST support JSON and MAY support other, additional serialization formats.
— https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#serialization-format

The point of the GraphQL multipart request spec is to allow all sorts of clients to send file uploads to all sorts of GraphQL APIs; if we have different versions of a spec for serialization formats other than JSON then it undermines this goal. JSON is by far the easiest to work with in browser code, where the size of your code and dependencies really matters for performance. I think it's safe to assume almost all server environments have the means to process JSON, but JSON is one of the only serialization formats clients can elegantly work with (without introducing third party library bloat).

Regarding #55 (comment)

Also why not expand the spec for responses?

This was one of the first things considered years ago during early experimentation, but I haven't met anyone that wants or needs this yet. If it's something you want to experiment with, keep in mind that there is a GraphQL over HTTP RFC for incremental delivery that specifies multipart/mixed GraphQL responses. It doesn't interfere with multipart GraphQL requests because it's for responses:

graphql/graphql-over-http#124 (comment)

But if you plan to experiment with multipart GraphQL responses for file downloads within the response, it might need to be accounted for as a user might want both file downloads as well as an incremental delivery?

from graphql-multipart-request-spec.

The official GraphQL Foundation GraphQL over HTTP spec (still a draft) does in fact require servers and clients to support JSON:

I see, didn't know about this spec. Why not write it like the spec itself? E.g. json MUST be supported but a server MAY also accept everything serialized in something else (like CBOR).

As for incremental delivery, I'll look into that, seems interesting!

from graphql-multipart-request-spec.