2.4 KiB
2.4 KiB
Rhythm Backend
High-performance Rust backend for a lightweight issue tracking platform focused on team execution.
Main Objective
Build a simple, reliable issue tracker where teams can:
- Create and manage projects
- Add users to projects with role-based permissions
- Create, update, and track issues with practical metadata
- Organize work through Kanban and Scrum views
The first version prioritizes clean CRUD, clear access control, and fast text search on plain-text issue data. Encryption and advanced collaboration features can be added in later iterations.
How To Start
-
Lock the V1 scope
- Entities:
users,projects,project_members,issues - Roles:
owner,maintainer,member,viewer - Issue fields:
title,description,status,priority,type,assignee_id,reporter_id, optionalsprint_id, timestamps - Keep Kanban and Scrum as filtered endpoints first (not separate DB models)
- Entities:
-
Bootstrap the Rust service
- Stack:
axum,tokio,sqlx,postgres,tracing - Suggested modules:
http/,service/,repo/,model/,auth/,db/ - First route:
GET /health
- Stack:
-
Build the database first
- Migrations for
users,projects,project_members,issues - Add unique constraint on
(project_id, user_id)in memberships - Add indexes for issue listing and filtering
- Add
tsvector+GINindex for title/description full-text search
- Migrations for
-
Implement CRUD vertical slices
- Projects: create, read, update
- Memberships: add member, update role, remove member
- Issues: create, list with filters + pagination, update, delete/soft-delete
-
Add board endpoints
- Kanban endpoint grouped by status
- Scrum endpoints for sprint + backlog views
- Keep these as query/aggregation logic on top of
issues
-
Harden the service
- Add authentication (JWT or session)
- Enforce role checks per project
- Add request validation and consistent error responses
- Add integration tests for permissions and issue lifecycle
- Add slow-query logging and tune key SQL with
EXPLAIN ANALYZE
Technical Direction
- Language: Rust
- API: REST
- Database: PostgreSQL
- Search: PostgreSQL full-text search (
tsvector+GINindexes) - Scale target: under 1M issues
Notes
- Keep handlers thin, business rules in services, SQL in repository layer
- Prefer cursor pagination over deep offset pagination
- Add external search only when Postgres full-text search becomes limiting