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

Subscriptions: SSE distinct connection support #1195

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

danplischke
Copy link

This PR introduces a first implementation of subscriptions over Server-Sent Events (SSE) based on the definition in graphql-sse. This provides an alternative to the existing WebSocket support, which is particularly useful in scenarios where WebSocket connections may be restricted (e.g., corporate proxies).

Key Features / Considerations

  • SSE Support: Added to the GraphQLHTTPHandler ASGI class, specifically for subscriptions.
  • Routing Requirement: The request must include Accept: text/event-stream to be routed to the SSE handler.
  • Distinct Connection Support: Currently supports only one subscription per HTTP connection ('distinct connection mode' in the protocol definition). The single connection mode would require state management, which has not been implemented due to Ariadne's stateless design.
  • Custom Starlette Response Class: A custom response class for SSE support has been added, based on the implementation in sse-starlette to avoid introducing an additional dependency.

It would be great to get some feedback from you on:

  • Does adding SSE support align with Ariadne's goals, given that the protocol is not part of the official GraphQL Over HTTP specification?
  • Should SSE be implemented as a separate handler, similar to WebSockets, or can it be integrated into the existing GraphQLHTTPHandler?
  • Should there be a way of disabling SSE support?
  • How can I best pass configuration options (i.e. send_timeout, ping_interval, headers, encoding) for the 'ServerSentEventResponse' from the 'GraphQLHTTPHandler'? Are parameters / member variables in the init of the 'GraphQLHTTPHandler' acceptable or do you see a cleaner alternative?
  • Since the 'subscribe' function returns formatted GraphQL errors as dicts, do you see a more elegant solution of passing them in an 'ExecutionResult' to the 'GrapQLServerSentEvent'? Modifying the 'GrapQLServerSentEvent' to accept dicts, seemed a bit hacky.

Looking forward to your feedback!
Thanks in advance!

@danplischke
Copy link
Author

Hey, I wanted to see if someone has any feedback for me on this.
Tagging @rafalp, since you have the most contributions in this project.

Thanks!

@rafalp
Copy link
Collaborator

rafalp commented Oct 10, 2024

Apologies @danplischke but I am no longer with Mirumee.

Poking @DamianCzajkowski

@mociepka
Copy link
Member

Hi @danplischke, thank you for the contribution. We are currently paced with commercial projects, but I am searching for a solution for you and the rest of the new PRs.

Are you on the time pressure?

@danplischke
Copy link
Author

Hi @mociepka
thanks for reaching back. No time pressure from my side. Currently, I just use my forked repository (https://github.com/danplischke/ariadne/tree/main) in a couple of projects.
But I think it would be nice to get this integrated eventually.

Let me know if I can somehow make this easier on you. Happy to help.

@rafalp rafalp added this to the Next release milestone Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants