Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

websocket / subscriptions support? #26

Closed
waterdrop01 opened this issue Feb 27, 2019 · 6 comments · Fixed by #55
Closed

websocket / subscriptions support? #26

waterdrop01 opened this issue Feb 27, 2019 · 6 comments · Fixed by #55
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@waterdrop01
Copy link

Hi there,

I was wondering if there is support for websocket subscriptions?

Thank you!

@barbieri barbieri self-assigned this Feb 27, 2019
@barbieri barbieri added enhancement New feature or request help wanted Extra attention is needed labels Feb 27, 2019
@barbieri
Copy link
Member

Not yet, @netogallo seems to be working on it, as per #23.

I'm busy with some work-related stuff, but as soon as things calm down I'd like to implement that on top of aiohttp, also adding the async endpoint.

@metachris
Copy link
Contributor

I'd also be very interested in subscription support! Going to need it one way or the other :D

@ecthiender
Copy link

I just published a python GraphQL client library supporting subscriptions over websocket. Check it out here. Contributions and comments are most welcome.

pip package
Source

josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 23, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 23, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 24, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 24, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 24, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 24, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and collects results to a list.  The list can then be
interpreted to Operation based objects by:
  [(op + result) for result in endpoint(op)]

Fixes profusion#26.
@josephlbarnett
Copy link
Contributor

The referenced PR implements a synchronous websocket endpoint that returns all the data objects after completion. Async may make more sense for some, but this fits our use case at the moment.

@barbieri
Copy link
Member

hi all, the PR #55 is great and about to be merged, but I have a question to users (asked there, but you can also answer here):

Is it better to accumulate a list during the whole session, until completed message arrives? Or should we progressively yield result as each message is processed? In my mind the yield would be required by subscription usage, since you're progressively receiving more data you want to process immediately, not at the end.

On a related question: should we create the websocket internally and execute one single query as it's implemented in #55, or should we create it in 2 phases:

  • WebSocket wrapper: connects, does the id generation and dispatching of messages ("observer")
  • WebSocket endpoint, that takes the wrapper above and issue one single query by queueing it to the wrapper, then when the replies arrive it will yield the results to each endpoint.

This would not be required for "app with one subscription" (as it would be the same), but if we do have multiple subscriptions, or want to interleave multiple queries/mutations/subscriptions in the same channel (saving the connection time for each), it would be required.

Move to yield is reasonably simpler... but to interleave multiple operations would be more work.

josephlbarnett added a commit to josephlbarnett/sgqlc that referenced this issue Jul 24, 2019
Implement the apollo graphql-ws protocol as a subclass
of BaseEndpoint.  Allows for both 'normal' queries as
well as subscriptions to be executed over a websocket
and returns a generator of results.  The generator can
then be interpreted to Operation based objects by:
  ((op + result) for result in endpoint(op))

Fixes profusion#26.
@barbieri
Copy link
Member

merged with single query support. We can extend it to support multi query later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants