Architecture

Frameworks, Libraries, APIs, etc.

1. Notification Center

Package: Socket.IO is a library that allows real-time communication between web clients and servers. It builds on the WebSocket protocol but adds features like automatic reconnection and support for various transport methods, which helps it work better across different browsers. This makes it easier to implement WebSocket functionality in our Node.js server and connect it to our React frontend.

Protocol: WebSockets enable real-time, two-way communication between the client (our React app) and the server (Node.js backend). Unlike traditional HTTP requests, where the client has to keep asking for new data, WebSockets maintain an open connection. This allows the server to send updates directly to the client whenever new information is available. In our study group matching app, we can use WebSockets for real-time notifications, so when a user gets a new match, message, or study group invite, the server can notify them immediately.

2. Storing different user profiles

Database: PostgreSQL is a robust relational database management system that’s great for handling the structured data our app needs. It can effectively manage tables for users, study groups, user preferences, and matches, allowing us to use relationships through foreign keys and joins. For instance, we can keep user details, study group info, match data, and chat messages in separate tables while maintaining their connections. This setup makes it easier to run complex queries to find the right study group matches or filter users based on specific criteria.

Database Host: Tembo.io is a cloud-hosted PostgreSQL service that manages the infrastructure for us, including automatic backups and replication. This ensures our data is secure and easily accessible. With this managed service, our database can scale as the number of users grows without needing major adjustments. By handling these backend challenges, we can focus on improving the user experience while still benefiting from PostgreSQL’s strong data management and performance.

API: The REST API is essential for linking our React frontend with the Node.js backend and the PostgreSQL database on Tembo.io. It provides a secure and organized way for the frontend to request and interact with the data. For example, it can define endpoints like GET /users to fetch a list of users, POST /matches to create new matches between users and study groups, or PUT /study-groups/:id to update study group details. The API also manages authentication, validation, and data processing on the Node.js server before interacting with the PostgreSQL database, ensuring that only authorized users access certain features and that data is correctly formatted before being stored.

Package/Build Manager

We plan to use npm as our package manager

Deployment

We will deploy our app on either AWS or Heroku for our hosting provider's. AWS are best for high scalability and availability requirements. Heroku supports Docker deployment with its container regirstry and Heroku pipelines for automated CI/CS. Also Heroku is simple and user-friendly. For Automation, we would use Github Action, by triggering the pipeline for the Docker and pushing it into a container and then deploying it.

VMs or Containers

We are going to be using Containers (docker) for deployment as they are simpler to use since it is easier to deploy across various platforms and move our application without worrying about the compatibility or configuration issues. Dockers require lower resources usage and more efficient deployment. The docker also packages all the dependencies and configuration into a single container without worrying about the infrastructure and gives a smooth deployment process.

URLs

These URLs and endpoints together form the core functionality of the app, enabling user registration, profile management, study group interactions, and real-time messaging.

Frontend Pages

WelcomePage (/welcomepage)
The landing page where users can learn about the app, see a brief description, and access the login or signup page.
Create Account (/createaccount)
The page where new users can register for an account by providing their name, email, password, and preferences for study group matching.
Login (/login)
Allows users to log in to their accounts by entering their email and password. Upon successful login, they are redirected to their dashboard.
Profile (/profile)
A page where users can view and edit their profile information, such as their name, preferences, and email.
View Matches (/matches)
Lists available study groups matching based on profile criteria, allowing users to message and discuss joining from this page. It shows the details of the groups, including members, their profiles, and when they would plan on meeting.
Messages (/study-groups/:id/messages)
A chat interface for a specific study group, where users can send and read messages in real-time. It shows the study group's message history and enables communication between members.

API Endpoints

GET /users
Retrieves a list of all users in the system. This endpoint will return user information such as IDs, names, and profiles, which may be used to display a list of potential matches or study group members on the frontend.
POST /users
Creates a new user in the database. The request body will include user details like name, email, password, and profile preferences. This is used when a new user registers for the app.
GET /users/:id
Retrieves details for a specific user by their ID. This is used to fetch a particular user's profile information when viewing or editing their profile.
PUT /users/:id
Updates the information of an existing user based on their ID. The request body may include updated profile details or preferences.
DELETE /users/:id
Deletes a user from the database using their ID. This could be used by an admin or by the user to deactivate their account.
POST /login
Authenticates a user by validating their email and password, returning a token for future authenticated requests. This endpoint is used during the login process to allow users access to their account.
GET /study-groups
Retrieves a list of all study groups available in the system. It may include optional query parameters like subject or availability to filter study groups based on specific criteria, such as finding study groups related to certain topics or those available on certain days.
POST /study-groups
Creates a new study group. The request body will include information such as the subject, description, meeting times, and the list of initial members. This is used when a user creates a new study group.
GET /study-groups/:id
Fetches the details of a specific study group by its ID. This is useful for viewing a study group's profile, including the description, members, and upcoming meetings.
PUT /study-groups/:id
Updates the details of an existing study group. This could include changes to the description, meeting times, or adding new members.
DELETE /study-groups/:id
Deletes a specific study group by its ID. This may be used by a group creator or an admin to remove a study group.
POST /matches
Creates a new match between a user and a study group based on their preferences. This endpoint takes user ID and study group ID as input and stores the match in the database.
GET /matches?userId=123
Retrieves all study groups that a specific user (with ID 123) has been matched with. The query parameter userId helps filter matches based on the user's ID, showing the user their matched groups.
GET /messages/:studyGroupId
Retrieves messages for a particular study group using the studyGroupId. This is used to load the chat history when a user enters a study group's chat room.
POST /messages
Sends a new message to a study group's chat. The request body will include the study group ID, the user ID of the sender, and the message content. This is used for real-time communication within a study group.

