Building an ATS Resume Scorer API with FastAPI, Celery, and Docker

Priyadharshiny J — Fri, 30 Oct 2026 11:00:34 +0000

Most resumes are filtered by ATS software before a human ever reads them. This project is a backend API that checks how well a resume matches a job description and suggests how to improve it.

What it does

PDF resume parsing: extracts text from uploaded resumes using pdfplumber
ATS keyword matching: compares the resume against a job description and calculates a match score
Smart suggestions: generates actionable tips to improve the resume for a specific role
JWT authentication: secured endpoints with role-based access for Job Seekers and Recruiters
Batch scoring: recruiters can score many resumes at once, handled in the background by Celery + Redis

Tech stack

Layer	Technology
Backend	Python, FastAPI
Auth	JWT (python-jose, passlib)
Database	MySQL 8.0, SQLAlchemy ORM, Alembic
Task queue	Celery + Redis
PDF parsing	pdfplumber
DevOps	Docker, Docker Compose, AWS EC2
CI/CD	GitHub Actions
Testing	Pytest

Design highlights

Background processing: batch scoring runs through a Celery queue, so the API stays responsive while many resumes are processed.
Role-based access: Job Seekers and Recruiters get separate permissions on the same API.
Reproducible setup: the whole stack (API, MySQL, Redis) starts with a single Docker Compose command.
Automated deployment: a GitHub Actions pipeline deploys automatically to AWS EC2.
Database migrations: schema changes are managed with Alembic.

Source code

https://github.com/priyadharshiny13/ats-resume-scorer

Feedback is welcome. If you were using a tool like this, what would matter more: a more accurate match score or more detailed improvement suggestions?

Building Smart Health API: A Production-Style REST API with CNN-Based Risk Prediction

Priyadharshiny J — Sat, 08 Aug 2026 11:06:09 +0000

By Priyadharshiny J — GitHub: priyadharshiny13

Overview

Smart Health API is a backend platform I built to explore how a real healthcare product might structure its API layer: role-based access for different user types, secure authentication, database migrations that don't break production, and a machine learning model wired into an async pipeline instead of blocking the request thread.

The result is a FastAPI service that lets Patients, Doctors, and Admins interact with the same system through different permission levels, and that returns CNN-based oral cancer risk scores without making the caller wait on model inference.

Stack

API layer: FastAPI
Database: MySQL, with SQLAlchemy ORM
Migrations: Alembic
Auth: JWT-based authentication with Role-Based Access Control (RBAC)
ML: TensorFlow CNN model for oral cancer risk prediction
Async processing: Celery + Redis
Infra: Docker, deployed toward AWS
CI/CD: GitHub Actions

Architecture Decisions

Why RBAC with three roles instead of a single user type?
Healthcare data access isn't uniform — a Patient should only see their own records, a Doctor needs read/write access to their assigned patients, and an Admin needs oversight without clinical permissions. I modeled this directly into the JWT claims and enforced it at the route-dependency level in FastAPI, rather than checking roles inside each endpoint's business logic. This keeps permission logic in one place and out of the individual handlers.

Why Alembic migrations instead of create_all()?
SQLAlchemy.create_all() is fine for a prototype, but it can't handle schema evolution — adding a column, renaming a table, backfilling data. Alembic gave the project versioned, reversible migrations, which is the same discipline a real production service needs the moment more than one person touches the schema.

Why Celery + Redis for the CNN inference?
Running a CNN prediction synchronously inside an HTTP request handler blocks the worker for however long inference takes, which doesn't scale under concurrent load. I moved prediction into a Celery task queue backed by Redis: the API accepts the image, enqueues the job, and returns a task ID immediately. The client polls (or would be pushed a webhook/notification in a fuller version) for the result. This separates the request/response cycle from the compute-heavy ML work.

A Real Debugging Story

Wiring up SQLAlchemy models across multiple modules (User, Patient, Doctor, Prediction) introduced circular import errors once relationships started referencing each other — Patient needed User, User needed Prediction, and Python's import system didn't like the cycle. The fix was restructuring model definitions to use string-based relationship references (relationship("Patient", back_populates=...)) instead of direct class imports, which lets SQLAlchemy resolve the relationship lazily at mapper-configuration time rather than at import time.

Small detail, but it's the kind of thing that only shows up once a schema has enough interrelated tables — and it's a good reminder that ORM relationship design needs the same intentionality as the schema itself.

What's Next

Add automated tests for the RBAC permission boundaries (currently manually verified)
Expose Celery task status through a WebSocket instead of polling
Add rate limiting on the prediction endpoint given its compute cost

Repo

Code and setup instructions: github.com/priyadharshiny13 — see the smart-health-api repository.

DEV Community: Priyadharshiny J