Unlike traditional MVC frameworks that segment code horizontally by technical layers (controllers, models, views), Stick is organized by vertical slices. Each domain feature—such as authentication, tasks, or audit logging—lives together in its own self-contained module. This simplifies code maintenance and cognitive load in medium-to-large codebases where horizontal layers inevitably grow difficult to navigate.

Architectural Philosophy & Layout

1. Vertical Slice Domain Layout

Every domain feature owns its database access models, business logic, endpoints, and markup templates. For example:

src/auth/models.rs: BSON data structures and claims.
src/auth/repository.rs: Database operations and query logic.
src/auth/handlers.rs: Request/response lifecycle logic.
src/auth/extractors.rs: Axum extractors for user session handling.
templates/auth/: HTML templates compiled at build-time.

2. Separating Components from Documentation

To prevent domain pollution and maintain code integrity, we strictly separate template assets:

Reusable UI Components (templates/components/): Reserved strictly for operational UI blocks used across the application. Reusable elements like fields, dropdowns, calendars, and buttons are defined as Askama macros inside templates/components/macros.html.
System Documentation (templates/docs/ & src/docs/): Design manuals, guidelines, and interactive preview sandboxes are isolated. The Documentation portal is served on a dedicated /docs route, separate from core application logic.

3. Key Stack Decisions

Axum (v0.8): Modern, async-first routing and middleware.
Askama (v0.16): Evaluates and compiles HTML templates into Rust code at compile time. Syntax, variable existence, and type constraints are verified by the compiler.
MongoDB: Standard Rust driver configured with BSON serialization.
Tailwind CSS: Utility-first styling compiled using a Node-based wrapper process.
JWT Authentication: Managed via JSON Web Tokens stored in secure, encrypted HttpOnly cookies.

Audit Logging Framework (First-Class Feature)

Stick contains a built-in, request-scoped Audit Logging and Replay framework designed to make all critical system mutations (Create, Read, Update, Delete, Search) auditable.

       Request
          │
          ▼
┌──────────────────┐
│   AuditLogger    │ ──► Resolves: DB, User, User-Agent
│    Extractor     │
└──────────────────┘
          │
          ├──► Parses "x-forwarded-for" & "x-real-ip" proxy headers
          ├──► Parses Direct ConnectInfo TCP socket IP
          │
          ▼
┌──────────────────┐
│  Log Entry Writ  │ ──► Formats: "ProxyIP (Socket: SocketIP)" if mismatched
└──────────────────┘
          │
          ▼
┌──────────────────┐
│  MongoDB Store   │ ──► Stores structured entry + JSON state snapshot
└──────────────────┘

1. Request-Scoped Extractor (`AuditLogger`)

The custom AuditLogger extractor implements Axum's FromRequestParts trait. When added to any handler function signature, it automatically resolves:

Database connection reference.
Optional authenticated user context.
Client metadata (IP address and User-Agent).

2. Intelligent IP & Proxy Resolution

To support load-balanced or proxied environments, the extractor resolves and logs both network paths:

Inspects standard proxy headers (x-forwarded-for, x-real-ip).
Captures the direct TCP client connection address via Axum's ConnectInfo.
If the proxy IP and connecting socket IP differ, the logger combines them (e.g. 10.0.0.1 (Socket: 127.0.0.1)) ensuring full visibility of both the request origin and proxy hop.

3. Historical State Snapshotting (Replayability)

Log entries include a serialized JSON payload field containing the state of the affected entity. For edits, it saves the state transition. For deletions, it saves the final snapshot before removal, ensuring data remains reconstructible in the event of an audit inquiry.

4. Admin Audit Panel

Authorized administrators can review, search, and audit system activities at /auth/audit. The dashboard allows filtering entries by:

Username: Filter logs to a specific actor.
Event Type: Filter by actions (e.g. Login, Create, Update, Delete).
Entity Type & ID: Pinpoint history for a specific resource (e.g. Task, Developer).
Timeline: Filter logs by start and end timestamps.

Core Features Included

Self-Provisioning Administrator

On startup, if the MongoDB users collection is empty, Stick automatically provisions an administrator account with username admin, generates a secure random 16-character alphanumeric password, and outputs the credentials directly to the console logs:

======================================================
CREATED INITIAL ADMINISTRATOR ACCOUNT:
Username: admin
Password: [GeneratedPassword]
======================================================

User Management Panel (Admin Only)