Database Schema

1. Users Table

Table Name: users
Description: Stores information about each user in the app.

Attribute	Type	Description
`id`	SERIAL	Unique identifier for each user (Primary Key)
`name`	VARCHAR(100)	User's full name
`email`	VARCHAR(100)	User's email address (Unique)
`password`	VARCHAR(255)	Hashed password for user authentication
`profile_preferences`	JSONB	User's preferences for study groups, stored in JSON format
`created_at`	TIMESTAMP	Date and time when the user was created
`updated_at`	TIMESTAMP	Date and time of the last update to the user profile

2. Study Groups Table

Table Name: study_groups
Description: Contains details about each study group.

Attribute	Type	Description
`id`	SERIAL	Unique identifier for each study group (Primary Key)
`name`	VARCHAR(100)	Name of the study group
`subject`	VARCHAR(100)	Subject area of the study group
`description`	TEXT	Description of the study group
`created_by`	INTEGER	User ID of the creator (Foreign Key)
`created_at`	TIMESTAMP	Date and time when the study group was created
`updated_at`	TIMESTAMP	Date and time of the last update to the study group

3. User Study Groups Table

Table Name: user_study_groups
Description: A join table to represent the many-to-many relationship between users and study groups.

Attribute	Type	Description
`user_id`	INTEGER	ID of the user (Foreign Key)
`study_group_id`	INTEGER	ID of the study group (Foreign Key)
`joined_at`	TIMESTAMP	Date and time when the user joined the group

4. Matches Table

Table Name: matches
Description: Stores information about user-study group matches.

Attribute	Type	Description
`id`	SERIAL	Unique identifier for each match (Primary Key)
`user_id`	INTEGER	ID of the user (Foreign Key)
`study_group_id`	INTEGER	ID of the study group (Foreign Key)
`matched_at`	TIMESTAMP	Date and time when the match was created

5. Messages Table

Table Name: messages
Description: Contains chat messages for study groups.

Attribute	Type	Description
`id`	SERIAL	Unique identifier for each message (Primary Key)
`study_group_id`	INTEGER	ID of the study group (Foreign Key)
`user_id`	INTEGER	ID of the user who sent the message (Foreign Key)
`content`	TEXT	Content of the message
`sent_at`	TIMESTAMP	Date and time when the message was sent

6. Notifications Table

Table Name: notifications
Description: Stores notifications for users about matches, messages, or study group updates.

Attribute	Type	Description
`id`	SERIAL	Unique identifier for each notification (Primary Key)
`user_id`	INTEGER	ID of the user (Foreign Key)
`type`	VARCHAR(50)	Type of notification (e.g., 'match', 'message')
`message`	TEXT	Notification message content
`read`	BOOLEAN	Status indicating if the notification has been read
`created_at`	TIMESTAMP	Date and time when the notification was created

Database Potential Queries

1. Retrieve User Profile

Need to join tables: No
SQL Query Example:
```
SELECT * FROM users WHERE id = $1;
```

2. Matching Users with Study Groups

Need to join tables: Yes

SQL Query Example:

SELECT users.id, users.name, study_groups.name AS group_name
FROM users
JOIN user_study_groups ON users.id = user_study_groups.user_id 
JOIN study_groups ON user_study_groups.study_group_id = study_groups.id;

3. Create New Study Group

Need to join tables: No

SQL Query Example:

INSERT INTO study_groups (name, subject, description, created_by) VALUES ($1, $2, $3, $4);

4. Find Users by Study Preferences

Need to join tables: Yes

SQL Query Example:

SELECT users.id, users.name, users.profile_preferences, study_groups.subject 
FROM users
JOIN user_study_groups ON users.id = user_study_groups.user_id
JOIN study_groups ON user_study_groups.study_group_id = study_groups.id
WHERE study_groups.subject = $1;

Application Type

Our study group matching app, using a Node.js backend and a React frontend, is best suited as a Single Page Application (SPA). React is designed for building SPAs, allowing the app to deliver a smooth user experience by dynamically updating content without the need for page reloads. This is particularly beneficial for a people-matching app, where users might browse, filter, and connect with others frequently. Meanwhile, the Node.js backend can handle serving the initial HTML and provide API routes that the React frontend can consume. This setup creates a clear separation of concerns: the backend manages the data and logic, while the frontend handles the user interface and dynamic updates. The SPA model not only ensures a responsive and interactive user experience but also offers the flexibility to incorporate real-time features, like notifications. Additionally, this structure supports scalability, making it easier to expand the backend logic as the app grows without tightly coupling it to the front end.

Views

The Views of your app. Embed the images from your Design Milestone. Home_Page_View-2

LearnLink Icon: The icon of our web app.
Welcome Page Text: A welcome description the user sees when they first get to the welcome page.
Get Started Button: User can click on the set started button to navigate to the login or signup page.
Study Groups Button: User can immediately navigate to study group they currently are apart of to communicate with them or beginning creating the study group of their choice
Study Resources Button: User can navigate to the study resources page and find links helpful to their course or book a study room.
Messaging Button: User can navigate message page and communicate with the other user in 2p2 conversation or have a group chat with multiple of users.
Grade Calculator Button: User can navigate to grade calculator page and see their scores, average they have have in the class and need in order to pass the course, and also graphs based on their average.
Copyright: Our app is copyrighted, so no one can claim it as their app.

What Each Person Will Work On

Team Role Assignments -- subject to change as time goes on and new features are desired