-
Notifications
You must be signed in to change notification settings - Fork 92
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
graphql: subscriptions at the scheduler #3731
Comments
From:
This means, all the filtering is done by the subscriber (ATM) (if you subscribe to a topic, all it means is you're receiving and throwing away all the other topics)... i.e. if we setup a GraphQL publish to a subscription, then it will be sent to all subscribers, and they will just ignore it.. It, more obviously, means the PUB can't tell if a SUB is killed in order to stop a subscription (and I don't know if you can rely on a last REQ on death of client).. Otherwise the only other solution along side PUB/SUB would be to send a REQ with info about the subscriber for polling or something.. So probably not what we want.. (we also don't care about scalability on the Scheduler (PUB) end as it's just a UIS, a few TUI's... I'm not sure how heavy the CLI will be..) So we'll keep looking for something that allows some "back-chatter".. |
Bit on the need to know about a client/server being alive (heartbeats): |
I have an idea, and it's based on the REQ/REP PUB/SUB patterns but incorporates:
Into a service that will work for both GraphQL and real command response. The idea is for the client (UIS/CLI) to:
The server/Scheduler will:
The content of the client request to a new
Or for protobuf/data-store deltas:
Or a command:
The The heartbeat would contain the the The Scheduler/publisher would register the ongoing subscriptions in a mapping to the client ID:
With the resulting set of ongoing published topics being:
This can be recreated/updated super quick with each deletion/addition using set operations (via a method in the publisher object)... On of the main benefits of this approach are:
Thoughts? |
At first glance, it sounds pretty good to me. However I'm not exactly au fait with comms patterns etc., I'll need to get a better understanding (after the beta release is out) |
Have put up a draft PR (#4274) for this one, I have a clear road map of how I want to achieve this therein... Step 1 is done, which also has the benefit of moving most of the network related code out of the |
Prerequisite to #3527
Implement the following component of the interfaces and protocols diagram:
Running GraphQL subscriptions over ZMQ/TCP is non-standard so this will require a bit of work at our end.
This may just involve patching in our pub-sub / req-rep endpoints to the existing websockets functionality as conceptually only the connections and transport differ. We should be able to use the same GraphQL server infrastructure.
Perhaps we should take this opportunity to consider whether there is a nice simplification of the existing req-rep / pub-sub duo, perhaps we could merge them with xpub-xsub or something else? Ping @dwsutherland.
Pull requests welcome!
The text was updated successfully, but these errors were encountered: