Define directives for HTTP compression on the client-side and HTTP caching on the server-side about graphql-over-http

[benjie]

Again, I think this would be better served by HTTP content negotiation, in this case you could add Accept: application/graphql+jsoncrunch, application/graphql+json, application/json or some such.

[isocroft]

OK @benjie , you do have a point. It's much better and more conformant to the use case than utilising directives. However, i want to ask: are these mime-types standardised for use via the HTTP RFCs ?

[benjie]

Why does regular HTTP content negotiation not sufficiently fulfil this need?

[isocroft]

Hello @benjie, yes, proactive HTTP content negotiation does in fact cover/include HTTP compression. However, one GraphQL client can request a GraphQL response with or without compression (e.g. gzip - because it supports stream compression; think @defer, @stream directives) depending on the size of the response but yes they can go hand-in-hand. Also, for most GraphQL clients and servers out there in the wild, the primarily popular Content-Type is set to application/graphql (which i think is in the process of being standardised) OR application/json. In other words, JSON is preferred over say XML (which can also be a valid response content type format for GraphQL). But for compression, it should statutorily optional.

Furthermore, a directive might be beneficial to apply HTTP compression only above a given JSON response size on the server-side. I also do believe it has more benefits to the many way GraphQL responses could be delivered quickly than applying deduplication as an alternative which doesn't work with streamed content (HTTP 1.1 streaming) as the response has to be complete before deduplication can take place. HTTP compression can also be effectively disabled (by default) at the GraphQL level (especially if the GraphQL server utilises signed HTTP cookie(s) for authorization and hence needs to worry about CSRF and consequently the BREACH attack linked to HTTP-level compression).

[isocroft]

Also, @benjie, another scenario will be to rename the directive from @httpCompressed to @compressed. This will enable deduplication to be used alongside HTTP compression (gzip). So, the GraphQL server may inspect the query and if it doesn't find directive that might suggest the use of HTTP 1.1 streaming to formulate the GraphQL response (think @defer, @stream directives), the @compressed directive makes use of deduplication else it makes use of HTTP compression (gzip - stream compression support). This can further standardise control over how and when deduplication is applied from the client-side.

[benjie]

When you say deduplication, what exactly are you referring to?

[isocroft]

I mean removing duplicates that is and appears redundant in a given dataset as it applies to GraphQL response payloads (probably using logic like the one used here).

[benjie]

Not as far as I know; I don't think this specific spec would contain the GraphQL Crunch encoding for example, however this spec should be compatible with someone doing so. Much in the same way that the GraphQL Cursor Pagination Specification is not part of the GraphQL Spec, but is compatible with it. If changes are required to this spec to make it compatible I certainly support that 👍

Or if you mean the actual HTTP RFCs (rather than the GraphQL-over-HTTP RFC) then here's a good place to start your research: https://stackoverflow.com/a/11574673/141284

[ghmcadams]

Closing this issue. There appears to be agreement that the solution is a combination of standard HTTP compression and HTTP content negotiation.