[ANN] I built a Django/DRF-inspired Rust framework and want feedback on the API design before 0.1

⚓ Rust    📅 2026-03-26    👤 surdeus    👁️ 4      

surdeus

Hi all,

I’ve been working on Reinhardt (reinhardt-web on crates.io, imported as reinhardt), a Rust web framework inspired by Django / DRF.

The motivation was simple: whenever I started a new Rust web project, I kept rebuilding the same stack from separate crates: HTTP/routing, ORM, migrations, dependency injection, auth, background jobs, and API scaffolding. Reinhardt is my attempt to provide those pieces as one integrated system while still keeping them composable.

Current state:

  • release candidate: v0.1.0-rc.14
  • open source: BSD-3-Clause
  • not production-ready yet

What currently works best is the core path:

  • HTTP/routing
  • DI
  • ORM/query building
  • auto-migrations from #[model(...)]
  • REST-style APIs
  • project bootstrapping via CLI

A few parts that may be interesting from an API-design perspective:

  • Composable feature flags: minimal for HTTP/routing/DI, standard for the main web stack, or individual features if you want to assemble a narrower setup.
  • Model-driven migrations: models are declared in Rust and migrations are generated from that.
  • Integrated Pages: there is a WASM+SSR “Pages” system for keeping frontend and backend in one Rust project, but this area is still early and I would not compare it to mature standalone frontend frameworks yet.

To be transparent: I used AI assistance heavily for some boilerplate-heavy implementation work, but the API/design decisions, review, crate structure, and release decisions were mine.

Areas that are still underdeveloped:

  • admin UI
  • GraphQL
  • gRPC
  • Pages / broader WASM-side ergonomics
  • deployment/scaffolding niceties

So I’m not posting this as “ready for production”, but as “I think the shape is finally visible, and I’d like feedback before stabilizing it”.

A few questions I’d especially appreciate feedback on:

  1. Does the integrated / batteries-included approach seem useful in Rust, or do you strongly prefer assembling your own stack?
  2. For model-driven migrations, what level of explicit control would you want around destructive changes such as column drops or renames?
  3. If you skim the API, what feels like the biggest design smell or missing piece?
  4. If you were to try this on a side project, what would you need to see first?

Quick start:

reinhardt = { version = "0.1.0-rc.14", package = "reinhardt-web" }

cargo install --locked --version 0.1.0-rc.14 reinhardt-admin-cli
reinhardt-admin startproject my-api
cd my-api
cargo run --bin manage runserver

Links:

If there’s interest, I can follow up with a separate reply containing a few focused code examples for Pages, model definitions, DI, and API View.

2 posts - 1 participant

Read full topic

🏷️ Rust_feed