GlideAPI
A Rust web framework I published to crates.io: FastAPI-style ergonomics with Actix-level performance.
Rust web frameworks are fast but verbose: routing, validation, dependency wiring and API docs all ask for boilerplate. Teams coming from FastAPI or Express expect to declare a route and get docs, typed inputs and sane defaults for free.
Designed and published GlideAPI, an ergonomic web framework on Tokio and hyper. Routes are declared with #[get]/#[post]/#[put]/#[delete] attribute macros and auto-registered with a single .mount_routes() call. Typed State<T> injection replaces Arc<Mutex> noise, a unified Result<T> replaces Box<dyn Error>, and middleware is a composable async fn(req, next) chain.
A Tokio + hyper core with a procedural-macro crate (glideapi_macros) that registers handlers at compile time via linkme. Every app gets an auto-generated OpenAPI 3.0 document at /_openapi.json and Swagger UI at /_docs, an x-request-id on every response, a default 1 MB body limit and 30 s request timeout, graceful shutdown on Ctrl+C / SIGTERM, and structured logging through tracing.
Route registration happens at compile time (linkme distributed slices), so there is no runtime routing table to build by hand and no forgotten registration. Request validation and typed parameters are enforced by the macros before a handler runs.
Rust for predictable latency and memory safety; Tokio and hyper for the async runtime and HTTP core; attribute macros to give a Python/TypeScript-style developer experience without giving up compile-time guarantees.
Bringing decorator-style routing, automatic OpenAPI and Swagger UI, and typed dependency injection to Rust in one crate, with zero boilerplate to start a service.
A batteries-included Rust framework for teams who want FastAPI-style speed of development on a compiled, memory-safe stack.