HTTP Message Transport

[jeremydmiller]

Problem

• The node assignment and cross-node communication requires a lot of request/response that's today done mostly through the simplistic database control queues -- which is a fancy way of saying "polling". This communication is super sensitive to timeouts with the latency and even more vulnerable to expired nodes. Nobody is happy with the current state
• With the planned "CritterWatch" tooling (see this google doc for more information) , we'll need ways to quickly scrape information out of Wolverine nodes with Request/Reply mechanics. We'll surely absolutely have to fall back to using existing transports in some cases but...

You know what technology is really, really good at request/reply mechanics? Good ol' fashioned HTTP.

What I'd like to propose is two things:

1. A basic messaging transport for Wolverine based on HTTP. We can use message batching, and that'll be pretty simple. Assuming the application itself is behind a cluster, you even get some level of competing consumers
2. A new kind of cheat in Wolverine so that when you call IMessageBus.InvokeAsync<T>() to do a remote request/reply, it can "see" that the message would be using HTTP and, issue a single request w/ expected reply via HTTP

Mechanics

• I think we would build this into Wolverine.HTTP the library but probably use Minimal API under the covers
• 2 HTTP routes, one for sending batched messages asynchronously, and a 2nd for doing a single request/reply message that would hopefully be suitable for especially the node to node communication and the CritterWatch scraping / command issuance

What about Security?

Dunno, something to figure out to make any of this feasible.

Jasper (Wolverine's predecessor) actually had a generic HTTP messaging transport that could send batches of messages between Wolverine applications. Cool, but it got thrown away before even Jasper went 1.0.

[Arne-B]

I like the idea of having a "simple" transport which works without additional infrastructure.HTTP plays nice with firewalls and proxys and encryption is a solved problem via HTTPS. I would suggest using websockets for live events, but offer a plain http endpoint with batch support as a fallback where WS are not feasible or not desired.

[jeremydmiller]

@Arne-B I think we'd opt for a SignalR transport (finally) if we did that. I've done custom web sockets before, but I'm not wanting to sign up for that one ever again!

[Arne-B]

@jeremydmiller fair enough, been there... Since SignalR can use different kinds of transports, and WS(S) is one of them, it might even bring more flexibility. Since there are also clients readily available for different languages , I see that as a plus for easy integration.