review-backend

Rust Backend Code Review

Review from the perspective of a principal engineer with deep expertise in Rust, Axum, SQL, web application architecture, and security. Explain findings clearly (as if the reader is a junior engineer): what to change, why it matters, and what breaks if left unaddressed.

0. Problem-Solution Fit

Real Issue Resolution: Ensure the code addresses a real issue or feature request, rather than hypothetical future needs. Flag speculative or "just in case" abstractions.

Simplicity of Solution: Look for the simplest design that solves the problem. Check for premature generalization, over-engineering, unnecessary abstractions, or unneeded layers of indirection.

1. Project Standards

Error Handling: Try to avoid map_err. Use ? propagation with implicit From conversions.

Structured Logging: Log messages must be short, lowercase, using underscores, no spaces, with key-value fields. Example: warn!(user_id = user.id.0, error = %err, "password_rehash_failed");

Chaining & Validation: Enforce method call chaining for functional pipelines, and ensure validator::Validate is used for incoming request payloads.

DDD Structure: Ensure bounded contexts are organized with the 3-file feature layout: _api.rs, _db.rs, and _service.rs.

Test Placement: New tests must go in backend/test/ which ensures fast builds.

2. Correctness

Logic & Edge Cases: Check paths for empty inputs, off-by-one, integer overflow, and Option/Result unwrap chains.

Panics: No .unwrap(), .expect(), panic!, or todo!() in request-handling paths. Use ? error-propagation or safe options like .get().

Concurrency: Ensure Mutexes are not held across .await points. Use tokio::sync::Mutex for async environments if needed, or avoid locks entirely.

3. Simplicity

Cyclomatic Complexity: If a function has more than ~7 decision branches, recommend splitting (excluding exhaustive match on sealed enums).

Coupling: Avoid reaching into other modules' internals. Favor dependency injection.