Accessible at /auth/users. Administrators can view all users, register new ones, toggle administrative roles, reset passwords, or delete standard accounts (with safety blocks preventing administrators from deleting their own active profile or revoking their own privileges).

Self-Service Password Reset

Any logged-in user can change their password at /auth/password by clicking their username in the navigation bar.

Setup and Running

Prerequisites

Rust: Toolchain v1.75+ (for native async traits).
Node.js & npm: Required to build Tailwind CSS.
MongoDB: Running locally on mongodb://127.0.0.1:27017.

Local Setup

Copy the environment configuration:
```
cp .env.example .env
```

Build Tailwind CSS styling:

npm install
npx tailwindcss -i src/input.css -o static/tailwind.css

Run the development server:
```
cargo run
```
The server will start listening at http://127.0.0.1:3009 (as configured in .env).

Running with Docker

A multi-stage Dockerfile compiles Tailwind, compiles the Rust binary, and bundle a lightweight Debian runtime container.

Build the image:
```
docker build -t stick .
```

Start the container:

docker run --name stick-app --rm --network="host" \
  -e DATABASE_URL="mongodb://127.0.0.1:27017" \
  -e DATABASE_NAME="stick_db" \
  -e JWT_SECRET="super_secret_template_signing_key_that_is_at_least_32_characters_long" \
  -e HOST="127.0.0.1" \
  -e PORT="3009" \
  stick

Developer Cookbook

1. Adding a Feature Slice (e.g. `projects`)

Create a module folder: src/projects/.
Define models in models.rs and database access operations in repository.rs.
Add request handlers in handlers.rs.

Create src/projects/mod.rs to expose the router:

pub fn router<S>() -> Router<S>
where
    crate::common::config::Config: axum::extract::FromRef<S>,
    mongodb::Database: axum::extract::FromRef<S>,
    S: Clone + Send + Sync + 'static,
{
    Router::new()
        .route("/projects", get(handlers::get_projects))
}

Place HTML templates under templates/projects/ extending the base.html layout.

let app = Router::new()
    .merge(main_view::router())
    .merge(auth::router())
    .merge(projects::router()) // Merge domain router
    .with_state(state);

2. Logging Operations with `AuditLogger`

To log any action in a handler, inject logger: AuditLogger and invoke .log() after a successful DB mutation:

use crate::audit::AuditLogger;
use serde_json::json;

pub async fn delete_task_handler(
    State(repo): State<MongoTaskRepository>,
    logger: AuditLogger, // <-- Automatically injected
    Path(task_id): Path<ObjectId>,
) -> Result<impl IntoResponse, AppError> {
    // 1. Fetch task and perform mutation
    let task = repo.get_by_id(&task_id).await?;
    repo.delete(&task_id).await?;

    // 2. Audit the event (single line, fully context-aware)
    logger.log(
        "Delete",                   // Event action
        "Task",                     // Entity type
        Some(task_id),              // Target entity ID
        Some(format!("Deleted task '{}'", task.title)), // Description
        Some(json!(task)),          // Serialized payload for replayability
    ).await;

    Ok(Redirect::to("/tasks"))
}

Production Deployment to a Cloud Host (DigitalOcean Droplet)

For production deployments (such as to a DigitalOcean Droplet), the application is fully containerized and configured via standard environment variables.

The application is completely decoupled from the underlying hosting, networking, and database infrastructure. You are responsible for provisioning the database and supplying the connection configuration.

1. Build the Application Container

Build the application Docker image:

docker build -t stick-app .

2. Deploy the Application Container

Run the container on your target Docker network, providing the connection details to your pre-existing MongoDB database container through environment variables:

docker run -d \
  --name stick-app-container \
  --network your-docker-network \
  -p 80:3007 \
  -e DATABASE_URL="mongodb://your-mongodb-host:27017" \
  -e DATABASE_NAME="stick_db" \
  -e JWT_SECRET="your_secure_production_jwt_signing_key_at_least_32_chars_long" \
  -e HOST="0.0.0.0" \
  -e PORT="3007" \
  --restart unless-stopped \
  stick-app

Note: Adjust the port mapping (-p), container name, network name, and DATABASE_URL environment variable as necessary to integrate with your custom proxy or container infrastructure.

Languages

HTML 67%

Rust 21.4%

JavaScript 10%

CSS 1.1%

Dockerfile 0.5%

README.md

Stick