Keeping a Rust Web Application Coherent with Bundles

A web application becomes harder to understand long before it becomes large. A route is added in one place, a background task in another, and the operational details needed to run both are left for someone to discover later. Each choice is defensible on its own. The shape they make together is what becomes tiring.

Vyuh starts from a small idea: a feature is more than an HTTP handler. It can include routes, OpenAPI information, durable tasks, channels, scheduled emitters, commands, services, templates, and assets. A bundle gives those pieces one named home.

The pressure is not routing

Most Rust web frameworks make it pleasant to write a handler. The more interesting question appears a few months later: where should the task that continues the work live? How does an operator inspect it? Which validation and authentication rules belong at the edge? What does another developer need to register before the feature exists?

There is no clever answer that removes this work. But a bundle makes the boundary visible. The application can be assembled from feature-shaped units rather than a long, gradually mysterious list of registrations.

That makes the code read closer to the way the product is discussed: this part handles accounts; this part handles imports; this part owns notifications. It also leaves room for a feature to grow without forcing every concern into one oversized route module.

Explicit paths are useful paths

Vyuh leans toward typed data and explicit transitions. A value passed into a handler, task, or command is not just an unstructured request payload travelling through the system. It has a type and a boundary. Validation, authorization, retry behaviour, and execution context remain deliberate choices.

This is not a promise that an application will stay simple. Real applications accumulate exceptions, integrations, and history. The aim is more modest: when the complexity arrives, it should have somewhere intelligible to go.

Vyuh is still pre-1.0, so its public API is intentionally allowed to change. That is a useful time to be honest about what is being explored: not a new way to hide application structure, but a way to keep it legible while routes and background work begin to meet.