Stream: fhircast-github
Topic: docs / Issue #43 Make it clearer that the WebSub model is...
Github Notifications (FHIRcast) (Nov 15 2018 at 11:32):
lbergnehr opened Issue #43
There's some confusion on the WebSub model and that you cannot use it since you're system's end-user clients cannot open a socket to retrieve callbacks. This is not the intended model -- the common model is that the application servers are communicating and then communicating with its end-user clients in a proprietary way. This should probably be clarified in the spec.
Github Notifications (FHIRcast) (Nov 17 2018 at 19:02):
jeremysrichardson commented on Issue #43
I don't understand your point. Who thinks they cannot use it? Can you reframe your point? Maybe with an example?
My concern around the WebSub model is that it doesn't allow applications (whether desktop clients, browser apps, or servers) to talk across a firewall without punching a hole in the firewall.
Github Notifications (FHIRcast) (Nov 18 2018 at 09:52):
lbergnehr commented on Issue #43
A common misconception seems to be that the Client in FHIRcast (without the websocket addition) needs to be an end-user client, i.e. a thick client, a web application, a mobile app, etc. In most situations, however, it's not the user-facing client app, but rather that client's application server which is acting as the FHIRcast Client.
But, with the websocket addition, described in https://github.com/fhircast/docs/issues/33#issuecomment-425730218, the FHIRcast client and the user-facing client could be the same.
Github Notifications (FHIRcast) (Nov 20 2018 at 21:22):
isaacvetter commented on Issue #43
Hey @lbergnehr , I think we're about to make progress on a proposed Websocket approach. Lets include guidance in that documenation explaining that use of FHIRcast doesn't dictate application architecture.
Github Notifications (FHIRcast) (Feb 05 2019 at 14:38):
isaacvetter commented on Issue #43
In conversation with @lbergnehr and @Will Maethner, we discussed adding short explanatory text that the use of WebSub does require that the subscribing app have an accessible url and therefore likely has a client/server communication method. That method is outside the scope of the specification. The use of WebSub vs Websocket should be carefully considered based upon the subscribing app's architecture and the environment of the integration.
### When to use WebSub over WebSockets?
WebSub is easier to troubleshoot and debug
WebSub is much less likely to encounter problems with load-balancer, rever proxies or other network appliances.
Last updated: Apr 12 2022 at 19:14 UTC
