moonasgiASGI 3.0

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

0 / 0
scope received sent application

Reading the lanes

Each card is one event. The label on the left is the lane it travelled in:

LaneWhat it isWho writes it
scopeThe connection, built once, before anything is saidthe server
inAn event the application pulled with receivethe server, read by the application
appA decision inside the application, not an eventthe application
outAn event the application pushed with sendthe application, written by the server
mwA middleware layer the request entered or leftthe 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.

src/examples/18-trace/main.mbt
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.

Regenerate

moon run src/examples/18-trace > docs/assets/traces.json