Mechanism for optional features

[sjparsons]

It's come up a number of times in our discussions as a working group: We would like to have optional features that can be adopted and if adopted by a server/client then that section of the spec can be applied. I believe we need a mechanism for this.

1. Documentation: we need to add a section to help organize and specify these optional features
2. Communication: Servers need to communicate which features they support and clients need to communicate what features they wish to use.

I know we wish to leave many of the optional features to be defined after the 1.0 release, but I'm wondering whether the mechanism should/could be put in place for the 1.0 release, so that we have a firm foundation and clear runway after the 1.0 to start building extensions and optional features.

I'm interested in hearing (1) opinions on 1.0 or post 1.0 release and (2) ideas about possible solutions for the 2. Communication mechanism described above.

[benjie]

It would be good to compile a list of possible features we might want to expose, since these may affect the results we come up with (e.g. are they individual named features, or are they groups of features with configuration?). Off the top of my head:

• queries over websockets
• mutations over websockets
• subscriptions over websockets
• automatic persisted queries (reducing network overhead of repeated operations)
• static persisted queries (operation allow-list)
• query batching (queries only, no special directives, minimises roundtrips, better solved by HTTP/2.0)
• operation batching (as above, but for both queries and mutations; subscriptions don't make sense here?)
• operation batching and chaining (e.g. @export directive like https://hotchocolate.io/docs/batching, allowing the output of one operation to affect the input of the next)
• @stream/@defer over websockets
• @stream/@defer over chunked encoding
• @stream/@defer over HTTP2 streaming
• live queries via directive (via transport mechanism?)
• live queries via entire operation over websockets
• file uploads via multipart/form-data