Tasker - Personal Task Management API
Tasker is a personal task management API built with Go and PostgreSQL, designed to organize tasks, priorities, deadlines, subtasks, and progress within individual user accounts.
- The problem
- As task lists grow, a simple checklist makes it harder to distinguish urgent work, break larger tasks into smaller steps, and keep relevant notes attached to each task. Users need a structured way to organize their responsibilities and understand what is active, completed, or overdue. The engineering challenge was to model those relationships while handling authentication, data ownership, validation, and persistence consistently.
- My role
- I designed and developed Tasker’s Go backend, including REST APIs, PostgreSQL data models, and business logic for tasks, subtasks, categories, and comments. I integrated Clerk authentication, user ownership checks, request validation, and error handling. I also built supporting infrastructure for database migrations, background email processing, logging, monitoring, and health checks, while establishing the React frontend and shared API tooling foundation.
- What I built
- I built a versioned REST API using Go and Echo, backed by PostgreSQL. I implemented handlers, services, and repositories for tasks, categories, and comments, with Clerk authentication and queries scoped to the authenticated user. Beyond the core task features, I added database migrations, reusable request validation, centralized error handling, structured logging, New Relic instrumentation, dependency health checks, and background email processing infrastructure. I also established a React and TypeScript frontend foundation and shared packages for API contracts, schemas, and email templates.
- The approach
- Tasker provides a centralized task management API designed around individual user accounts. It brings together task statuses, priorities, deadlines, categories, subtasks, and comments, with search and filtering to help users find relevant work. Statistics endpoints summarize progress and overdue tasks. A layered Go backend separates HTTP handling, business rules, and database access, making the system easier to maintain and extend.
Overview
Tasker is a task management project designed to give everyday work more structure. Its backend models tasks with draft, active, completed, and archived statuses, alongside priorities, due dates, categories, and subtasks. Comments keep notes attached to their relevant tasks, while search, sorting, pagination, and filters support finding work by status, priority, category, deadline, or completion state. Statistics endpoints provide counts of tasks across statuses and identify overdue work. I organized the Go backend into handlers, services, and repositories so that request processing, business rules, and persistence have distinct responsibilities. The service layer checks ownership when assigning categories or parent tasks and restricts subtasks to a single nesting level. PostgreSQL stores the relationships using foreign keys, indexes, timestamp triggers, and versioned migrations. The project also includes infrastructure for operating and extending the backend: Clerk authentication, rate limiting, structured logs, request IDs, New Relic tracing, database and Redis health checks, and graceful shutdown. Redis and Asynq support background welcome-email processing through Resend. A Bun and Turborepo workspace connects the React frontend foundation with shared schema, API contract, and email-template packages.
A Layered Backend with Background Processing
Layered Backend Design: Separated HTTP handlers, business logic, and database access. Asynchronous Job Infrastructure: Built Redis and Asynq infrastructure for background email processing. Backend Observability: Integrated structured logging, request IDs, and New Relic instrumentation.
Balancing Data Integrity and Flexibility
Single Level Subtasks: Restricted nesting to simplify task relationships. Database Enforced Integrity: Used foreign keys, unique category names per user, and timestamp triggers. Flexible Task Metadata: Used JSONB for optional attributes alongside relational task fields. Email Job Retry Strategy: Configured queue priorities, retries, and execution timeouts
Managing Ownership and Task Relationships
User Ownership Boundaries: Scoped operations to each authenticated user’s data. Parent–Subtask Validation: Checked parent ownership and prevented self-parent relationships. Combined Task Queries: Developed search, filtering, sorting, and pagination logic. Consistent API Errors: Centralized validation and database error responses.
Health Checks, Diagnostics, and Testing Foundations
Dependency Health Checks: Implemented PostgreSQL and Redis connectivity checks. Request Diagnostics: Added logs and traces to investigate failures and execution times. Integration Testing Foundation: Prepared PostgreSQL Testcontainers helpers; feature tests remain pending.
Current Gaps and Remaining Work
Frontend Completion: The React interface currently remains a starter screen. API Contract Coverage: Shared contracts and generated documentation currently cover health checks. Signup Email Integration: Welcome-email workers are not connected to signup events. Backend Validation Gaps: Integration tests and query consistency fixes remain outstanding. Production Evidence: Performance and reliability still require benchmarking and deployment validation.