FitLog
A workout and nutrition tracker for Indian gym-goers, with offline set logging, Indian food data, and AI-assisted logging.
Live app → · Django service repo →
Built with Next.js 16, Django and Postgres. 410 unit tests pass, and offline set retries are deduplicated in the database.
Trying it? Use Continue with Google, the fastest way in. It's installable on Android from the landing page.
Screenshots show fictional demo data from the development environment.
What it does
- Logs workouts as they happen. Pick from a 155-exercise catalog and log sets during the session, or afterwards. Save any session as a reusable template.
- Keeps working in a basement gym. Sets logged with no signal are stored on the phone and sync when the app is open and back online. Retrying a set never inserts it twice.
- Understands Indian food. 148 seeded foods (116 with Hindi names) in real serving units: roti, katori, glass. Mark a meal as restaurant food and its calories are scaled by that food's restaurant multiplier. You can also save your own foods.
- Calculates safe targets. A pure-function engine computes calories and macros from Mifflin-St Jeor BMR and activity-based TDEE. No target goes below your BMR, a 1,200 kcal (female) / 1,500 kcal (male) floor, or a 25% maximum deficit, whether you're losing, maintaining or gaining.
- Turns descriptions into logs. Type "bench 4 sets 40x12, 50x10…" and AI workout parsing produces a draft you review before anything is saved. AI meal parsing ("2 roti, dal and curd") validates the reply and logs the matched foods straight away.
- Reports on finished periods. The Progress tab shows weight trend, estimated one-rep max per lift and a consistency grid, all computed by code. Weekly, monthly, quarterly and yearly AI reports summarise those numbers in writing.
- Shares plans publicly. A workout template becomes a public link that previews properly in WhatsApp. Friends can copy it into their own account.
Architecture
Two services and one Postgres database. Application data always goes through same-origin Next.js routes.
flowchart LR
subgraph Device["User's device"]
UI["React app (installable PWA)"]
IDB[("IndexedDB<br/>offline set queue")]
end
subgraph Vercel["Vercel · syd1"]
P["proxy.ts<br/>JWT check · cookie refresh"]
API["Route handlers<br/>auth → Zod → service"]
SVC["Services · Repositories<br/>(Prisma)"]
end
subgraph Supabase["Supabase · Sydney"]
AUTH["Auth"]
PG[("Postgres")]
end
DJ["Django + DRF<br/>(Render)"]
LLM["LLM chain<br/>Gemini → Groq → OpenRouter"]
RL["Upstash Redis<br/>rate limits"]
UI -->|"same-origin HTTPS<br/>httpOnly cookie"| P --> API --> SVC -->|"SQL via pooler"| PG
UI --- IDB
IDB -.->|"sync when online"| P
API -->|"sign-in"| AUTH
API -->|"user's JWT forwarded"| DJ -->|"its own tables"| PG
API --> LLM
API --> RL
- No tokens in JavaScript. Credential and OAuth code exchanges run server-side, and the session lives in an
httpOnly cookie (cookie-options.ts).
- Layered. Route handlers only do HTTP: authenticate, validate with Zod, map errors. Services hold the business rules. Business-data access lives in repositories. The calorie engine (lib/engine) is pure maths with no I/O.
- Server-side integrations. Next.js calls Django, the LLM providers and Redis server-to-server. Django verifies the same Supabase JWT, which Next.js forwards (django.service.ts). Browser-side third-party traffic is limited to Google sign-in, the CAPTCHA widget, error reporting and WhatsApp share links.
Engineering highlights
1. Offline set retries are deduplicated
Gym Wi-Fi drops, taps get doubled, and two tabs can be open at once. Logging a set goes through these steps:
- It's written to an IndexedDB outbox first, with a client-generated request id. Its order number is assigned inside the same IndexedDB transaction, so two tabs can't get the same one (outbox-store.ts).
- A drainer sends queued sets in order, retrying temporary failures after 2s → 5s → 15s → 60s. Where Web Locks are available, only one tab drains the queue at a time (drain.ts, transport.ts).
- On the server, one
SELECT … FOR UPDATE checks ownership, existence and that the workout is still open. A replayed request id returns the row that's already saved, and the set number is assigned as max + 1 under the lock. Unique constraints back up both rules (workout.repository.ts).
- If someone signs in as a different user in another tab, queued sets aren't sent under the wrong account (expected-user.ts).
There's a regression test for the hardest case: a set that commits just as the workout is finished (add-set-replay.test.ts).
2. Diagnosing a slow set save
Saving one set took ~2.9 s in production. The X-Vercel-Id header (bom1::iad1) showed the request entering in Mumbai but running in Washington DC, while the database is in Sydney. The save path makes several sequential database round trips, and each one paid that distance.
Functions are now pinned to syd1, next to the database (vercel.json). The investigation and latency estimates are in DEPLOY_REGION.md.
3. Two services, one database, permissions enforced by Postgres
The Django service owns share_links in the same Postgres, and a stray Prisma command could otherwise treat those tables as drift and drop them. Instead of relying on discipline, permissions are split across database roles (db/roles):
| Role | Can | Cannot |
|---|
fitlog_app (runtime) | read and write app tables | change the schema · read Django's tables · delete users |
fitlog_migrate (migrations) | change Prisma's own tables | drop the schema · directly alter Django-owned tables |
fitlog_deleter | run one account-deletion function | access application tables directly |
- The cross-service foreign key is guarded. DDL triggers check that registered cross-service foreign keys stay in place, with
postgres as the explicit break-glass exception.
- Supabase's public REST API is closed. Application tables in
public have RLS on with no policies, so the anon and authenticated roles can't read any rows. An event trigger also tries to switch RLS on for every new public table (000_rls_auto_enable.sql).
- Each user's data is separated by the app. The runtime role bypasses RLS, so ownership checks in the server code do that job.
- One intentional cross-service effect: deleting a user cascades into their Django share links (db/roles documents this).
4. AI output is treated as untrusted input
- A fallback chain under a time budget. Gemini → Groq → OpenRouter. Meal and workout parsing give each provider 4s + 2s + 2s; reports use a longer budget. If every provider fails, you can still log manually (fallback.ts).
- Workout replies are checked set by set. Numbers are coerced and range-checked. An invalid set (say, a hallucinated 9000 kg lift) is dropped with a warning, and the valid sets around it are kept (ai-workout.service.ts).
- Deterministic exercise matching. Gym shorthand ("OHP", "ham curls", Hinglish like "bench lagaye") is matched without AI. Ambiguous words like "row" or "curl" are never auto-accepted; any suggested match needs your review (exercise-aliases.ts).
- Reports: code does the maths, AI writes the summary. Zod checks the reply's structure and length, but not whether the prose is factually right. A database lease stops two taps from paying for two AI calls (insight.service.ts).
- Rate limits (with Redis available): 15 meal parses and 10 workout parses per user per rolling day, and 16 report generations per rolling 30 days. Each report period also has a database-backed attempt cap.
Tech stack
| Layer | Tools |
|---|
| App | Next.js 16 (App Router) · React 19 · TypeScript (strict) · Tailwind CSS 4 |
| Data | Supabase Postgres + Auth · Prisma 7 with @prisma/adapter-pg · TanStack Query · Zustand |
| Offline / PWA | IndexedDB (idb) · Web Locks · BroadcastChannel · service worker · web app manifest |
| Second service | Django 5 · Django REST Framework · fitlog-django |
| Platform | Vercel (syd1) · Render · Upstash Redis · Sentry · Cloudflare Turnstile |
| Quality | Vitest · ESLint · GitHub Actions |
Testing and CI
- 410 passing unit tests across the calorie engine, validators, offline queue, repositories and AI parsing. Another 20 integration tests run against a real Postgres.
- CI runs on pushes to
main and on pull requests targeting main (ci.yml): type-check → lint → tests → Prisma validation → a migration drift check, which replays every migration into a throwaway Postgres 16 and diffs it against the schema → production build.
npm test # unit tests
# integration tests: apply the migrations to a disposable Postgres first, then
TEST_DATABASE_URL=postgresql://… npm test
Trade-offs and next steps
- Offline covers logging sets, not the whole app. The service worker caches only the offline fallback page and never caches API responses or app assets. Queued sets live in IndexedDB until they sync.
- Running two services has a cost. Django handles public sharing, which adds a second deployment, free-tier cold starts and cross-service database constraints.
- Integration tests aren't in CI yet. Running them against CI's Postgres container is the next step.
- Email signup needs a custom email provider. Supabase's built-in sender only delivers to project members, so Google sign-in is the recommended path for now.
Run it locally
You need: Node.js 22 and a Supabase project (Postgres + Auth).
git clone https://github.com/VaibhavGarg2003/FitLog.git
cd FitLog
npm install
cp .env.local.example .env.local # then fill in the values below
npx prisma generate # generate the Prisma client
npx prisma migrate deploy # create the schema
npm run db:seed # foods + exercises catalog
npm run dev # http://localhost:3000
The Settings "sign-in methods" card needs the private.user_has_password() helper, and account deletion needs private.delete_user_account(). Both live in the SQL under db/roles, which also sets up the production roles. Apply those scripts in the order that README describes, relative to the migrations.
| Variable | Needed for |
|---|
NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY | Auth |
DATABASE_URL (pooler) · DIRECT_URL (direct, for migrations) | Database |
GEMINI_API_KEY, GROQ_API_KEY, OPENROUTER_API_KEY | AI parsing and reports (at least one provider) |
UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN | Rate limits (disabled if unset) |
DJANGO_URL | Share links (the Django service) |
ACCOUNT_DELETION_DATABASE_URL | Optional: account deletion (needs the dedicated role and function) |
SENTRY_DSN, NEXT_PUBLIC_SENTRY_DSN | Optional: server and browser error reporting |
SENTRY_AUTH_TOKEN, SENTRY_ORG, SENTRY_PROJECT | Optional: source-map uploads |
NEXT_PUBLIC_TURNSTILE_SITE_KEY | Optional: CAPTCHA on sign-in |
CRON_SECRET | Optional: protects /api/health |
Project structure
app/ pages (App Router) and API route handlers (app/api)
lib/engine/ calorie and macro engine: pure functions
lib/services/ business rules
lib/repositories/ business-data access (Prisma, transactions, locks)
lib/offline/ IndexedDB outbox, drainer, cross-tab lock
lib/ai/ LLM clients, fallback chain, exercise matching
prisma/ schema, migrations, seed data
db/roles/ least-privilege roles and database guards
proxy.ts session refresh and route protection for matched requests
Built by Vaibhav Garg · GitHub
