Showcase
One request, event by event
A server and an application say four things to each other, or a dozen. Here they are in the order they happen, for nine shapes of traffic, recorded from real runs of this library.
Play a request
Loading
Reading the lanes
Each card is one event. The label on the left is the lane it travelled in:
| Lane | What it is | Who writes it |
|---|---|---|
scope | The connection, built once, before anything is said | the server |
in | An event the application pulled with receive | the server, read by the application |
app | A decision inside the application, not an event | the application |
out | An event the application pushed with send | the application, written by the server |
mw | A middleware layer the request entered or left | the stack |
Nothing in the middle lane crosses the seam. It is there to show where the application was when the events around it happened, which is the part a protocol trace usually hides.
How it was recorded
src/examples/18-trace builds each scenario the way an application would, then drives it with a receive and a send that write down what passes through them. The timeline on this page is that transcript, nothing else.
fn Driver::receive(self : Driver) -> @spec.Receive {
async fn() {
let event = self.inbound[self.at]
self.at = self.at + 1
self.rec.add("in", event_title(event), event_body(event), "the application pulls it in")
event
}
}
fn Driver::send(self : Driver) -> @spec.Send {
async fn(event) {
self.out.push(event)
self.rec.add("out", event_title(event), event_body(event), "the application pushes it out")
}
}
Because the recording happens at the seam itself, the order is the application's own: a streamed body shows three pulls and one push, a middleware stack shows the request entering every layer and the answer leaving through them in reverse.
moon run src/examples/18-trace > docs/assets/traces.json