PassTheTest.com is a cloud-based e-commerce platform designed to address the time
constraints faced by Engineering & Computer Science (ECS) students. The website offers
downloadable study guides, both free and premium versions, to help students reduce stress and
focus on their studies. The platform aims to increase accessibility by offering diverse content
and supporting multiple payment methods.
The platform will initially focus on Computer Science study guides, with plans to expand into
other subjects like Statistics. PassTheTest.com ensures that users can make secure payments,
access study materials instantly, and manage their accounts via a simple and user-friendly
interface. The premium guides will include answers to exercises, ratings, and works cited, while
free guides will provide basic study content.
Project Goals:
· Provide stress-free study solutions for ECS students.
· Ensure seamless, secure payment processing and account management.
· Continuously expand the platform's academic content offering.
· Deliver high-quality study guides through an easy-to-use interface.
Prototype Method and Environment
Cloud-Based Application:
We are building a cloud-hosted e-commerce platform that users can access via the web.
The cloud hosting provider chosen for this project is Vercel, which integrates well with
our stack, specifically Next.js and GitHub. This ensures continuous deployment with
every commit and simplifies the development workflow.
Technology Stack:
Frontend and Backend:
We are using Next.js, a React-based full-stack framework, for building the user interface
(UI) and managing server-side rendering (SSR) or processing logic. The framework is
ideal for this e-commerce platform as it allows quick, dynamic page loading and
improves SEO, which is crucial for attracting students via search engines.
To style the UI, we are leveraging Tailwind CSS, which provides flexibility in creating
responsive, modern designs quickly, adhering to mobile-first principles.
Database:
The database we are using is MongoDB (SQL Version) for its user and product
management. This SQL database is well-suited for scalability as the platform grows,
ensuring efficient data storage and retrieval. To query the database, we use Prisma, an
ORM to retrieve the data from the database in a more structured way. Abstracting SQL
queries into a JavaScript-friendly syntax for improved type safety and ease of use.
We are using Next.js which runs on Node.js to handle server-side requests, manage the
processing of data, and interface with our database. This choice enables fast I/O and
real-time handling of user requests, which is especially critical when dealing with user
authentication and payments.
Authentication:
Auth0 will handle user authentication for logging in and creating accounts. This service
integrates seamlessly with Next.js and offers advanced security features like multifactor
authentication (MFA) and social logins (Google, Facebook, etc.), although MFA will not
be implemented at the prototype stage.
Payment Processor:
Stripe will manage payments. It is a widely used, secure API solution for handling credit
card payments. In our next iteration, we’ll implement the basic payment flow, ensuring
the user is redirected to Stripe's secure portal, with confirmation and payment
processing handled on our backend.
Version Control:
We will use GitHub as our code repository, tracking all changes and providing an audit
trail of the development process. This allows the team to collaborate efficiently through
pull requests, branch management, and code reviews. GitHub’s integration with Vercel
ensures the automatic deployment to the production of the reviewed code..
Methodology
We will use Agile with Scrum as a framework to delegate work and progress.
We will have 6 day long sprints and a team reflection on Friday detailing how we can improve
for the next sprint. Our goal is to have working software every day.
Tools
We will use JIRA for the project timeline, to see if we are hitting the milestones or see where
people are struggling.
GitHub will be used as a Cloud Repository with Issue Tracking and explicit documentation for
our weekly improvement process.
Vercel will be our cloud hosting provider since we can integrate with GitHub to deploy our
service to the web.
NextJS will be our full-stack framework and will be using libraries such as Tailwind to style our
components.
MongoDB will be our Database to store our information and manage the Authentication of the
Users. We will be using the SQL Version of MongoDB so we can
Requirement Analysis
The software will have to host and manage the distribution of these ECS Study Guides. The
website has a free and paid tier version and will have to take credit card information. The
following Frontend UI Mockups, Use Case Diagram, and Software Architecture Diagrams, will
be used to describe the functionality that the software will accomplish from a normal user’s
perspective.
Software Architecture Diagram
Vercel is an AWS wrapper to extend the capabilities and make it easier to use with other
frameworks like NextJS and other cloud providers. Prisma will be used to interface with the
cloud database and we will be using Auth0 as the NextJS Authentication suite. Stripe will be the
payment processor for the study guides and will be redirected back to the AWS Server for
further processing.
Client (Browser)
Connection coming from the user utilizing a web browser
Frontend Layer (Public Access)
This represents the part of the website that is accessible to all users without login, such
as browsing study guides or viewing comments.
Auth0 (Authentication Layer)
Auth0 only comes into play when the user wants to access protected content (e.g.,
logging into their account, making a purchase, seeing already bought study guides, or
commenting).
Protected Frontend (Logged-in State)
After the user logs in via Auth0, they return to the application. This represents the part of
the website that’s accessible only after the user logs in (e.g., viewing account info, and
accessing purchased guides).
Backend (Next.js)
This handles data requests, responses, and data processing for both logged-in and
non-logged-in users (e.g., fetching user data, and managing purchases).
Database (MongoDB)
Stores user information, product data, authentication tokens, and purchasing
information. Obtained by the use of queries performed by the backend layer.
Stripe (Payment Processing)
Third-party software that helps with the processing and verification of transactions. It
communicates with both the backend and the database to provide a customer payment
status.
Design Patterns
The Observer Pattern is necessary to update the users when publishing a new study guide.
Therefore, we can have the user’s subscribe to the memos or updates on selected study
guides, since there may be an update on the answers or a particular question.
11 Week Project Timeline
Week 0 - Project Idea - Completed
Week 1 - Set up Environments - Completed
Week 2 - Learn how to Use Development Environments - Completed
Week 3 - Deploy a Mockup of the Website to Cloud - Completed
Week 4 - Set-up Automated Testing - Completed
Week 5 - Configure Database - Completed
Week 6 - Design Frontend
Week 7 - Finish Authentication
Week 8 - Finish including Payment Processor
Week 9 - Finish User, Accountant, Admin
Week 10 - Finish Frontend Dashboards
Week 11 - Presentation Practice
Database Requirements
Persistent Data:
The website stores user profiles, study guides, transactions, and subscription details for
notifications.
Data types:
User Data: User profiles, account creation dates, and payment information
Study Guides Data: Guide titles, types (free or premium), description and prices
Transaction Data: Details of Payments, including the amount and purchase date
Subscription Data: Details for users who subscribe to updates for specific
guides.
Relational Database Design:
Tables and fields
Users Collection
user_id: (Primary key) Unique identifier for each user
name: Full name of the user
email: User’s email (unique, used for authentication)
password: Encrypted password for login
created_at: Date and time the user registered
Product Collection
product_id: (Primary Key) Unique identifier for each study guide
title: Title of the study guide
description: Description of the guide content
price: Price of the guide (0 for free content)
created_at: Date the guide was added to the platform
sale: the discounted price of the product
Transactions Collection
transaction_id: (Primary Key) Unique identifier for each transaction
user_id: (Foreign Key) References user_id in User Tables
product_id: (Foreign Key) References product_id in Products Table
amount: Amount paid by the user
transaction_date: Date and time of the transaction
Subscriptions Collection:
subscription_id: (Primary Key) Unique identifier for each subscription
user_id: (Foreign Key) Reference user_id in User Table
product_id: (Foreign Key) References product_id in Products table
notifications_preference: User’s preference for receiving updates (Optional)
Database Entity Relationship Diagram
Products Collection
No-SQL Database Representation
Sample MongoDB Collections using JSON
We chose MongoDB, a Cloud Provided Database as a Service solution, because it supports
easy scalability and flexibility with authentication and customer transactions. With NoSQL, we
can query and filter documents easily for the Backend and Frontend to use. Products will be
perfect in a NoSQL table, since it can carry optional fields such as sale, so if the sale is present
in the JSON, the frontend will be able to distinguish something from its normal price.
Mongodb Database Implementation
Setup database and various collections:
Setup the Users collection with sample data to establish a guide when adding real user data.
Here users have an embedded address allowing for faster queries.
Users Collection: Transactions Collection:
Testing
This week we decided to create automated deployment testing for every development branch
whenever code is uploaded to GitHub. We also wanted to test the database’s connection to the
backend, which means basic CRUD operations, this week we wanted to update and request
collections from MongoDB. On top of the CRUD operations, we wanted to test the
authentication feature of NextAuth by being able to sign in with a Google or GitHub Account.
In the case of Automated Deployment Testing for Continuous Integration Testing, the
precondition is to set up an “On Push” event listener to every development branch on our
GitHub project. Therefore, the post condition is to deploy the branch in a development
environment and return the build status after the linting and strict type checks.
To achieve this the pull request action will fire a staging environment to Vercel. Knowing
that we coded strict linting and type checking, we want to make sure the build works
properly when deployed to the cloud.
The results were successful. Vercel makes it easy for us to stage environments for every
development branch. This is useful to both approve changes without affecting the
production environment.
No further updates with this test is required since the development branch either deploys
or it doesn't.
Attached is a screenshot of a pull request test that was successful.
To send and update data to MongoDB, we implemented a Post Request API Call to the
backend so that we can send data to the database. The precondition is setting up a
button to send a POST and GET Request stating that the button was pressed an “X”
number of times.
To achieve this we had to connect the database to the backend and link the POST API
to an ORM so that we can easily interface with the database.
The results were not so successful, since the POST API call still have bugs so the
backend was unable to update the database with the proper changes resulting in the get
request to display this error message to the user.
Further testing is required to make sure that we are properly performing CRUD
operations on the database.
To test authentication with MongoDB, we are implementing a protected API call. You can
only call this API whenever you are properly authenticated. So the precondition is the
authenticated state.
To achieve this we had to set up MongoDB with proper database fields to handle
Authentication. So we had to create Session, User, and Verification Token Collections
with fields: email, createdAt, emailVerified, sessionID, sessionToken, sessionExpiration,
and TokenVerificaiton.
This is not so successful yet, because we have yet to properly setup an API callback on
Google Cloud Platform and GitHub Authentication Suite.
Further testing is required to see if the protected API Call is properly implemented and if
the authentication state persists.
Research
I believe we can integrate some automated unit testing for every CRUD operation. From further
research there is this project called the OpenCTI Platform that is trying to create generic unit
tests for API calls and comparing the results with proper outcomes. This can be used by
integrating OpenCTI Platform with GitHub Actions.
Prototype Reflection
Frontend:
As more progress has been made in the prototype, progress and a vision for the front end is
beginning to come together. Additional attention has been recently placed on where the front
end programmers should be making adjustments and how those changes should be
implemented. As many of the previous challenges concerning the front end have been
addressed, and the timeframe for the project is shortening, new and greater changes will be
implemented.
Backend:
As the team continues to implement their contributions to the front end and database
layers, some areas that previously did not impose any interest/concerns have now called our
attention as they imply a newfound delay in our process. The integration of the backend with the
database has resulted in quite a challenge, causing a delay in the implementation of other
essential functionalities like payment methods and data queries. We continue to work in those
challenges and bring improvements every cycle.
Database:
This iteration focused on creating the database and establishing patterns for later data entry.
Challenges of this iteration included setting up Mongodb and learning how SQL terms and
concepts are applied in a NO-SQL format. Concepts such as joins can be replaced by
embedding data in Mongodb.
Project Management:
With this iteration, we were able to query the database within the terminal and have successfully
connected the database to the backend. This is a good leap since we have successfully created
our schema for the project. The next challenge is trying to make the CRUD API Calls the
database in NextJS. We plan on wringing the details out this coming week to create the API
Calls and finally set up the frontend.
PassTheTest.com E-commerceWebsite
Group Members and Roles:
ーTam Vo (Project Manager and Team Leader) ーJuan Campos (Full Stack Developer) ーAaron (Frontend Developer) ーBret Semkiw (Frontend Developer) ーJennifer Taylor (Backend Developer)
Course:
CSC 131 - Professor A. Abdel Khaleq.
Github
https://github.com/tamkhaivo/CSC131_WebProject Project Title: PassTheTest.com - E-commerce Website for ECS Study Guides
Summary:
PassTheTest.com is a cloud-based e-commerce platform designed to address the time constraints faced by Engineering & Computer Science (ECS) students. The website offers downloadable study guides, both free and premium versions, to help students reduce stress and focus on their studies. The platform aims to increase accessibility by offering diverse content and supporting multiple payment methods. The platform will initially focus on Computer Science study guides, with plans to expand into other subjects like Statistics. PassTheTest.com ensures that users can make secure payments, access study materials instantly, and manage their accounts via a simple and user-friendly interface. The premium guides will include answers to exercises, ratings, and works cited, while free guides will provide basic study content.
Project Goals:
· Provide stress-free study solutions for ECS students. · Ensure seamless, secure payment processing and account management. · Continuously expand the platform's academic content offering. · Deliver high-quality study guides through an easy-to-use interface.
Prototype Method and Environment
Cloud-Based Application: We are building a cloud-hosted e-commerce platform that users can access via the web. The cloud hosting provider chosen for this project is Vercel, which integrates well with our stack, specifically Next.js and GitHub. This ensures continuous deployment with every commit and simplifies the development workflow.
Methodology
We will use Agile with Scrum as a framework to delegate work and progress. We will have 6 day long sprints and a team reflection on Friday detailing how we can improve for the next sprint. Our goal is to have working software every day. Tools We will use JIRA for the project timeline, to see if we are hitting the milestones or see where people are struggling. GitHub will be used as a Cloud Repository with Issue Tracking and explicit documentation for our weekly improvement process. Vercel will be our cloud hosting provider since we can integrate with GitHub to deploy our service to the web. NextJS will be our full-stack framework and will be using libraries such as Tailwind to style our components. MongoDB will be our Database to store our information and manage the Authentication of the Users. We will be using the SQL Version of MongoDB so we can Requirement Analysis The software will have to host and manage the distribution of these ECS Study Guides. The website has a free and paid tier version and will have to take credit card information. The following Frontend UI Mockups, Use Case Diagram, and Software Architecture Diagrams, will be used to describe the functionality that the software will accomplish from a normal user’s perspective.
Software Architecture Diagram
Vercel is an AWS wrapper to extend the capabilities and make it easier to use with other frameworks like NextJS and other cloud providers. Prisma will be used to interface with the cloud database and we will be using Auth0 as the NextJS Authentication suite. Stripe will be the payment processor for the study guides and will be redirected back to the AWS Server for further processing. Client (Browser)
Design Patterns
The Observer Pattern is necessary to update the users when publishing a new study guide. Therefore, we can have the user’s subscribe to the memos or updates on selected study guides, since there may be an update on the answers or a particular question.
11 Week Project Timeline
Week 0 - Project Idea - Completed Week 1 - Set up Environments - Completed Week 2 - Learn how to Use Development Environments - Completed Week 3 - Deploy a Mockup of the Website to Cloud - Completed Week 4 - Set-up Automated Testing - Completed Week 5 - Configure Database - Completed Week 6 - Design Frontend Week 7 - Finish Authentication Week 8 - Finish including Payment Processor Week 9 - Finish User, Accountant, Admin Week 10 - Finish Frontend Dashboards Week 11 - Presentation Practice
Database Requirements
Persistent Data:
Relational Database Design:
Tables and fields
Database Entity Relationship Diagram
Products Collection No-SQL Database Representation Sample MongoDB Collections using JSON
Database Tool Selection
We chose MongoDB, a Cloud Provided Database as a Service solution, because it supports easy scalability and flexibility with authentication and customer transactions. With NoSQL, we can query and filter documents easily for the Backend and Frontend to use. Products will be perfect in a NoSQL table, since it can carry optional fields such as sale, so if the sale is present in the JSON, the frontend will be able to distinguish something from its normal price. Mongodb Database Implementation Setup database and various collections: Setup the Users collection with sample data to establish a guide when adding real user data. Here users have an embedded address allowing for faster queries. Users Collection: Transactions Collection:
Testing
This week we decided to create automated deployment testing for every development branch whenever code is uploaded to GitHub. We also wanted to test the database’s connection to the backend, which means basic CRUD operations, this week we wanted to update and request collections from MongoDB. On top of the CRUD operations, we wanted to test the authentication feature of NextAuth by being able to sign in with a Google or GitHub Account.
Research
I believe we can integrate some automated unit testing for every CRUD operation. From further research there is this project called the OpenCTI Platform that is trying to create generic unit tests for API calls and comparing the results with proper outcomes. This can be used by integrating OpenCTI Platform with GitHub Actions. Prototype Reflection
Frontend:
As more progress has been made in the prototype, progress and a vision for the front end is beginning to come together. Additional attention has been recently placed on where the front end programmers should be making adjustments and how those changes should be implemented. As many of the previous challenges concerning the front end have been addressed, and the timeframe for the project is shortening, new and greater changes will be implemented.
Backend:
As the team continues to implement their contributions to the front end and database layers, some areas that previously did not impose any interest/concerns have now called our attention as they imply a newfound delay in our process. The integration of the backend with the database has resulted in quite a challenge, causing a delay in the implementation of other essential functionalities like payment methods and data queries. We continue to work in those challenges and bring improvements every cycle.
Database:
This iteration focused on creating the database and establishing patterns for later data entry. Challenges of this iteration included setting up Mongodb and learning how SQL terms and concepts are applied in a NO-SQL format. Concepts such as joins can be replaced by embedding data in Mongodb.
Project Management:
With this iteration, we were able to query the database within the terminal and have successfully connected the database to the backend. This is a good leap since we have successfully created our schema for the project. The next challenge is trying to make the CRUD API Calls the database in NextJS. We plan on wringing the details out this coming week to create the API Calls and finally set up the frontend.
CSC 131 - Group Project - Project Database.pdf