Skip to main content
Our application is structured using a 3-layer architecture, two of which are enveloped by our web application. This structure provides flexible development and easier building through technologies such as React and TypeScript. We chose this structure to ensure a smooth transition during project turnover, allowing future teams to easily understand the design and layer separation. The static and dynamic architectures outlined below further explore the interactions within our system.

​
Rationale

Our architecture was planned to efficiently build a dynamic application. By maintaining a clear separation between different architectural levels, we effectively outlined the tasks and processes each section would manage during runtime. We utilize Google Sign-On via OAuth 2.0 for user authentication. This approach leverages Google’s robust security infrastructure, including multi-factor authentication. As a result, we do not store sensitive password information, reducing vulnerabilities related to password reuse and database breaches.

​
Static Architecture

Our static system architecture was designed to develop a responsive interface and an efficient full-stack web application. We clearly delineate between the front-end, back-end, and database layers to represent their interactions. Figure 1.1 - Static System Diagram\ Static System Diagram

​
Key Components:

  • Web Application: The central part of our system, encompassing both front-end and back-end processes.
  • Frontend (User Interaction Layer): Built using React, TypeScript, and HTML, ensuring an intuitive and seamless desktop application.
  • Backend (Business Logic Layer):
    • Uses Node.js to handle server-side logic.
    • Interacts with the database to store user information.
    • Executes the optimization algorithm to manage carpool groupings and update the frontend accordingly.
  • Database Layer:
    • Uses MongoDB to store and track user profiles, carpool organizations, and group data.
    • Maintains persistent storage and updates user data dynamically.

​
Dynamic Architecture

Our dynamic system architecture represents a real-world user scenario for creating and managing a Carpool Group. A system sequence diagram illustrates how different components interact to create a seamless user experience. Figure 1.2 - Dynamic System Diagram Dynamic System Diagram

​
User Scenario: Carpool Group Creation

  1. User initiates group creation:
    • The User Interaction layer presents the interface for front-end interactions.
    • The backend components are prepared for handling user requests.
  2. User requests to view or create a carpool:
    • The frontend collects user input and forwards it to the backend.
    • The backend retrieves user data and carpool information from the database.
  3. Data retrieval & optimization:
    • The Business Logic layer fetches data from the database.
    • The backend queries stored carpools and members, executing optimization algorithms to sort users into driving groups.
  4. Interface update:
    • Once the backend processes the request, data is returned to the frontend.
    • The User Interaction layer updates the interface with the latest carpool group details.
  5. Database maintenance:
    • The MongoDB database continuously stores and updates user data.
    • It fetches and returns information such as location and availability for all carpool members, ensuring the optimizer functions effectively.
This structured system ensures scalability, efficiency, and security, creating a smooth user experience for managing carpooling logistics.