graphql-python/gql

[Feature] Support Subscriptions HTTP Multipart Protocol

Opened this issue ยท 6 comments

I think you're mixing two different things. The HTTP callback protocol that you first linked is different than the Multipart HTTP protocol (which is on the next page of the docs).

In the callback protocol, you have to create a server and send an url to the backend so that it could send answers to your own server.
In the Multipart protocol, you do an HTTP request which is long lived and will not close the connection but instead continue to send data as new events happen. There is no need for a server there.

I suppose you're interested in the Multipart protocol and not the callback protocol.

In that case, do you know a public backend which supports this protocol already that we could use to test this functionality?

Yep, you're correct about the differences... also for context, I'm a Solutions Architect at Apollo. ๐Ÿ˜„

I linked both for context but yes you're correct that what I'm interested in is the client portion, the Multipart protocol.

I don't know of a public backend currently... but I can help with testing by providing a private test repo (and adding you to it) and temporarily issuing an Apollo Key to a test graph.

@leszekhanusz @andrewmcgivery I'd be happy to help with this :)

If you need a backend for testing this I can make a an example with Strawberry (I have a PR open to add multipart support: strawberry-graphql/strawberry#3076)

Yep, you're correct about the differences... also for context, I'm a Solutions Architect at Apollo. ๐Ÿ˜„

Oops ๐Ÿ˜†

I don't know of a public backend currently... but I can help with testing by providing a private test repo (and adding you to it) and temporarily issuing an Apollo Key to a test graph.

That would be nice, but I would like to take this opportunity to ask if you could maybe propose in your organization to make a very simple public server to allow any user to test clients for GraphQL subscriptions. I think that would be a very nice gift to the GraphQL community.

With gql, we are using https://countries.trevorblades.com for most of our examples, but they dropped the websockets endpoint, so a public GraphQL backend which supports both the websocket and multipart protocol would be really nice. The actual schema could be something really simple like a subscription for a number counting to 10 with a 100ms interval for example. The bandwidth should be minimal as this serves no purpose except for a few tests. If that's not possible, no worries I'll use the private test repo.

If you need a backend for testing this I can make a an example with Strawberry (I have a PR open to add multipart support: strawberry-graphql/strawberry#3076)

That would be great!

Note for both of you: Is there a list somewhere of clients/servers supporting the multipart protocol in all languages? Something like the GraphQL file upload spec

Yep, you're correct about the differences... also for context, I'm a Solutions Architect at Apollo. ๐Ÿ˜„

Oops ๐Ÿ˜†

I don't know of a public backend currently... but I can help with testing by providing a private test repo (and adding you to it) and temporarily issuing an Apollo Key to a test graph.

That would be nice, but I would like to take this opportunity to ask if you could maybe propose in your organization to make a very simple public server to allow any user to test clients for GraphQL subscriptions. I think that would be a very nice gift to the GraphQL community.

With gql, we are using https://countries.trevorblades.com for most of our examples, but they dropped the websockets endpoint, so a public GraphQL backend which supports both the websocket and multipart protocol would be really nice. The actual schema could be something really simple like a subscription for a number counting to 10 with a 100ms interval for example. The bandwidth should be minimal as this serves no purpose except for a few tests. If that's not possible, no worries I'll use the private test repo.

I'll chat internally to see what we can do. :)