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.
🌐 English | 日本語 | 简体中文 | 繁體中文 | Русский | Українська | فارسی | العربية
📍 Quick Navigation
You may be looking for:
- 🌐 Official Website - Documentation, tutorials, and guides
- 🚀 Quick Start - Get up and running in 5 minutes
- 📦 Installation Options - Choose your flavor: Micro, Standard, or Full
- 📚 Getting Started Guide - Step-by-step tutorial
- 🎛️ Feature Flags - Fine-tune your build
- 📖 API Documentation - Complete API reference
- 💬 Community & Support - Get help from the community
Why Reinhardt?
Polylithic = Poly (many) + Lithic (building blocks) Unlike monolithic frameworks that force you to use everything, Reinhardt lets you compose your perfect stack from independent, well-tested components.
Reinhardt brings together the best of three worlds:
| Inspiration | What We Borrowed | What We Improved |
|---|---|---|
| 🐍 Django | Batteries-included philosophy, ORM design, admin panel | Feature flags for composable builds, Rust's type safety |
| 🎯 Django REST | Serializers, ViewSets, permissions | Compile-time validation, zero-cost abstractions |
| ⚡ FastAPI | DI system, automatic OpenAPI | Native Rust performance, no runtime overhead |
| 🗄️ SQLAlchemy | QuerySet patterns, relationship handling | Type-safe query builder, compile-time validation |
Result: A framework that's familiar to Python developers, but with Rust's performance and safety guarantees.
✨ Key Features
- Type-Safe ORM with compile-time validation (reinhardt-query)
- Powerful Serializers with automatic validation (serde + validator)
- FastAPI-Style DI with type-safe dependency injection and caching
- ViewSets for rapid CRUD API development
- Multi-Auth (JWT, Token, Session, Basic) with BaseUser/FullUser traits
- Admin Panel with auto-generated model management interface
- Management Commands for migrations, static files, and more
- GraphQL & WebSocket support for real-time applications
- Pagination, Filtering, Rate Limiting built-in
- Signals for event-driven architecture
See Available Components for complete list and Getting Started for examples.
Installation
Reinhardt is a modular framework. Choose your starting point:
Note on Crate Naming:
The main Reinhardt crate is published on crates.io as reinhardt-web, but you import it as reinhardt in your code using the package attribute.
Default: Full-Featured (Batteries Included) ⚠️ New Default
Get all features with zero configuration:
[]
# Import as 'reinhardt', published as 'reinhardt-web'
# Default enables ALL features (full bundle)
= { = "0.1.0-alpha.1", = "reinhardt-web" }
Includes: Database, Auth, REST API, Admin, GraphQL, WebSockets, Cache, i18n, Mail, Sessions, Static Files, Storage
Binary: ~50+ MB | Compile: Slower, but everything works out of the box
Then use in your code:
use *;
use ;
Option 1: Standard Setup (Balanced)
For most projects that don't need all features:
[]
= { = "0.1.0-alpha.1", = "reinhardt-web", = false, = ["standard"] }
Includes: Core, Database (PostgreSQL), REST API, Auth, Middleware, Pages (WASM Frontend with SSR)
Binary: ~20-30 MB | Compile: Medium
Option 2: Microservices (Minimal Setup)
Lightweight and fast, perfect for simple APIs:
[]
= { = "0.1.0-alpha.1", = "reinhardt-web", = false, = ["minimal"] }
Includes: HTTP, routing, DI, parameter extraction, server
Binary: ~5-10 MB | Compile: Very fast
Option 3: Build Your Custom Stack
Install only the components you need:
[]
# Core components
= "0.1.0-alpha.1"
= "0.1.0-alpha.1"
# Optional: Database
= "0.1.0-alpha.1"
# Optional: Authentication
= "0.1.0-alpha.1"
# Optional: REST API features
= "0.1.0-alpha.1"
# Optional: Admin panel
= "0.1.0-alpha.1"
# Optional: Advanced features
= "0.1.0-alpha.1"
= "0.1.0-alpha.1"
📖 For a complete list of available crates and feature flags, see the Feature Flags Guide.
Quick Start
1. Install Reinhardt Admin Tool
2. Create a New Project
# Create a RESTful API project (default)
This generates a complete project structure:
my-api/
├── Cargo.toml
├── src/
│ ├── lib.rs
│ ├── config.rs
│ ├── apps.rs
│ ├── config/
│ │ ├── settings.rs
│ │ ├── settings/
│ │ │ ├── base.rs
│ │ │ ├── local.rs
│ │ │ ├── staging.rs
│ │ │ └── production.rs
│ │ ├── urls.rs
│ │ └── apps.rs
│ └── bin/
│ └── manage.rs
└── README.md
Alternative: Create a reinhardt-pages Project (WASM + SSR)
For a modern WASM-based frontend with SSR:
# Create a pages project
# Install WASM build tools (first time only)
# Build WASM and start development server
# Visit http://127.0.0.1:8000/
3. Run the Development Server
# Using the manage command
# Server will start at http://127.0.0.1:8000
Auto-Reload Support:
For automatic reloading on code changes (requires bacon):
# Install bacon
# Run with auto-reload
# Or use cargo make
# For tests
4. Create Your First App
# Create a RESTful API app (default)
# Or explicitly specify type
# Create a Pages app (WASM + SSR)
This creates an app structure:
users/
├── lib.rs
├── models.rs
├── models/
├── views.rs
├── views/
├── serializers.rs
├── serializers/
├── admin.rs
├── urls.rs
└── tests.rs
5. Register Routes
Edit your app's urls.rs:
// users/urls.rs
use ServerRouter;
use views;
Include in src/config/urls.rs:
// src/config/urls.rs
use *;
use routes;
The #[routes] attribute macro automatically registers this function with the
framework for discovery via the inventory crate.
Note: The reinhardt::prelude includes commonly used types. Key exports include:
Always Available:
- Core routing and views:
Router,DefaultRouter,ServerRouter,View,ListView,DetailView - ViewSets:
ViewSet,ModelViewSet,ReadOnlyModelViewSet - HTTP:
StatusCode
Feature-Dependent:
corefeature:Request,Response,Handler,Middleware, Signals (post_save,pre_save, etc.)databasefeature:Model,DatabaseConnection,F,Q,Transaction,atomic, Database functions (Concat,Upper,Lower,Now,CurrentDate), Window functions (Window,RowNumber,Rank,DenseRank), Constraints (UniqueConstraint,CheckConstraint,ForeignKeyConstraint)authfeature:User,UserManager,GroupManager,Permission,ObjectPermissionminimal,standard, ordifeatures:Body,Cookie,Header,Json,Path,Queryrestfeature: Serializers, Parsers, Pagination, Throttling, Versioningadminfeature: Admin panel componentscachefeature:Cache,InMemoryCachesessionsfeature:Session,AuthenticationMiddleware
For a complete list, see Feature Flags Guide.
For a complete step-by-step guide, see Getting Started.
🎓 Learn by Example
With Database
Configure database in settings/base.toml:
= true
= "your-secret-key-for-development"
[]
= "postgresql"
= "localhost"
= 5432
= "mydb"
= "postgres"
= "postgres"
Settings are automatically loaded in src/config/settings.rs:
// src/config/settings.rs
use SettingsBuilder;
use Profile;
use ;
use Settings;
use env;
use PathBuf;
use FromStr;
Environment Variable Sources:
Reinhardt provides two types of environment variable sources with different priorities:
-
EnvSource(priority: 100) - High priority environment variables that override TOML files.add_source -
LowPriorityEnvSource(priority: 40) - Low priority environment variables that fall back to TOML files.add_source
Priority Order:
- Using
EnvSource: Environment Variables >{profile}.toml>base.toml> Defaults - Using
LowPriorityEnvSource(shown above):{profile}.toml>base.toml> Environment Variables > Defaults
Choose EnvSource when environment variables should always take precedence (e.g., production deployments).
Choose LowPriorityEnvSource when TOML files should be the primary configuration source (e.g., development).
See Settings Documentation for more details.
Using the Built-in DefaultUser:
Reinhardt provides a ready-to-use DefaultUser implementation (requires argon2-hasher feature):
// users/models.rs
use *;
use DefaultUser;
// Re-export DefaultUser as User for your app
pub type User = DefaultUser;
// DefaultUser includes:
// - id: Uuid (primary key)
// - username: String
// - email: String
// - password_hash: Option<String>
// - first_name: String
// - last_name: String
// - is_active: bool
// - is_staff: bool
// - is_superuser: bool
// - last_login: Option<DateTime<Utc>>
// - date_joined: DateTime<Utc>
// DefaultUser implements:
// - BaseUser trait (authentication methods)
// - FullUser trait (full user information)
// - PermissionsMixin trait (permission management)
// - Model trait (database operations)
Defining Custom User Models:
If you need custom fields, define your own model:
// users/models.rs
use *;
use ;
use ;
Model Attribute Macro:
The #[model(...)] attribute automatically generates:
- Implementation of the
Modeltrait (includes#[derive(Model)]functionality) - Type-safe field accessors:
User::field_email(),User::field_username(), etc. - Global model registry registration
- Support for composite primary keys
Note: When using #[model(...)], you do NOT need to add #[derive(Model)] separately,
as it is automatically applied by the #[model(...)] attribute.
Field Attributes:
#[field(primary_key = true)]- Mark as primary key#[field(max_length = 255)]- Set maximum length for string fields#[field(default = value)]- Set default value#[field(auto_now_add = true)]- Auto-populate timestamp on creation#[field(auto_now = true)]- Auto-update timestamp on save#[field(null = true)]- Allow NULL values#[field(unique = true)]- Enforce uniqueness constraint
For a complete list of field attributes, see the Field Attributes Guide.
The generated field accessors enable type-safe field references in queries:
// Generated by #[model(...)] for DefaultUser
Advanced Query Examples:
use *;
use DefaultUser;
// Django-style F/Q object queries with type-safe field references
async
// Transaction support
async
Note: Reinhardt uses reinhardt-query for SQL operations. The #[derive(Model)] macro automatically generates Model trait implementations, type-safe field accessors, and global model registry registration.
Register in src/config/apps.rs:
// src/config/apps.rs
use installed_apps;
// The installed_apps! macro generates:
// - An enum InstalledApp with variants for each app
// - Implementation of conversion traits (From, Into, Display)
// - A registry for app configuration and discovery
//
// Note: Unlike Django's INSTALLED_APPS, this macro is for user apps only.
// Built-in framework features (auth, sessions, admin, etc.) are enabled via
// Cargo feature flags, not through installed_apps!.
//
// Example:
// [dependencies]
// reinhardt = { version = "0.1", features = ["auth", "sessions", "admin"] }
//
// This enables:
// - Automatic app discovery for migrations, admin panel, etc.
// - Type-safe app references throughout your code
// - Centralized app configuration
installed_apps!
With Authentication
Reinhardt provides Django-style user models with BaseUser and FullUser traits, along with comprehensive user management through UserManager.
Note: Reinhardt includes a built-in DefaultUser implementation. You can use it directly or define your own user model as shown below.
User Management Example:
use *;
// Create and manage users with UserManager
async
Use the built-in DefaultUser in users/models.rs:
// users/models.rs
use DefaultUser;
// Re-export DefaultUser as your User type
pub type User = DefaultUser;
// DefaultUser already implements:
// - BaseUser trait (authentication methods)
// - FullUser trait (username, email, first_name, last_name, etc.)
// - PermissionsMixin trait (permission management)
// - Model trait (database operations)
For Custom User Models:
If you need additional fields beyond DefaultUser, define your own:
// users/models.rs
use ;
use Uuid;
use ;
use ;
Use JWT authentication in your app's views/profile.rs:
// users/views/profile.rs
use ;
use ;
use DatabaseConnection;
use Arc;
use crateUser;
pub async
Endpoint Definition
Reinhardt uses HTTP method decorators to define endpoints:
HTTP Method Decorators
Use #[get], #[post], #[put], #[delete] to define routes:
use ;
use json;
pub async
pub async
Features:
- Compile-time path validation
- Concise syntax
- Automatic HTTP method binding
- Support for dependency injection via
#[inject]
Using Dependency Injection
Combine HTTP method decorators with #[inject] for automatic dependency injection:
use ;
use DatabaseConnection;
use Arc;
pub async
Dependency Injection Features:
- Automatic dependency injection via
#[inject]attribute - Cache control with
#[inject(cache = false)] - FastAPI-inspired dependency injection system
- Works seamlessly with HTTP method decorators
Result Type:
All view functions use ViewResult<T> as the return type:
use ViewResult; // Pre-defined result type
With Parameter Extraction
In your app's views/user.rs:
// users/views/user.rs
use ;
use DatabaseConnection;
use crateUser;
use Arc;
pub async
Register route with path parameter in urls.rs:
// users/urls.rs
use ServerRouter;
use views;
With Serializers and Validation
In your app's serializers/user.rs:
// users/serializers/user.rs
use ;
use Validate;
In your app's views/user.rs:
// users/views/user.rs
use ;
use DatabaseConnection;
use crateUser;
use crate;
use Validate;
use Arc;
pub async
Available Components
Reinhardt offers modular components you can mix and match:
| Component | Crate Name | Features |
|---|---|---|
| Core | ||
| Core Types | reinhardt-core |
Core traits, types, macros (Model, endpoint) |
| HTTP & Routing | reinhardt-http |
Request/Response, HTTP handling |
| URL Routing | reinhardt-urls |
Function-based and class-based routes |
| Server | reinhardt-server |
HTTP server implementation |
| Middleware | reinhardt-dispatch |
Middleware chain, signal dispatch |
| Configuration | reinhardt-conf |
Settings management, environment loading |
| Commands | reinhardt-commands |
Management CLI tools (startproject, etc.) |
| Shortcuts | reinhardt-shortcuts |
Common utility functions |
| Database | ||
| ORM | reinhardt-db |
reinhardt-query integration |
| Authentication | ||
| Auth | reinhardt-auth |
JWT, Token, Session, Basic auth, User models |
| REST API | ||
| Serializers | reinhardt-rest |
serde/validator integration, ViewSets |
| Forms | ||
| Forms | reinhardt-forms |
Form handling and validation |
| Advanced | ||
| Admin Panel | reinhardt-admin |
Django-style admin interface |
| Plugin System | reinhardt-dentdelion |
Static & WASM plugin support, CLI management |
| Background Tasks | reinhardt-tasks |
Task queues (Redis, RabbitMQ, SQLite) |
| GraphQL | reinhardt-graphql |
Schema generation, subscriptions |
| WebSockets | reinhardt-websockets |
Real-time communication |
| i18n | reinhardt-i18n |
Multi-language support |
| Testing | ||
| Test Utilities | reinhardt-test |
Testing helpers, fixtures, TestContainers |
For detailed feature flags within each crate, see the Feature Flags Guide.
Documentation
- 📚 Getting Started Guide - Step-by-step tutorial for beginners
- 🎛️ Feature Flags Guide - Optimize your build with granular feature control
- 📖 API Reference (Coming soon)
- 📝 Tutorials - Learn by building real applications
For AI Assistants: See CLAUDE.md for project-specific coding standards, testing guidelines, and development conventions.
💬 Getting Help
Reinhardt is a community-driven project. Here's where you can get help:
- 💬 Discord: Join our Discord server for real-time chat (coming soon)
- 💭 GitHub Discussions: Ask questions and share ideas
- 🐛 Issues: Report bugs
- 📖 Documentation: Read the guides
Before asking, please check:
- ✅ Getting Started Guide
- ✅ Examples
- ✅ Existing GitHub Issues and Discussions
🤝 Contributing
We love contributions! Please read our Contributing Guide to get started.
Quick links:
⭐ Star History
License
This project is licensed under the BSD 3-Clause License.
Third-Party Attribution
This project is inspired by:
- Django (BSD 3-Clause License)
- Django REST Framework (BSD 3-Clause License)
- FastAPI (MIT License)
- SQLAlchemy (MIT License)
See THIRD-PARTY-NOTICES for full attribution.
Note: This project is not affiliated with or endorsed by the Django Software Foundation, Encode OSS Ltd., Sebastián Ramírez (FastAPI author), or Michael Bayer (SQLAlchemy author).