What does “live”
really mean?

A screen can look right
and tell the wrong story.

Streaming data often looks simple in a demo: subscribe, receive an update, render it. The difficult part is what happens around that happy path—a restart, an interrupted connection, a slow browser, or a change in who is allowed to see the data.

I wanted a developer experience that made those conditions visible and manageable, while still getting a useful page running quickly. A connection indicator alone doesn’t answer the question that matters to the person using the page: can I rely on what I’m seeing?

Make the guarantees
part of the interface.

Browsers subscribe to named state channels instead of raw Kafka topics. A view begins with an authoritative snapshot and then receives ordered full-state updates. The client reports whether that view is live, stale, synchronizing, or needs to resync, so an application can display the truth.

Application-owned handlers control authentication, authorization, mapping, and snapshots. Those choices belong with the application that understands its users and its data. The CLI, local workbench, and browser SDK turn the architecture into a workflow a developer can actually follow.

The aim is a useful boundary: the application defines what the information means and who can see it; the delivery system makes the state of that information explicit.

A tool, put to work.

StreamOtter is published as a release candidate on npm with a CLI, gateway, local workbench, and browser client. The repository includes getting-started guides, a reference example, implementation status, and verification results.

Lontra Creek puts it in a different setting: a separate web application that consumes the published package through a real Kafka pipeline. Its simulated watershed is fictional; the delivery system is real. It gives the library’s promises a place to be inspected as application behavior.

The public hosted demonstration is still in development. For now, the source and documentation are the places to inspect the implementation.

Useful now. Still evolving.

The npm release is a candidate, and the API may change before version 0.1.0. The package and repository provide the current implementation details. That distinction matters: this is a body of working software with an explicit release state, and there is still work ahead.

What keeps me interested is the original question. When a system can say what it knows—and when it has stopped knowing—the people using it have a better basis for their next decision.