Stream: FHIRcast
Topic: websockets subprotocol: subscriptions vs fhircast
Isaac Vetter (Jan 14 2021 at 17:41):
During the connectathon, we talked through some of the differences between and a potential goal of harmonization of the FHIRcast websockets "sub-protocol" and that being introduced in FHIR Subscriptions.
My take is that Subscriptions approach is more thorough, and also more complicated and more difficult to implement.
cc / @Bas van den Heuvel, @Catie Ladd , @Eric Labadie , @Gino Canessa
Gino Canessa (Jan 14 2021 at 18:59):
That sounds like a fair assessment. We tried to keep implementation as simple as possible, but with the additional constraints:
- a single connection must support multiple subscriptions
- the server needs a way to periodically (as they determine) enforce authorization
- renewals should be allowed without reconnecting, to reduce the possibility of missed events
Having done a naive implementation, it didn't feel too complex. I can see becoming a bit more difficult when the websocket endpoint is disassociated with the token-generation endpoint, since you need to sort out a method of communication there. But, in that architecture you need a mechanism to feed it notifications anyway and it is unidirectional - the websocket server doesn't generally* need to communicate back.
*Unless the server wants to keep track of notification status and connected clients outside the websocket handler service and there isn't anything in place to do that already.
With all of that said, I would be happy to discuss any revisions/ideas that could help them align better.
Bas van den Heuvel (Jan 14 2021 at 19:05):
The main question here is whether the design rationales used by Gino also apply to FHIRcast. The main requirement is the first one: "a single connection must support multiple subscriptions". Is this a general requirement that needs to be taken into account also by FHIRcast
?
Last updated: Apr 12 2022 at 19:14 UTC
