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.
Feature | Roadster | Loco |
---|---|---|
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 | ✅ | ❌ |
✅ | ✅ | |
↳ 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 | ❌* | ✅ |