FitForYou is a modular fitness application designed for personal trainer and client use. Trainers can create individualised workout routines, while clients can log their completed sessions. The system is to be built using a service based architecture and is containerised using Docker and Docker compose. The application will prioritise modularity, deployability, and interoperability as fey factors in project success.
Name: Cooper Blackburn
Student number: 46935913
Workouts will be structured collections of exercises with a defined schema that allows for detailed tracking. Clients log actual performance per exercise, which is stored as immutable records in the client database. A unified frontend will be developed using Flask templates and originates from it’s own container. This frontend will serve as the entry point for both trainers and clients. It will interact with the backend services by sending API requests and displaying data such as performance logs, workout plans and user dashboards. This will be catered to whether a trainer or client is using the frontend. To determine which user (id and type: trainer or client), a simple mock login system will be integrated for users to access by providing a hardcoded ID .
The system will consist of three services:
Each service will be deployed in its own container and will communicate via API. Databases will also separate per service, simulating a microservice architecture to ensure low coupling and clear data ownership. Communication between services will occur via HTTP APIs defined within the Docker network using docker-compose, simulating a microservice-style deployment. This approach ensures clear domain boundaries and allows independent development and scaling of services
FitForYou will use Docker and Docker Compose to fully containerise each component of the system. The services and their corresponding databases will be defined in a single docker-compose.yml file, allowing the application to be deployed with a single command across any machine. Service dependencies, environment set up, and networking are encapsulated in this configuration, ensuring consistent behaviour regardless of host platform. The system avoids manual installation, significantly increasing deployability.
The system follows a service-based architecture, where each service is responsible for a single domain of functionality. The trainer service owns, manages and assigns workouts, while the client service owns client data and workout performance logs. This modular structure is reinforced through the use of Flask Blueprints, which allow separation between different services routes and logic. Each service will have its own data models and internal structure, and the services will only interact through API’s. This approach increases modularity, as maintaining different elements of the project can be conducted without refactoring the whole codebase.
The system is designed to support clean communication between services via HTTP-based APIs. The client service interacts with the trainer service to fetch assigned workouts, and the trainer service queries the client service to access workout logs. This approach supports interoperability as independently deployed services interact meaningfully through standardised interfaces. No shared databases or direct data access is required. This ensure that each service’s data remains encapsulated, and only necessary data is exchanged through controlled interfaces.
The success of the system will be evaluated against its intended architectural goals and functionality. API endpoints will be validated using HTTP clients and automated test cases to ensure correct behaviours across system work flow, including client workout retrieval, workout logging, and trainer querying logs. Successful deployment using Docker Compose across different machines will demonstrate Deployability. Interoperability will be demonstrated through inter-service API calls that fethc and display data correctly from other services. Modularity will be validated through code structure, database separation, and service independence. The frontend service will serve as the user interface and tested through simulating trainer and client login scenarios using mock IDs. Any additional features such as optional progress graphs will be considered in terms of how easily they could be added within the existing architecture, providing a reflection on future extensibility. Overal, the evaluation will focus on how well the system follows principles of clean architecture, modular separation, and effective inter-service collaboration.