Currently this emits data only to standard out, but it will likely need to learn
how to drop this payload directly onto the eventbus in the near future
Now that I have something simple and functioning, this no longer needs to be
in the auctioneer
The fun work begins now, supporting custom messages known only to the auctioneer
for its needs, but passing those through EventBusClient
I originally tossed this approach since I believed that the awc +
actix-web-actors approach was unnecessarily complex. After experimenting a bit
with tungstenite, I believe that converting its high-level API into something
that I could work with in an asynchronous manner would require too much poking
around with tokio to be worth the effort.
I suppose I'll have to make do with the somewhat mid-level abstraction that
actix-web-actors provides me.
There's some refactoring I need to do in the server/eventbus module before
continuing, but this contains the initial cut of code necessary to create a new
inbox when a client connects that will map to that client name
While connecting the auctioneer, I noticed that the messages need to have their
channel name associated with the message body, otherwise the client doesn't know
what message goes where!
I think I am going to have to abandon this approach for a couple of different
reasons:
* Bastion does not yet support dynamic supervision
<https://github.com/bastion-rs/bastion/issues/9>
This means that any workers which might handle websocket or other connections
cannot possibly scale because the server would need to start with a fixed number
of children under supervision. Contrary to what we have with actix-web where
we use an actor per connection.
* Tide/tungstenite do not yet integrate. It seems that actix-web and _maybe_
gotham are the only two web frameworks which properly upgrade HTTP
connections to websockets without requiring two fundamentally different servers
to be running.
This makes the auctioneer resilient to total failures on connecting to the
eventbus, but unfortunately spins in a tight loop if the eventbus is offline.
This is just to checkpoint this work. I think I'll be refactoring the eventbus
quite a bit to make sure that each eventbus client doesn't need to do too much
custom actix work
shoreman is a shell-only implementation of the Ruby "foreman" gem, which is
helpful for running multiple processes locally for development.
https://github.com/chrismytton/shoreman