A simulated marketplace for Ottawa-based sellers and buyers

1. Overview
2. Database
   • 2.1 ER Diagram
   • 2.2 Database Design
     • 2.2.1 Products vs Reviews vs Orders
     • 2.2.2 Product ID vs Product
3. Express API
   • 3.1 Architecture Diagram
   • 3.2 API Design

• NodeJS and ExpressJS:
  • Our frontend is primarily Javascript-based and as a result, I chose to use NodeJS as our backend framework so that I and future developers can seamlessly work full stack
• MongoDB and Mongoose:
  • In another context we may have chosen a SQL database but we are currently looking for speed of development and so we went with NoSQL. As we are opting for speed of development we opted to couple Mongoose with MongoDB. Another option we considered was Firebase / Firestore but chose MongoDB because it would be more high-performant as we scale.

• I had originally nested reviews under products because all functionality was associated with one another but realized that it may be harder to decouple logic later down the road if I follow this design.
• For example, if i nested orders under products i would have to loop through each product to retrieve all the orders in our backend

• I also wanted to point your attention to the orders table where you can see we are only storing product IDs instead of the entire product object. With this design I wanted to reduce duplication in our database, and so by only storing the ID we wouldn’t have to replicate data by storing the entire product as well.
• That being said, there are some tradeoffs with this approach because if we had nested the entire product then we would be able to access the product objects right away whereas currently I have to make an API call for every product that is stored

• Instead of having everything in 1 giant API file I decoupled the backend logic so that there is a clear separation of concerns.

You can see that all HTTP requests are directed first to Routes, which contain the base object URLs such as /Products , /Reviews , /Orders

Afterwards, they are brought to the controllers which connect the specific HTTP URL to the business logic and services

The services hold all the actual functionality and business logic of the backend. In the future, we would implement a database access layer so the logic is further decoupled. For now the services directly communicate with the database.