Roadster vs. Loco

Loco and Roadster serve similar purposes -- they both aim to reduce the amount of configuring, wiring, and other boilerplate code required to build a backend or full-stack web app in Rust. There are some notable differences, however, both in mission statement and the list of supported features. This section will give a summary of both the similarities and differences between Loco and Roadster.

Feature breakdown

Below is a detailed breakdown of the features included in Roadster and Loco. Note that because both frameworks are based on Axum and Tokio, there's not a lot technically preventing either framework from implementing features they're missing compared to the other. Features that Roadster would like to add in the near future are marked with '*'. Other missing features are not planned but we'd be open to adding if there was enough interest in them.

Last updated in Feb 2025.

FeatureRoadsterLoco
Separate cargo CLI to help with generating code and other tasks
Custom CLI commands
HTTP APIs via Axum
 ↳ Default "ping" and "health" HTTP routes
  ↳ Default routes can be disabled via config
 ↳ Default middleware configured with sensible defaults
  ↳ Middleware can be customized via config files
  ↳ Middleware execution order can be customized via config files
OpenAPI support
 ↳ built-in via Aide
 ↳ 3rd party integration, e.g. Utoipa
 ↳ OpenAPI docs explorer http route provided by default
GRPC API with tonic
Channels (websockets and/or http long-polling)
Support for arbitrary long-running services
Health checks
 ↳ Run in "health" API route
 ↳ Run on app startup
 ↳ Run via CLI
 ↳ Consumer can provide custom checks
Custom app context / Axum state using Axum's FromRef
SQL DB
 ↳ via Diesel
 ↳ via SeaORM
  ↳ SeaORM migrations for common DB schemas
(in lib)

(in starters)
Sample JWT Axum extractor
 ↳ Multiple JWT standards supported
Email
 ↳ via SMTP
 ↳ via Sendgrid's Mail Send API
Storage abstraction❌*
Cache abstraction❌*
Background jobs
 ↳ via Sidekiq
 ↳ via Postgres
 ↳ via in-process threading with Tokio
Periodic jobs
 ↳ via Sidekiq
 ↳ via custom scheduler
Configuration via config files
 ↳ Toml
 ↳ Yaml
Config files can be split into multiple files
Config values can be overridden via env vars
Tracing via the tracing crate
 ↳ Built-in support for trace/metric exporting via OpenTelemetry
insta snapshot utilities
Data seeding and cleanup hooks for tests❌*
(⚠️ makes tests non-parallelizable)
Mock DB support for tests
 ↳ via Temporary Test DBs
 ↳ via SeaORM's MockDatabase
 ↳ via TestContainers
Allows following any design pattern
(MVC only)
Lifecycle hooks
 ↳ Customizable shutdown signal
HTML rendering
 ↳ Built-in
 ↳ via 3rd party integration, e.g. Leptos⚠️ (Partial support)
Deployment config generation
Starter templates❌*