backend-final-project
Shipped: A service with a job running behind it
Repository: https://sgm322.github.io/finalBackendDevConnect/ Built for the Verified Backend Internship · Final project
Shipped: A service with a job running behind it
Project Overview I built an asynchronous Background Job Processing Service using Node.js, Express, MySQL (TiDB Cloud Serverless with TLS/SSL), and deployed it to Render. The architecture consists of: 1. REST API Server: Accepts job requests, validates authentication, enforces user scoping, and guarantees idempotency. 2. Background Worker: Polls pending tasks from the database, executes the job asynchronously, tracks attempt limits, and updates the status upon completion. 3. Persistent Database: Managed TiDB Cloud database storing jobs, idempotency keys, execution statuses, and timestamps. --- How to Test and Verify Acceptance Criteria Base URL: https://final-project-5nyu.onrender.com Auth Token: supersecrettoken123 1. Submit a New Job (POST /jobs) Run the following curl command to submit a background job: bash curl -X POST https://final-project-5nyu.onrender.com/jobs \ -H "Content-Type: application/json" \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" \ -d '{"idempotencyKey": "demo-key-001"}' Expected Output: Returns HTTP 202 with jobId and status: "pending". 2. Check Job Status (GET /jobs/:id) Allow 1-2 seconds for the worker to process the job, then retrieve the status: Bash curl -X GET https://final-project-5nyu.onrender.com/jobs/1 \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" Expected Output: Returns HTTP 200 with status: "completed" and execution details (processedAt). 3. Test Idempotency (Duplicate Prevention) Re-run the exact same POST request with the same idempotencyKey: Bash curl -X POST https://final-project-5nyu.onrender.com/jobs \ -H "Content-Type: application/json" \ -H "Authorization: Bearer supersecrettoken123" \ -H "x-user-id: user 101" \ -d '{"idempotencyKey": "demo-key-001"}' Expected Output: Returns HTTP 200 with the existing jobId and message "Job already registered" without creating a duplicate record. 4. Test Authentication & User Isolation Missing/invalid Authorization header returns HTTP 401 Unauthorized. Missing x-user-id header returns HTTP 401 Missing user identity. Repository: https://github.com/roh155/final project Live: https://final-project-5nyu.onrender.com Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
A reading-list API with JWT-based accounts. Unauthenticated requests to /books return 401. Every book query is scoped to the caller's user id, and GET/DELETE on another user's book returns the same 404 as a nonexistent id -- so ownership can't be probed for. This is proven with node test-isolation.js, which registers two users, has user A create a book, and shows user B getting 404 on it while user A still gets 200. POST /books accepts an optional Idempotency-Key header: retrying the same key returns the original book instead of creating a second row -- node test-idempotency.js demonstrates this with real output (same id returned twice, list shows exactly one row). All 400 errors name the specific field that was wrong. No secret is committed -- JWT SECRET is read from an environment variable, with only a .env.example checked in. Reviewer steps: npm install, cp .env.example .env (set JWT SECRET), npm start, then run the two test scripts above in another terminal. Repository: https://github.com/GhulamMustafaAnsari/reading-list-service Live: https://reading-list-service.bonto.run/health Built for the Verified Backend Internship · Final project
Shipped: A service with a job running behind it
I built and deployed an asynchronous digest service using Node.js, Express.js, MongoDB Atlas, Mongoose, JWT, bcryptjs, Zod, and JavaScript-based background workers. The API authenticates users, isolates user-owned data, accepts digest requests asynchronously, and returns "202 Accepted" without waiting for the background work to finish. Digest jobs are stored in MongoDB and processed by a separate worker with idempotency, retry handling, stale-job recovery, and actionable error states. The service also uses an in-memory cache for completed digest responses. The application code is pushed to GitHub, the API server is deployed on Render, the background worker is deployed as a separate Render Background Worker, and the database is deployed on MongoDB Atlas. The API has been fully tested with Postman, and the complete Postman collection is included in the GitHub repository so the reviewer can import it and test the endpoints directly. How the reviewer can verify the acceptance criteria ● Deployed and reachable: Open the deployed Render API URL and call "/health". The GitHub repository is linked in the project documentation. ● Request returns without waiting: Send "POST /api/v1/digests" with valid authentication and an "Idempotency-Key". The API immediately returns "202 Accepted", while the separate Render background worker processes the job afterward. ● Safe to run twice: Send the same digest request again using the same "Idempotency-Key". The existing digest is returned instead of creating a duplicate. ● Worker failure handling: The README documents the "QUEUED → PROCESSING → COMPLETED/FAILED" lifecycle, retry attempts, stale-job recovery, and what happens if the worker dies during processing. ● Authentication: Call a protected endpoint without an "Authorization" header. The API returns "401 Unauthorized". ● User isolation: Digest and event queries are scoped to the authenticated user's ID, preventing one user from reading another user's records. ● Actionable errors: The API returns structured "400", "401", "404", "409", and "500" responses with machine-readable error codes and human-readable messages. ● Caching: Completed digest responses are cached in application memory for 60 seconds, with MongoDB remaining the source of truth. ● No committed secrets: ".env" is excluded through ".gitignore". ● API testing: The included Postman collection contains the complete authentication, protected-route, event, digest, retry, and health-check flows and can be imported directly by the reviewer. Repository: https://github.com/abbasg-dev/async-digest-service Live: https://async-digest-service.onrender.com Built for the Verified Backend Internship · Final project
Shipped: A service with a job running behind it
I built and deployed relay/digest, a Vercel-hosted service that accepts authenticated CSV imports through a responsive dashboard and returns immediately with 202 Accepted , while Vercel Cron processes the import in the background. A reviewer can visit https://relay-digest-api.vercel.app and enter the configured AUTH TOKEN , submit the sample CSV, and observe the import move from queued to completed . The service uses account-scoped database queries so users cannot read another account’s rows, idempotency keys and unique database constraints make retries safe, and worker leases recover jobs that die mid-processing while storing visible errors. The protected API returns 401 Unauthorized without credentials, CRON SECRET protects the scheduled worker, the README documents failure recovery and deployment, the repository contains the requested DevConnect badge and MIT license, and secrets are supplied through environment variables rather than committed to source. Repository: https://github.com/azizulabedinazmi/Relay-Digest-API Live: https://relay-digest-api.vercel.app/ Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
Deployed an accounts-backed habit tracker (Node.js, built-in http and node:sqlite, no external dependencies) at https://habit-tracker-1u6z.onrender.com, repo at https://github.com/mohammedoomatia-max/habit-tracker. Users sign up/log in and get a bearer token; every /habits... route requires Authorization: Bearer <token and returns 401 with a named field if it's missing or invalid. Ownership is enforced by scoping every habit lookup to WHERE id = ? AND user id = ? — a habit that exists but belongs to someone else returns 404, identical to a habit that doesn't exist, so IDs can't be enumerated by watching for 403 vs 404; test/acceptance.test.js proves this with a real two-account test. The retry-safe write path is check-ins: POST /habits/:id/checkins is keyed on (habit id, date) with a UNIQUE constraint as the backstop, so the same check-in sent twice returns the existing row (200) instead of creating a duplicate — reasoning is in the README. All 400 errors return {error, field} naming exactly what was wrong. No secret is committed: password hashing reads a pepper from PASSWORD PEPPER, set as an environment variable on Render, with only a placeholder in the committed .env.example. Run node test/acceptance.test.js to verify the first four reviewer checks automatically (18/18 passing) Repository: https://github.com/mohammedoomatia-max/habit-tracker Built for the Verified Backend Internship · Final project
Shipped: SpendingWrapped - my final project entry
I built a tracker that turns a year of spending, uploaded as a CSV, into a review like Spotify Wrapped: total spent, biggest month, most-visited merchant and a category breakdown. The upload returns 202 in milliseconds, and a separate worker process does the import in the background, saving its progress every 50 rows. Because the database refuses duplicate rows, running an import twice or retrying after a crash gives the same result, and a fingerprint of the summary proves it. Repository: https://github.com/Kam-ino/DevConnect-Internship/tree/main/SpendingWrapped Live: https://devconnect-internship-final-project.onrender.com Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
Repository: https://github.com/yanayem/task-3 Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
Repository: https://github.com/saikatdas47/expense-tracker Live: https://expense-tracker-88pa.onrender.com/ Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
An Event booking service with ASP.NET as backend and Postgres as db. Organizers publish events with a limited capacity, attendees register for them. Everything except public event reads requires a JWT. Missing or malformed tokens return 401. Registration is idempotent: a repeat returns the original registration and consumes no extra seat. Repository: https://github.com/Abadli-Badro/EventHub Live: https://eventhub-ly9o.onrender.com/ Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
ContextQuery AI Live API: https://contextquery-api.onrender.com/docs Web Console: https://context-query-ai-frontend.vercel.app/ Repository: https://github.com/Ramsha-Anwar/context-query-ai What it does ContextQuery AI is a zero-cost, multi-tenant B2B SaaS backend. Users create isolated Knowledge Hubs, add knowledge by pasting text or uploading PDFs, and ask natural-language questions. Answers are generated using Groq and retrieved via pgvector similarity search over chunked, embedded documents. Every write path is idempotent, every query is strictly tenant-isolated, and the RAG pipeline is gated by a custom LLM-as-a-Judge evaluation suite. Tech Stack Backend: Python 3.11, FastAPI, SQLAlchemy 2.0, Alembic Database: PostgreSQL with pgvector (Neon) AI Generation: Groq (openai/gpt-oss-120b) AI Embeddings: FastEmbed (BAAI/bge-small-en-v1.5) running locally via ONNX Evaluation: Custom LLM-as-a-Judge suite (Faithfulness, Relevancy, Recall@5, MRR) Deployment: Docker, Render (API), Vercel (Frontend), Neon (DB) Authentication and Isolation Every protected route requires a valid JWT (Authorization: Bearer <token ). Tenant isolation is enforced at the repository layer. Cross-tenant reads, lists, and deletes return a cloaked 404 HUB NOT FOUND (never a 403, which would leak existence). Vector search filters by owner id and hub id before calculating cosine distance. Proven by tests: test user b cannot read user a hub, test vector search is scoped to owner. Retry Safety If a network drops during a write, retrying is safe. For POST /hubs and POST /hubs/{id}/documents, provide an X-Idempotency-Key header (UUIDv4). The server hashes the request body and stores it with your key. If you retry with the same key and same body, the server returns the original cached response with Idempotent-Replayed: true, without creating duplicate rows or burning AI quota. Errors Every error uses a standard JSON envelope. Field-level error (422): { "error": { "code": "VALIDATION ERROR", "message": "Request validation failed.", "status": 422, "request id": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "details": [ { "field": "body.name", "reason": "string too short", "message": "String should have at least 1 character" } ] } } Non-field error (404): { "error": { "code": "HUB NOT FOUND", "message": "Hub not found.", "status": 404, "request id": "7c9e6679-7425-40de-944b-e07fc1f90ae7", "details": [] } } Measured RAG Quality Evaluated on a 50-question golden dataset (run on 2026-10-25). Faithfulness: 0.92 (Gate ≥ 0.70) Answer Relevancy: 0.98 (Gate ≥ 0.70) Recall@5: 0.98 (Gate ≥ 0.85) MRR: 0.98 (Gate ≥ 0.65) Cost and Latency Cost: $0.00/month (Render free tier, Neon free tier, Groq free tier, Vercel free tier). Latency: Avg query response 2.5s (dominated by Groq generation). Cold Starts: Render free tier sleeps after 15 mins. A cron-job pings /healthz every 10 minutes to keep it warm. This is a workaround, not a guarantee. Run Locally Using Docker (Recommended) git clone https://github.com/Ramsha-Anwar/context-query-ai.git cd context-query-ai cp .env.example .env Add your GROQ API KEY and DATABASE URL to .env docker compose up -d alembic upgrade head The API is now running at http://localhost:8000. Bare Metal python -m venv .venv source .venv/bin/activate Windows: .venv\Scripts\activate pip install -r requirements.txt -r requirements-dev.txt alembic upgrade head uvicorn app.main:app --reload Tests Fast tests (mocks the AI layer) pytest -q -m "not eval" Full 50-question evaluation gate (requires real GROQ API KEY) pytest -q -m eval -s Try it (cURL) Create a hub with inline text curl -X POST https://<YOUR RENDER URL /api/v1/hubs \ -H "Authorization: Bearer YOUR JWT TOKEN" \ -H "X-Idempotency-Key: $(uuidgen)" \ -H "Content-Type: application/json" \ -d '{"name": "HR Policies", "content": "Employees get 20 days of annual leave."}' Environment Variables Variable Description DATABASE URL Postgres connection string (pooled). DIRECT DATABASE URL Postgres connection string (direct, for Alembic). JWT SECRET KEY 32+ byte random string for HS256. GROQ API KEY API key for Groq generation. GROQ MODEL openai/gpt-oss-120b EMBEDDING DIM 384 RAG MIN SIMILARITY 0.25 (threshold to prevent hallucinations) CORS ORIGINS Comma-separated allowed origins (Vercel URL). What we fixed vs. what we documented Fixed Documented as trade-off Cross-chunk retrieval via multi-query expansion Fixed-size chunking (no semantic boundaries) Refusal path when retrieval similarity is too low In-memory rate limiter (single instance) Retrieval evaluation (Recall@5 + MRR) in the gate Client-driven ingestion (no background worker) Idempotent document process state machine PDF text extraction (not layout-aware) Architectural Deviations from PRD Generation: The PRD specified Gemini. We use Groq (openai/gpt-oss-120b) because the Gemini free tier capped at 20 requests/day, making CI evaluation impossible. Embeddings: The PRD specified Gemini Embeddings. We use FastEmbed (bge-small-en-v1.5) running locally to save memory on Render's 512MB free tier. Evaluation: The PRD specified RAGAS. We built a custom LLM-as-a-Judge suite because RAGAS had unresolvable C++/LangChain dependency conflicts. Known Limitations Fixed-size chunking with overlap; no semantic chunking. Single-instance rate limiter (will break if scaled to multiple servers). No update endpoints for hubs or documents. The database schema and query plans are detailed in DATA MODEL.md. Repository: https://github.com/Ramsha-Anwar/context-query-ai Live: https://context-query-ai-frontend.vercel.app/ Built for the Verified Backend Internship · Final project
Shipped: A service somebody else could run
I built a secure backend Habit Tracker API using Node.js, Express, and native SQLite. How to verify the acceptance criteria: - Deployed & Public: The live service is hosted on Render at the provided URL, and the source code is fully linked on GitHub. - Authentication & Security: Protected routes require an Authorization header and return 401 Unauthorized if credentials are missing or invalid. - Data Isolation: All queries are strictly filtered by user id to ensure users cannot access other accounts' rows. - Retry-Safe (Idempotent) Write Path: The POST /habits route uses an idempotencyKey to prevent duplicate records during retries (detailed in the README). - Descriptive Errors: The API returns clear JSON error messages for invalid requests. - Testing: Reviewers can easily test all endpoints using the test.http file in the repository by swapping the localhost URL with the live Render URL. Repository: https://github.com/oliviamol/Habittracker Live: https://habittracker-cb70.onrender.com/ Built for the Verified Backend Internship · Final project
Shipped: A service with a job running behind it
Repository: https://github.com/garima-2006/background-digest-service Live: https://background-digest-service.onrender.com Built for the Verified Backend Internship · Final project