Case study · 03

FitTrack

A mobile-first way to log workouts and stay consistent.

Role

Full-stack & mobile developer

Stack

React Native (Expo) · Node/Express · MongoDB · Cloudinary

Timeline

Ongoing

Status

In progress

View source on GitHub ↗

github.com/omnikam2810-oss/FitForge

Today52 min

Push day

Bench press60 kg

88–

Finish workout

Today52 min

Push day

Bench press60 kg

88–

Shoulder press30 kg

–––

Finish workout

Progress8 weeks

Bench press

52.5 kg60 kg

Best set60 kg × 8

Workouts24

Logging a workout, and tracking progress over time. · Designed screen, sample data

01 — The problem

Consistency needs a good log.

FitTrack is for people who want to record their workouts and keep a consistent routine. Staying consistent starts with tracking, and tracking has to be quick enough to do between sets on a phone.

The goal is a mobile-friendly experience for fitness tracking, backed by a real API and database so that data stays reliable and in sync.

02 — What I built

A gym log, in your pocket.

Mobile app

Built with React Native and Expo, so most of the code is shared across platforms.

Log a workout as exercises and sets, with weight, reps and a completed tick for each set
Totals for volume, sets and muscle groups are worked out for you when a workout is saved
A numeric keypad made for entering sets quickly
An exercise library, training programs and body measurements
A community feed, plus an onboarding flow for new users

Backend & media

A Node/Express API with MongoDB for data, and Cloudinary for media storage.

REST API for app data
MongoDB for users and workouts
Cloudinary for images

03 — Architecture

Mobile front, containerised back.

The Expo app talks to an Express API over REST. The API and MongoDB run in Docker, and media goes to Cloudinary so the API stays light.

Client · Expo

React Native app

Android and iOS from one codebase

↓ REST · to Express API

↑ JSON · from Express API

Server · Docker network

Express API

REST routes, env config, uploads

↓ R / W · to MongoDB

↓ UPLOAD · to Cloudinary

Data · Docker network

MongoDB

Users and workouts

Media

Cloudinary

Images; the API stores references

Docker network

Client · Expo

React Native app

Android and iOS from one codebase

Server

Express API

REST routes, env config, uploads

Data

MongoDB

Users and workouts

Media

Cloudinary

Images; the API stores references

RESTJSONR / WUPLOAD

04 — Key decisions

Three choices that shaped it.

One codebase, two platforms

React Native with Expo shares most of the code between Android and iOS, and Expo Go makes testing on a real phone fast during development.

ii.

Free for everyone

I removed the premium tier and payments so every feature is free to use.

iii.

Media off the server

Images go to Cloudinary, so the API and database only store references.

05 — The hardest part

Inside Docker, localhost isn't where you think it is.

Inside a container, localhost points at that container itself, not at the MongoDB container next to it. I fixed the connection by treating the database as a service on a shared network:

Run the API and MongoDB on the same Docker network
Connect by service name, e.g. mongodb://mongodb:27017/fittrack, instead of localhost
Keep the connection string in environment variables, so each environment gets the right value

06 — What I learned

What it taught me.

Cross-platform mobile

using React Native and Expo to share most of the code across platforms.

End-to-end data flow

wiring the app, API and database carefully so data moves reliably.

Environment configuration

how database connections, environment variables and container networking change behaviour between environments.

Next case study

DevTrace

A self-hosted observability platform for metrics, logs, traces and incidents.