Software design of a cognitive training web application

For the past few months, my team and I, at the Dementia Research Centre, Singapore has been working on a lifestyle application for the elderly called RevitalAIze with the goal of enhancing long-term cognition. Our web application covered over 20 cognitive games—alongside a food diary, health tracking, and wearables integration.

Tech Stack Overview

• React
• FastAPI
• PostgreSQL

Frontend Architecture

We focused on building well encapsulated components with a strong emphasis on separation of concerns. Component definition and design was done with reusability in mind. These principles kept our architecture more maintainable and modular.

Our core react application acts as the control centre for displaying main user workflows like authentication, daily todo, games and health tracking, all of which are separate pages.

Cognitive games were decoupled entirely and are displayed within an iframe allowing for independent development and performance isolation. Communication between the core app shell and game iframes are standardized using an internally designed robust messaging toolkit called FrameBridge.

Several parts of game development were standardized including lifecycle management, asset loading, data management and result tracking, through which a specialized GameEngine SDK was created. Lifecycle management is shown in Figure x. This SDK acted as the backbone of each cognitive game, leaving enough room for separate game logic and UI.

Lastly, the data service layer lies behind both the game engine SDK and other user workflow pages which abstracts all API communications with the backend and standardizes the data formats between APIs and component props.

Backend Architecture

At the outset, we have a Uvicorn ASGI web server which interacts with external systems. Internally, the web server interfaces with routers which are structured into domain specific features like games, health tracking, user management, etc. This organisation embodies the Single Responsibility Principle (SRP), where each part is responsible for only one part of the functionality.

Behind the routers, the service layer encapsulates business logic and CRUD operations. Services depend on abstractions using FastAPI’s native Dependency Injection system for better testing and flexibility. Additionally, CRUD operations are also organized by domain specific features similar to routers further subdivided into data access logic and business logic.

Next, we use Pydantic Schemas to ensure data validation and serialization between Service Layer and ORM models layer for our database.

Following tasks have been centralized across the system into feature specific components:

• Logging - Using Python’s logging module, we have implemented a fairly comprehensive multi-level logging system (INFO, ERROR, etc.) which supports JSON formatting, per module granularity.
• Rate Limiting - Using SlowAPI’s middleware, we have implemented IP-based rate limiting to protect sensitive endpoints like login and game results.
• Background Task Queue - We used FastAPI’s BackgroundTasks library to manage time consuming processes like sending emails and report generation.
• Authentication - Using OAuth2 to handle password flow and cryptographic hashing along with Dependency Injection in secure endpoints.
• Configuration - Using Pydantic’s BaseSettings, we facilitate robust configuration & secrets management.

In the next part of this blog, I will cover the deployment techniques used for this application.