One Backend Pattern for HTTP, CLI, and Workflows

Recommended reading: The request context problem and Backend composables — the context model and composable pattern this article builds on. Most backend frameworks are HTTP frameworks that pretend otherwise. They might support WebSockets as a plugin. CLI tooling lives in a separate package. Scheduled jobs get wired through a queue library with its own conventions. And if the same business action needs to run from an API endpoint and a CLI command and a scheduled job, you write three wrappers around the same logic. Not because the logic is different. Because the framework assumed HTTP from the start. That is the problem I hit after building the composables layer from the previous article . The composables worked great inside HTTP handlers — but the moment I needed the same action from a CLI command or a workflow step, the HTTP-shaped context leaked everywhere. The duplication nobody talks about A pattern most teams know but rarely name. You build an API endpoint that generates a report: