vitorlfaria/rust_clean_api

This system is a RESTful API service for managing articles, built with Rust and the Axum framework. It provides standard CRUD operations for article entities, including creating, retrieving, updating, and deleting records. The application persists data using SurrealDB and follows a structured architecture that separates business logic into distinct application and infrastructure layers.

The application's data persistence has switched from an in-memory vector to a SurrealDB database. This change introduces a new \surreal\_context\ module to handle database connections and authentication, and replaces the previous \in\_memory\_db\ implementation with a \TodoRepository\ that performs CRUD operations against the SurrealDB instance. The legacy in-memory database interface and its implementation have been removed to consolidate on this new persistent storage solution.

src/infrastructure · high confidence

The application now uses SurrealDB as its data store, replacing the previous in-memory implementation. This change involves a structural refactor that moves business logic from handlers into dedicated API and application layers, and renames domain entities to models. Additionally, the Todo model's ID type has changed to SurrealDB's Thing type, and timestamps now use local time instead of UTC. The server port has also been updated from 8000 to 8080.

src · high confidence

The todo API endpoints have been restructured to route through the application layer, replacing the previous handler-based implementation with explicit command and query objects. Creating, updating, and deleting todos now invokes dedicated application commands (create\_todo\_command, update\_todo\_command, delete\_todo\_command), while retrieving todos uses queries (get\_all\_todos\_query, get\_todo\_by\_id\_query). This change also updates the HTTP method for updating a todo from PATCH to PUT and moves the request schema into the application layer.

src/application · high confidence

The project has been renamed from 'axum\_api' to 'article\_api' in the Cargo manifest. Additionally, the SurrealDB database client (version 1.0.0) has been added as a dependency, and the 'uuid' crate has been removed in favor of 'once\_cell' for initialization needs.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 45 → 45 (-0.2)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 69 → 69 (+0.0)
• Maturity 51 → 51 (+0.0)
• Readiness 17 → 23 (+5.7)
• Security 100 → 80 (-19.7)

• Dependency hygiene not measured — no supported dependency manifest was read
• No exposed public API
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient
• single-maintainer — knowledge-concentration (bus factor) risk

• Critical CVE: [GHSA redacted] (Cargo.lock)
• Documentation: no installation or build instructions (README.md)
• Documentation: no licence statement (README.md)
• Documentation: no usage examples (README.md)
• Duplicate creation logic: The repository exposes create_todo accepting a domain model, while the command layer exposes create_todo_command accepting raw JSON. This creates two distinct paths for the same business operation (creating a todo), leading to potential inconsistency in validation and transformation logic.
• Duplicate deletion logic: Both the repository and the command layer expose methods for deleting a todo. This redundancy allows for inconsistent handling of deletion (e.g., soft vs. hard delete) if not strictly coordinated.
• Duplicate retrieval logic: The repository provides get_all for data access, while get_all_todos_query provides a method that returns an HTTP response (impl IntoResponse). This mixes data access with HTTP presentation logic in the query object, while the repository remains a pure data access object. This is an architectural inconsistency in how 'all' retrieval is handled.
• Duplicate retrieval logic: The repository provides a direct data access method get_by_id, while a separate query object get_todo_by_id_query exposes an identical semantic operation. This violates the separation of concerns and creates redundant entry points for the same data fetch.
• Duplicate update logic: Similar to creation, both the repository (update_todo) and the command (update_todo_command) expose methods for updating a todo. The command accepts JSON, while the repository accepts a domain model, creating parallel update paths.
• High CVE: [GHSA redacted] (Cargo.lock)
• High CVE: [GHSA redacted] (Cargo.lock)
• High CVE: [GHSA redacted] (Cargo.lock)
• High CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: [GHSA redacted] (Cargo.lock)
• Medium CVE: RUSTSEC-2024-0336 (Cargo.lock)
• …and 21 more

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

vitorlfaria/rust_clean_api was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.