Stream: subscriptions
Topic: Subscription per subscriber?
Jenni Syed (May 05 2019 at 15:16):
One of the discussions we had at the table during the connectathon was around the awkwardness of the Subscription resource to subscriber. A basic summary:
- For email, SMS, and resHook, it is clearly a subscription:subscriber (many:1) relationship because the subscription has data that is obviously specific to the subscriber.
- for WebSockets, there was some confusion around this. The websocket endpoint is common to all subscribers - though there are other details on subscription that definitely define the subscriber. It feels interesting to require every websocket to be unique even if the criteria is the same.
Jenni Syed (May 05 2019 at 15:16):
In the first case, the server can still fan out - essentially gather the same subscriptions behind the scenes and send the message to all interested parties
Jenni Syed (May 05 2019 at 15:22):
The websocket modality is a little different. We're requiring different binds when technically, the server should be able to handle the common subscriptions on the same bind when the criteria are the same
Jenni Syed (May 05 2019 at 15:23):
This gets closer to the topic conversation that came up during our Event conversations
Jenni Syed (May 05 2019 at 15:23):
I'm leaving this conversation here for others to add or extend... :)
Grahame Grieve (May 05 2019 at 15:31):
I haven't really understood this thread - the fact that there is one websocket end-point doesn't mean that you run more than one subscription per web-socket connection?
Jenni Syed (May 05 2019 at 15:37):
@Grahame Grieve The general opinion here is that a server would likely (if subscriptions wasn't defined like this) have all subscribers that have the same criteria bind to the same "topic" vs binding to each subscription uniquely
Jenni Syed (May 05 2019 at 15:37):
eg: if 1000 people want Observation?category=laboratory, they would all have the same bind
Jenni Syed (May 05 2019 at 15:38):
but today, they would bind to 1000 different messages
Grahame Grieve (May 05 2019 at 15:38):
that is, if the were only a few topics
Jenni Syed (May 05 2019 at 15:38):
no, even if the server was really amazingly scalable and had a whole compute stack ;)
Jenni Syed (May 05 2019 at 15:39):
IE the server behind the scenes is finding the commonalities anyway today for scale/sanity
Michele Mottini (May 05 2019 at 15:45):
Requiring different binds for web socket means also that the same client will generate new subscriptions every time it re-starts (assuming it does not go through the trouble of deleting the old one - that for a browser-based client is difficult)
Michele Mottini (May 05 2019 at 15:46):
But sharing bindings is not really possible because if the client actually _do_ delete the subscription it will break it for everyone
Grahame Grieve (May 05 2019 at 16:00):
the way the current subscription works, the client can subscribe to whatever it can describe. given that, I don't find the idea of 1000 clients subscribing to the same thing very compelling
Grahame Grieve (May 05 2019 at 16:00):
are we saying that we think the current method is jsut crap and we want to toast it in the interests of scaling the implementations?
Brandon Pollett (May 05 2019 at 16:03):
If you have 1000 patients all using the same client application, it would be much more efficient if they all listened to the same subscription
Brandon Pollett (May 05 2019 at 16:04):
The server could realize it needs to ping all these websocket connections given this single subscription fired.
Grahame Grieve (May 05 2019 at 16:06):
1000 patients would have to listening to differnet subscriptions, since it's different patients. No?
Brandon Pollett (May 05 2019 at 16:07):
Depends on the criteria.
Grahame Grieve (May 05 2019 at 16:08):
well, I presume you don't mean 1000 patients all listening to the same patient results - I presume you mean that somehow the patient-ness of the subscription is... implicit....
Brandon Pollett (May 05 2019 at 16:09):
Or not required... something like the application wants to know when a slot becomes available.
Grahame Grieve (May 05 2019 at 16:09):
sounds like a fun auction.... but ok
Last updated: Apr 12 2022 at 19:14 UTC
