SingalR and Async API

I think you should really look at Async API first ;). 

AFAIK it aims to do what you describe. It it not a tool. It is an agnostic spec for describing async communication.

But I do agree with the last point. There is going to be an overlap in complex systems where both means of communication are used. A bridge of sorts would be quite useful. I’m pretty sure there is related research in the REST community.

Tom

On 9 July 2019 at 22:19:58, Karol Szczepański (karol.szczepanski@gmail.com) wrote:
> > We should make this more egalitarian. Otherwise is it currently a bus factor of 1?
>  
> For the time being yes.
>  
> > Web sockets is event-based communication. A paradigm pretty different from REST.  
> On top of that SignalR is quite opinionated.
>  
> It doesn't matter, SignalR or Async API Initiative, and yes - event
> based communication is far from REST.
> What matters is on how to propagate such a knowledge to the client, i.e.:
>  
> "Look client, here is what you need to do to subscribe for some events.
> Once subscribed, you're on your on with these events, but here is a
> receipt on how to get on the bus."
>
> In case of SignalR subscription is a matter of sending a couple of
> GETs to specified URLS with some query string params making it
> possible to describe such links
> (current SignalR client has these logic hardcoded), but I'm quite
> curious on how such an mental exercise could end up.
>  
> Actually, telling a client that there is another pipe with different
> protocol might be interesting and be of some value.
> HTTP spec defines i.e. 101 Switching Protocols status. Just loud thinking.
>  
> Best
>  
> Karol

Received on Tuesday, 9 July 2019 20:29:33 UTC