Most backend projects do not become complicated all at once.
They start with a route or two. Then come configuration, authentication, storage, background work, health checks, logging, metrics, migrations, and deployment concerns.
Each addition is reasonable on its own, but over time the boundaries between them become unclear.
Application code starts knowing too much about storage. Background jobs depend on HTTP details. Health checks are implemented differently from service to service. Configuration is spread across constructors, environment variables, and framework-specific layers.
I built Arqen to give those concerns a clearer home.
Arqen is a Rust-first backend toolkit for HTTP services, agents, automation, jobs, health checks, modules, and storage adapters.
It is not intended to hide the system from you. The goal is to make important boundaries explicit without forcing every application to rebuild the same foundation.
The problem with backend glue
A backend often has several responsibilities that are related, but not identical:
- Accepting and validating HTTP requests
- Authenticating users or services
- Calling storage
- Running background work
- Reporting health and metrics
- Emitting useful logs
- Exposing capabilities to tools or agents
- Moving between local and production environments
The difficult part is not necessarily implementing each feature.
The difficult part is keeping those features from becoming tightly coupled.
A storage implementation should not dictate how an application defines its routes. A background job should not need to know whether data came from an in-memory store, a local embedded engine, or a remote service.
A health endpoint should be able to report dependency state without taking ownership of the entire application lifecycle.
That is where Arqen’s boundaries begin.
A backend foundation, not a giant runtime
Arqen provides a structure for composing backend capabilities while keeping the application in control.
The core is built around Rust, Tokio, Axum, Tower, tracing, and explicit feature flags. HTTP servers, clients, logging, jobs, storage adapters, migrations, and CLI support can be enabled according to the needs of a project.
The easiest way to add Arqen to a Rust project is through Cargo:
cargo add arqen
This adds Arqen from crates.io without tying the article to a specific release number.
For projects that need the CLI generator, a new application can be created with:
cargo run -p arqen --features cli --bin arqen -- new hello-api
cd hello-api
cargo run
The intention is to make the first step straightforward without deciding the entire architecture on behalf of the application.
Keeping storage behind a contract
One of the most important design decisions in Arqen is the ThingdBackend boundary.
Applications should be able to depend on a storage contract instead of directly coupling their business logic to one storage implementation.
That makes it possible to use different modes for different situations:
- Memory storage for tests and local development
- HTTP Thingd for separately deployed services
- Native Thingd for local tooling and embedded workflows
- Future hosted or cloud-backed paths where the contract remains useful
The application-facing boundary stays the same while the deployment choice changes.
This is useful when local development and production have different requirements. A local tool may benefit from an embedded engine, while a production application may be better served by a separately managed HTTP service.
Arqen does not treat those modes as interchangeable without qualification. Each mode has different operational properties, compatibility requirements, and failure modes.
For production applications, the HTTP adapter is the preferred boundary. Native storage is useful when the application specifically needs embedded access, local diagnostics, or migration tooling.
Durable work belongs in the backend foundation
Background work tends to grow quietly.
A first job may just process a request later. Eventually it needs retries, leases, idempotency, failure tracking, dead letters, and a way to avoid multiple workers processing the same logical task.
Arqen treats durable jobs as a backend concern rather than leaving every application to invent its own queue lifecycle.
The job system is designed around explicit behavior:
- A job can be claimed by a worker
- Leases prevent abandoned work from remaining active forever
- Retries can be tracked
- Failures can be moved to dead-letter handling
- Work can be reconciled after a restart
- Scheduling can support interval, one-time, and cron-like execution
- Run identities can be deterministic and observable
This does not remove the need for application-specific decisions. A payment system, content pipeline, and email sender will all have different retry policies.
But the underlying lifecycle should not need to be reconstructed from scratch each time.
Agent-ready does not mean AI-only
Arqen uses the term “agent-ready,” but that does not mean every application needs to be an AI product.
For Arqen, agent-ready means that capabilities can be:
- Discovered
- Typed
- Permission-aware
- Validated
- Audited
- Exposed through machine-readable contracts
Those properties are useful for agents, but they are also useful for ordinary clients, internal tools, automation, and operational systems.
A typed tool with a clear input schema is easier for an agent to call, but it is also easier for a human developer to understand.
A manifest that describes available capabilities is helpful for automation, but it is also useful for documentation and testing.
The goal is not to add AI terminology to a conventional backend. The goal is to make backend capabilities more explicit and easier to integrate.
Explicit features instead of one large bundle
Arqen uses feature flags to keep optional capabilities visible.
An application can use the core HTTP foundation without pulling in native Thingd support. The CLI, HTTP client, logging, migration, maintenance, and connector features can be enabled when they are actually needed.
That approach adds some configuration work, but it also makes dependencies and deployment assumptions easier to inspect.
A project using native storage should be able to say so clearly. A project using an HTTP-only production boundary should not accidentally compile in an embedded database path just because a convenience feature enabled it.
The feature list becomes part of the architecture rather than an implementation detail hidden inside the dependency graph.
What Arqen provides
Arqen includes building blocks for:
- HTTP services and clients
- Authentication and request context
- Typed tools and machine-readable manifests
- Application module composition
- Memory and Thingd-backed storage adapters
- Durable jobs and scheduling
- Health checks and operational status
- Structured logging and request correlation
- Metrics and observability
- Configuration and validation
- CLI-based project generation
- Migration and maintenance workflows
These capabilities are designed to work together, but they do not require every application to use all of them.
That balance matters. A backend toolkit should provide a coherent path without making every project inherit the complexity of the most advanced project built with it.
The tradeoffs
Arqen is deliberately opinionated in a few places.
It prefers explicit boundaries over convenience coupling. It prefers feature-gated integrations over a single universal runtime. It treats HTTP and native storage as different operational modes.
It gives jobs, health, logging, and configuration a defined place in the application structure.
Those choices can make the architecture slightly more visible up front.
That is intentional.
When a system is small, almost any structure can appear to work. As the system grows, the cost of unclear ownership becomes more noticeable.
Arqen is an attempt to make that ownership clear earlier.
Where the project is today
Arqen is early-stage and actively maturing.
It has useful building blocks and a growing set of examples and documentation, but it should not be treated as automatically production-ready for every workload.
Applications still need their own security review, durability testing, recovery testing, dependency compatibility checks, and operational ownership.
The toolkit can provide a foundation. It cannot make application-specific risk disappear.
That distinction is important because backend infrastructure is easy to oversell. A clean abstraction is valuable, but it is not a substitute for understanding how a particular system behaves under failure.
Explore Arqen
If the problems Arqen is trying to solve sound familiar, the project is available in a few places:
Arqen is an ongoing attempt to make backend infrastructure easier to compose, easier to inspect, and easier to move between environments.
The most useful result would not be that every project uses it.
It would be that the boundaries it explores help make backend systems a little easier to reason about.
Top comments (0)