Axum Rust Web Server Configuration
Configure Aider for pair programming on production-ready Rust web servers built with Axum 0.7, PostgreSQL, and modern async patterns.
What This Does
This skill configures Aider to understand and work effectively with modular Axum web server architectures. It enforces best practices for safety, testing, database operations, and code quality specific to Rust web development.
Instructions for AI Agent
When this skill is loaded, configure Aider with the following settings and follow these guidelines:
1. Model and Basic Configuration
Set the model to `gpt-4o` and enable:
`gitignore: true` - respect .gitignore patterns`lint: true` - run linting before commits`test: true` - run tests before commits `format: true` - auto-format code`auto_commits: true` - commit changes automatically`pretty: true` - enhanced output formatting`show_diffs: true` - display diffs clearly`stream: true` - stream responses2. File Exclusions
Configure Aider to ignore these files (beyond .gitignore):
`.env*` - environment files`target/` - Rust build artifacts`*.log` - log files`Cargo.lock` - generated dependency lockfile`.DS_Store` - macOS metadata`*.tmp`, `*.bak` - temporary files`coverage/` - test coverage reports`sessions/` - session dataSet as read-only (reference only, never modify):
`.env.example``README.md``LICENSE`3. Architecture Guidelines
**Module Structure:**
`api.rs` - JSON API route handlers and responses`web.rs` - HTML web handlers and template responses`services.rs` - Business logic and service layer`auth.rs` - Authentication middleware and utilities`context.rs` - Application context and shared state`database.rs` - Database connection and configuration`models.rs` - Data models and database schemas`routes.rs` - Route definitions and middleware setup`server.rs` - Server initialization`main.rs` - Application entry point**Design Principles:**
Keep handlers lightweight - move complex logic to servicesFollow modular separation: handlers → services → databaseUse Axum 0.7 patterns (axum, sqlx, tokio, tera)4. Safety & Security Rules
CRITICAL - Enforce these security practices:
Never expose or log sensitive data (passwords, tokens, connection strings)Always hash passwords with Argon2Use tower-sessions for session managementValidate and sanitize all user input at boundariesNever use raw SQL strings - SQLx macros only5. Database Practices
**Required patterns:**
Use SQLx compile-time checked queries: `sqlx::query!`, `sqlx::query_as!`Never write raw SQL stringsUse transactions for multi-step operationsPlace migrations in `migrations/` directoryUse connection pooling for all database operationsFollow PostgreSQL best practicesExample:
```rust
// Good
let user = sqlx::query_as!(User, "SELECT * FROM users WHERE id = $1", user_id)
.fetch_one(&pool)
.await?;
// Bad - never do this
let query = format!("SELECT * FROM users WHERE id = {}", user_id);
```
6. Testing Strategy
Write tests following these patterns:
Unit tests for business logic in servicesIntegration tests using axum-testTest both success and error casesMock external dependencies appropriatelyPlace tests in `tests/` directory7. Code Quality Standards
**Rust best practices:**
Use Rust 2024 edition features and idiomsPrefer `Result<T, E>` error handling over panickingImplement proper error types that implement `std::error::Error`Use async/await consistently throughoutRun `rustfmt` and `clippy` before suggesting changes**Performance considerations:**
Use connection pooling for database operationsConsider caching for frequently accessed dataImplement proper structured loggingHandle graceful shutdowns properly8. Commit Message Format
Auto-generate commit messages in this format:
```
<type>(<scope>): <description>
```
Types: `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`
Scopes: `api`, `auth`, `db`, `web`, `services`, etc.
Examples:
`feat(auth): add password reset functionality``fix(db): prevent connection pool exhaustion``refactor(api): extract validation to middleware`9. File Type Context Map
When reading files, understand their purpose:
`src/api.rs` - JSON API handlers`src/auth.rs` - Auth middleware`src/services.rs` - Business logic`migrations/*.sql` - Schema migrations`tests/*.rs` - Test suites`templates/*.html` - Tera HTML templatesExample Usage
**Scenario 1: Add new authenticated API endpoint**
```
User: "Add a POST /api/users endpoint that creates a user with email validation"
Aider will:
1. Add route handler in api.rs (lightweight)
2. Add business logic in services.rs (validation, db ops)
3. Use sqlx::query! for database insert
4. Write integration test in tests/
5. Ensure proper error handling
6. Commit with: feat(api): add user creation endpoint
```
**Scenario 2: Fix security vulnerability**
```
User: "The password reset endpoint is leaking user existence"
Aider will:
1. Review auth.rs for timing attacks
2. Implement constant-time response
3. Add unit tests for both cases
4. Run clippy and tests
5. Commit with: fix(auth): prevent user enumeration in password reset
```
**Scenario 3: Database migration**
```
User: "Add created_at and updated_at timestamps to users table"
Aider will:
1. Create migration in migrations/
2. Update models.rs User struct
3. Update relevant sqlx queries
4. Run migration locally
5. Commit with: feat(db): add timestamps to users table
```
Constraints
Never modify read-only files (README, LICENSE, .env.example)Never commit Cargo.lock changes unless dependency updatesAlways run tests before committingNever expose secrets in logs or error messagesAlways use SQLx macros, never raw SQLFollow the established module structureNotes
This configuration assumes PostgreSQL as the databaseRequires SQLx CLI for compile-time query checkingUses Tera for HTML templatingSessions managed via tower-sessionsPasswords hashed with Argon2