Repository for CSC 510 Software Engineering project 2, created by Group 14: Mithil Dani, Neha Kale, Rishikesh Yelne, Ritwik Vaidya, Vansh Mehta and Pradyumna Khawas

Click on the image below to view the demo video of the project

Demo Video of Improved Project:

Want to sell something you own in a bidding war? Want to snatch something you really want? Congratulations, you have come to the perfect place: the Auction Sphere

Auction Sphere is an auctioning system where people can bid on exciting items and also put items up for sale. Every item has a bidding window, and the item goes to the highest bidder by the end of that window.

On the products page, people can view all the latest items being put up for sale and their respective highest bids. On the product details page, apart from product details, people can view the latest bids as well as the highest bid, and can also place a bid. It's upto the seller to decide the minimum price of the product, as well as bid increments.

React.js
JavaScript
Flask
Python
PostgreSQL

The docs folder incorporates all necessary documents and documentation in our project.

Code formatter: Prettier

Tech stack: React.js, Flask, PostgreSQL

You will need Node.js and NPM installed. You can refer this article if not installed already: https://kinsta.com/blog/how-to-install-node-js/ First, navigate to our application on the terminal and install all the packages using npm i In case this throws any error, install the yarn package manager: npm install --global yarn And then to install all the packages, run yarn Now, to run our application, run npm start

To run code coverage, just do: yarn coverage This will not only give you a detailed report on your terminal, but will also generate a .html file for the reporrt as seen here in our project: https://github.com/kartikson1/Auction-Sphere/blob/main/coverage/lcov-report/index.html

We have a lot planned for the future! Completed tasks and future enhancements can be found here

We have focused on multiple aspects to improve the project, following are few aspects which we have enhanced:

In the first phase of the project, the products were listed on the webpage by fetching all available products in the database. This is not a scalable option. If we add about 10000 products in the database, the performance of the application will be drastically affected. Following is the screenshot of the network and memory tabs of the browser while loading 10000 records form the database:

The API endpoint requires ~35 seconds to fetch all records and the size of the packet is over 1Mb.

Browser Memory Consumption:

The Fix : Pagination

We have implemented a paginated endpoint to fetch only 10 records at a time and the user can traverse through the pages using a pagination component. This drastically reduces the loading time of the page and also requires lower packet size to be transferred over the network.

Following is the screenshot of the network and memory tabs of the browser while loading 10000 records form the database:

With the paginated API endpoint, it requires only 114ms to fetch 10 records and the size of the packet is a mere 2.5kB.

Browser Memory Consumption:

In comparison, following are the improvement metrics in terms of Performance:

We have used REDIS cache to improve the performance of API endpoints like fetching images of the products and to fetch the initial price of the product while creating a bid. These data are not subject to major updates and whenever the image or the base price of a product is updated, we also update the cache configuration if present.

REDIS cache drastically reduces the latency of network calls. For example, if we compare the time taken to load the images of products on the browser's network tab:

1. Before Caching

To fetch the image for a product, the API takes ~500ms as seen above in the network tab.

The time taken for the product does not improve on subsequent calls and hence has a lower performance overall.

2. After Caching

As seen in the above image, all subsequent calls take ~75ms on an average to fetch the product's image from cache.

This is a significant improvement in performance and can be evaluated as follows:

Monolithic applications: All applications have multiple fucntionalities that we implement for various features according to the requirements of the project. If we put up all the fucntionalities of this application in a single codebase, such type of applications are known as monolithic application. For the previous design, project was a monolithic design with all the features in one single codebase.

Microservice applications: It is a method of development in which the system is broken down into smaller units that each handle a specified amount of functionality and data while interacting directly with one another using simple protocols like HTTP. We have changed from monolithic to microservices, we have separated the user and product services. The user microservice has all the user functionalities of login, signup and the product microservice has all the product functionalities such as creating the products, biding for the products, selling products.

Disadvantages of Monolithic Application: For all the smallest changes we have to deploy everything. It is difficult to manage. We are required to deploy every instance of the application to multiple servers if any single unit of the system faces heavy traffic. Deployment time is very large. Not relaible. To adapt to a new tech stack it will be difficult.

Advantages of using two microservices over the previous monolithic service: Microservices are scalable. Very reliable. Easy to manage. We only deploy a particular servie that has been changed. Services are independent. If any service fails, it won't affect all the remaining services. Each service can have its own tech stack.

• SQLite3 is not scalable and only works well with small databases.

• SQLite3 is serverless and runs within the app.

• SQLite - five types: Null, Text, Blob, Integer, Real.

• No user management with more simultaneous access.

• SQLite3 is fast for simple operations.

• SQLite3 is not fully ACID compliant.

• PostgreSQL works better with bigger databases and machines and has vertical scalability.

• PostgreSQL is a client-server model where we have a separate DB server.

• PostgreSQL supports every type.

• Handles many users very well with proper permissions.

• When many complex queries are present, PostgreSQL works very well.

• PostgreSQL is ACID compliant. (Atomicity, COnsistency, Isolation, Durability).

The earlier version of software used raw string queries even in the signup flow. This made the system vulnerable to an SQL Injection attack as demonstrated in the video below.

This can be easily mitigated by using an ORM model to wrap the queries before it gets executed. This makes SQL injection impossible.

Mithil Dani

Neha Kale

Rishikesh Yelne

Ritwik Vaidya

Vansh Mehta

Pradyumna Khawas