TaskFlow API
In ProgressAn in-progress backend system exploring how APIs hand expensive work to background workers.
Interactive project walkthrough
Interactive Preview
API and Queue Architecture Explorer
This panel is an architectural simulation for portfolio purposes only. It runs entirely in your browser and does not call the real TaskFlow backend.
Simulates the current /health endpoint response.
Project Overview
TaskFlow is a FastAPI and PostgreSQL backend currently focused on account creation and validation, being built out toward a full job-queue architecture for background task processing.
My Role
Designing and implementing the backend foundation, database layer, account-creation flow, and eventual queue-processing architecture.
The Problem
Some operations, such as sending email or processing files, shouldn't force users to wait for an entire task to finish during a single HTTP request.
The Solution
An API that validates and stores work, places jobs into a queue, processes them through workers, and exposes status information. This describes the project's intended architecture and is not yet complete.
Key Features
FastAPI Foundation
Structured routers and request handling for account-related endpoints.
PostgreSQL + SQLAlchemy
Database models and reusable sessions for persisting user accounts.
Validated Signup Flow
Pydantic schemas validate incoming requests and catch duplicate emails.
Password Hashing
Passwords are hashed before storage rather than kept in plain text.
Technical Architecture
Currently implemented
Planned architecture
PlannedCurrently Implemented
- FastAPI request handling
- PostgreSQL integration
- SQLAlchemy models and sessions
- Validated account creation
- Password hashing
- Health endpoint
- Duplicate-email error handling
Planned ArchitecturePlanned
- Job creation
- Queue storage
- Background workers
- Job status tracking
- Retry handling
- Email verification jobs
- Authentication
- Worker concurrency
Engineering Highlights
- Designed REST endpoints for users and task-management operations.
- Connected FastAPI to PostgreSQL through SQLAlchemy models and database sessions.
- Added request and response validation with Pydantic schemas.
- Implemented duplicate-account handling with proper database rollback.
- Structured the backend into maintainable routers, models, schemas, and services.
Challenges and Lessons
Challenges
- Structuring the codebase into routers, models, schemas, and services early enough to support a future queue system without a rewrite.
- Handling duplicate-account edge cases cleanly with a proper database rollback instead of a raw exception.
Lessons Learned
- Designing the database session and model layer carefully up front makes it much easier to add background workers later.
- Validating and testing the account-creation path thoroughly before adding authentication reduces compounding bugs.