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.