Full-Stack Management Systems
A banking REST API in Spring Boot, a gym operations platform in Flask, and a college app paired with an admin app on a shared Firebase backend.
- Role
- Sole developer
- Year
- 2025
- Stack
- Java 21
- Spring Boot
- Spring Data JPA
- MySQL
- Lombok
- Python
- Flask
- SQLAlchemy
- Flask-Login
- APScheduler
- SQLite
- Android
- Firebase
01The problem
Each of these is an operations problem: keeping records consistent, enforcing rules on money and membership, and getting the right information to the right person — whether that's a bank teller, a gym administrator, or a student checking today's notices.
Banking API
Spring Boot · Java 21
REST client
/api/accounts
AccountController
create · get · list · deposit · withdraw · delete
AccountService
Business rules, e.g. reject overdrafts
AccountRepository
Spring Data JPA
MySQL
accounts table
Gym platform
Flask · SQLAlchemy
Browser
Server-rendered Jinja templates
Flask routes
@login_required, staff & admin users
SQLAlchemy models
Members, classes, payments, attendance, reminders
SQLite
gym.db
APScheduler · daily 09:00
Surfaces due fee reminders, rolls paid ones forward
College apps
Android · Firebase
Admin app
Publishes notices & categorised gallery images
Firebase
Realtime Database + Storage + Auth
Student app
Notices, faculty by department, e-books, gallery
02What I built
- Banking — a layered Spring Boot REST API (controller → service → repository) over MySQL with JPA, exposing create, read, list, deposit, withdraw, and delete for accounts.
- Gym — a Flask application with login and staff/admin roles, members, fitness classes and registrations, payments, attendance devices and check-ins, and automated fee reminders.
- College — two Android apps in Java: an admin app that publishes notices and categorised gallery images, and a student app that reads them alongside faculty by department, e-books (PDFs), and Firebase Authentication.
03Key decisions
- D1
DTOs and a mapper at the API boundary (banking)
The API exchanges AccountDto objects rather than JPA entities, keeping persistence details out of the contract. Withdrawals are rejected when the balance is insufficient.
- D2
Business rules as data events (gym)
An SQLAlchemy after_insert listener creates a member's first fee reminder 30 days after joining, priced by membership tier. A daily APScheduler job at 9 AM surfaces due reminders and rolls paid ones forward.
- D3
One backend, two apps (college)
Splitting publishing (admin app) from reading (student app) keeps write access out of the student client. Both use Firebase Realtime Database and Storage, so new notices appear without a custom server.
- D4
Passwords are hashed, routes are guarded (gym)
Werkzeug password hashing and Flask-Login's login_required protect every management route.
Want to talk through how this was built?