Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
A plugin-based Rust framework for backend HTTP services. The architecture — lifecycle phases, plugin composition, and route groups with stacked middleware — is borrowed from GoDaddy's Gasket, which targets full-stack JavaScript apps and pairs a Node backend with a React frontend. Rusty Gasket adapts the same lifecycle-driven plugin model for Rust backends only; the frontend half of the analogy is out of scope.
Build production HTTP APIs with a lifecycle-driven plugin system, pluggable middleware pipeline, and clean separation between open-source core and organization-specific overlays.
Rusty Gasket is designed for teams that want Rust's deployment, runtime, and safety benefits without requiring every API owner to become a Rust specialist first. The primary use case is agentic code generation: a software engineer describes or evolves an API, an agent generates the Rust implementation, and the engineer still needs to read, review, debug, and maintain that code in production.
That means generated application code must be approachable to engineers who are experienced in backend systems but new to Rust. The framework uses modern Rust internally, but keeps boxing, object-safety adapters, lifetime-heavy signatures, and ownership-heavy syntax behind named framework types wherever practical.
Readability is part of the framework contract. Public APIs, framework handles, and non-obvious internal adapters should be documented in domain language so developers can understand the code without first decoding Rust's lower-level type machinery.
Design Priorities
- Readable generated APIs -- route handlers, plugins, auth backends, and configuration should look like ordinary service code.
- Modern Rust under the hood -- advanced Rust is allowed inside the framework when it buys safety, correctness, or performance, but it should be wrapped in named concepts.
- Production ownership by non-Rust specialists -- comments, rustdoc, examples, and type names should help backend engineers understand generated code well enough to operate it.
- Expert-defensible tradeoffs -- novice ergonomics matter most, but not by committing to obsolete patterns, unsound shortcuts, or dead-end abstractions.
Quick Start
use ;
use *;
use ;
// A plugin is the unit of API composition.
// It can contribute routes, middleware, config changes, health checks,
// and startup/shutdown work.
;
// Request inputs are ordinary typed structs.
// Serde fills this from query parameters: /v1/add?a=2&b=3
// Response bodies are ordinary typed structs too.
// Serde turns this into JSON for the HTTP response.
// A second request type for a string-processing endpoint.
// Example: /v1/upper?text=hello
// Public endpoints can return small status payloads without requiring auth.
// Handlers are just async functions.
// No boxed futures, no lifetime annotations, no framework-specific ceremony.
async
async
async
async
Swagger UI: The
openapifeature is enabled by default for API projects. AddOpenApiPluginto serve interactive API docs at/swagger-ui/. Minimal consumers can opt out withdefault-features = false.
Crates
| Crate | Description |
|---|---|
rusty-gasket |
The framework: plugins, config, error handling, server, health, observability, rate limiting, OpenAPI, and caching — plus optional batteries (auth, AWS, SQL via db, DynamoDB, testing) behind feature flags. |
rusty-gasket-macros |
#[derive(ApiError)] proc macro for ergonomic error types. |
Application code depends only on rusty-gasket; optional functionality is turned on with feature flags (see below).
Documentation
| Guide | Description |
|---|---|
| Getting Started | Installation, first project, first route |
| API Ergonomics | Novice-readable handlers, policy guards, context, generators, OpenAPI |
| Architecture | Plugin lifecycle, middleware pipeline, route groups |
| Plugin Guide | Writing plugins: ordering, routes, layers, health |
| Authentication | JWT, API keys, auth chain, extractors, policies |
| Database | SQLx, transactions, request ID correlation |
| Caching | ObjectCache, response caching, Redis, Memcached |
| Configuration | Config files, env vars, secrets, environments |
| Error Handling | ApiError trait, derive macro, structured errors |
| Testing | TestApp, mocks, containers, benchmarks |
| Observability | Tracing, request IDs, OpenTelemetry |
| Middleware | Pipeline slots, custom middleware, route groups |
| Changelog | Release history |
| Contributing | Development setup, testing, PR process |
Feature Flags
rusty-gasket
| Feature | Default | Description |
|---|---|---|
json-log |
Yes | JSON structured logging |
health |
Yes | Health check endpoints |
rate-limit |
Yes | Governor rate limiting |
openapi |
Yes | utoipa + Swagger UI at /swagger-ui/; disable with default-features = false |
cache |
Yes | ObjectCache, response caching, and in-process Moka backend |
cache-redis |
No | Redis/Valkey object-cache backend |
cache-memcached |
No | Memcached object-cache backend |
otlp |
No | OpenTelemetry OTLP span + metric export |
auth |
No | JWT auth backends, auth chain, middleware, and policy extractors |
auth-api-key |
No | API-key auth backend in addition to JWT auth |
aws |
No | AWS integration helpers |
db |
No | Default SQL database integration (db-postgres) |
db-postgres |
No | PostgreSQL SQLx integration, transaction middleware, DbTx extractor |
db-mysql |
No | MySQL SQLx integration, transaction middleware, DbTx extractor |
dynamodb |
No | DynamoDB lifecycle plugin and extractor |
testing |
No | TestApp, TestResponse, and in-process auth test helpers |
Development
Creating a New Project
License
Licensed under the Apache License, Version 2.0. See LICENSE.