2.[Easy/Hard](## What you thought would be hard but was easy, and what you thought would be easy but turned out hard?)
3.[Proudest Thing](## Proudest Thing)
4.[Improvements](## Things can improve if we have more time)
5.[Pain Points](## Pain Points)
6.[Value of Design](## Value of Design - Code - Refactor)
2.[System Design](## System Design)
3.[Easy/Hard](## What you thought would be hard but was easy, and what you thought would be easy but turned out hard?)
4.[Proudest Thing](## Proudest Thing)
5.[Improvements](## Things can improve if we have more time)
6.[Pain Points](## Pain Points)
7.[Value of Design](## Value of Design - Code - Refactor)
## Usage
...
...
@@ -39,7 +39,15 @@ npm install --save bootstrap
Then run `npm start`, will automatically open browser in `localhost: 3000`.
## What you thought would be hard but was easy, and what you thought would be easy but turned out hard?
## System Design
At high level architecture, the auction system is separated into two modules - frontend and backend which communicate RESTfully using JSON over HTTP. Messages from the Frontend are mapped by Controller Tier Class depending on a route path (e.g. /item) which then calls a method in Service Tier to handle all business logics. The Service tier then calls Repository Tier Classes which interact and perform CRUD operation with the database. Frontend and Backend also communicate using WebSocket for real time price update - users can see price changes without having to refresh the browser.
The system is developed based on Spring Boot framework which provides all common resources and dependencies for Web Application. We utilized Java Persistent API (JPA) to map Object-Oriented Entities (e.g. user, item) with the relational database. JPA also handles all CRUD operations without having us to write SQL queries. The framework also provides embedded Tomcat web server and embedded H2 SQL database which are convenient during development - the system will use either MySQL or PostgreSQL for the production.
Since these method calls and communicating with JSON over HTTP are lightweight and expected to handle hundreds of clients currently, we chose not to use asynchronous messaging tool such as RabbitMQ. Although, if required, we can put in place an asynchronous messaging between Frontend and Backend to handle more concurrent requests in the future.
## What you thought would be hard but was easy, and what you thought would be easy but turned out hard?
Realtime bidding seemed hard in the beginning as none of us has any experience in large-scale web service, let alone realtime communication and concurrencies. It turned out that, by using a websocket, server-client interaction can be largely simplified as exposing port to clients, handshaking, and exchanging messages.
