-
Notifications
You must be signed in to change notification settings - Fork 249
-
The subscription implementation code seems pretty tightly bound to websockets. Am I missing an obvious solution?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 8 comments 9 replies
-
sorry, would be great to move to discussions tab? I also try to implement graphql subscription using SSE. There is documention of subscription implementation at https://mercurius.dev/#/docs/subscriptions?id=subscriptions. Maybe it can be the starting point
Beta Was this translation helpful? Give feedback.
All reactions
-
We may consider looking into providing a way to integrate with https://the-guild.dev/blog/graphql-over-sse instead of building it up from scratch
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
I'm not sure it's a viable option given how the code is structured inside this module. Anyway it would be a good PR.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1
-
This would be an interesting discussion (feel free to move to the Discussion section).
I'm currently looking to add support for the full WS transport (i.e. to be able to send all operations via WS: query, mutation and subscription, see #195) and I also thought about SSE. I feel that we are maybe reinventing the wheel here... my first thinking was, ok cool let's do that by integrating with these libraries:
https://github.com/enisdenjo/graphql-ws
https://github.com/enisdenjo/graphql-sse
In fact, by default, mercurius is using the same WS sub-protocol of the graphql-ws
library.
However, as @markrzen says above, we currently have a custom subscriptions implementation pretty hard bound, so I don't really know if that would be possible. I mean, it definitely is but it feels that we would need to refactor some logic in order to do so... what do you think about it? It would be better to integrate or we need to re-implement internally?
Beta Was this translation helpful? Give feedback.
All reactions
-
Is there any updates here? This would be an amazing feature to have. As well as to have support for the gateway option. I currently am looking to use fastify as a gateway for multiple services, some will be node and some will be java but I intend to use graphql-sse instead of websockets.
Beta Was this translation helpful? Give feedback.
All reactions
-
@markrzen @Ancient-Dragon what's your use case for subscriptions over sse?
Beta Was this translation helpful? Give feedback.
All reactions
-
We would be looking to stream notifications and potentially price updates back to our users, as well other things. All of these will come from different microservices
Beta Was this translation helpful? Give feedback.
All reactions
-
Ok so it's about infrastructure. Authentication is fairly simple, I wouldn't consider it a blocker for WS compared to SSE
Beta Was this translation helpful? Give feedback.
All reactions
-
I don't suppose there are any updates here in terms of supporting SSE subscriptons in the mercurius gateway?
Beta Was this translation helpful? Give feedback.
All reactions
-
Not that I'm aware of
Beta Was this translation helpful? Give feedback.
All reactions
-
Have you looked into the approach described here? https://www.the-guild.dev/blog/graphql-over-sse#with-fastify
Beta Was this translation helpful? Give feedback.
All reactions
-
Would that be all you needed to do with mercurius as a gateway though? How would it know which service to use?
Beta Was this translation helpful? Give feedback.
All reactions
-
sse is not supported out of the box and based on earlier conversation it doesn't look like it's either simple to do or in the roadmap. on the other hand, using existing libraries alongside mercurius to have sse support (especially but not exclusively for subscriptions) is fairly easy. I put together an example to illustrate this https://github.com/simoneb/graphql-sse-mercurius
Beta Was this translation helpful? Give feedback.