Magic Potion Launch Site

Revolutionizing the skincare industry!
Explore the docs »

View Demo · Report Bug · Request Feature

Table of Contents

• About the Project
  • Built With
• Getting Started
  • Prerequisites
  • Installation
• Data Schema
• Scaling
• Front End
• API Architecture
• What Would You Do Differently?
• Improve or Scale the Application

About The Project

View Demo: Interactive 3D Product Viewing with Add to Cart

Form Validations

Built With

• ReactJS: A JavaScript library for building user interfaces.
• Material-UI: A React UI framework.
• NodeJS: A JavaScript library for server-side applications.
• Express: A NodeJS framework.
• PostgreSQL: An open source object-relational database.
• Sequelize: An ORM(Object Relational Mapping) of PostreSQL

Getting Started

Prerequisites

• npm

npm install npm@latest -g

Installation

For /Client Folder:

1. Clone the repo

git clone https://github.com/kiumwong/curology-challenge.git

2. Install NPM packages

npm install

3. Run the application

npm run dev

4. Access the application

Access http://localhost:3000/

For /Server Folder:

1. Install NPM packages

npm install

2. Run the application

npm run dev

3. Access from Local Server

Access http://localhost:5678/api/v1/magic

4. Provide database credentials

Provide database credentials under config/config.js

Data Schema

Existing data schema represents transactional "orderItems" placed by a "userID" given a specific "productID which results in a "transactionID". For simplicity, I treated it as transactional data. However in a real life scenario, I would break and map the relationship as follows:

Scaling

Scaling comes at a price. The question now is how do we scale efficently which is measured by cost relative to demand. From a server perspective, there are 4 main factors that will drive up costs; Storage, CPU, Network I/O and Disk I/O. By monitoring and analyzing this data, it will be easy to determine, which metric is the bottleneck in the process. In terms of this application, I had leveraged localStorage as a means of validation so that it would reduce API costs. A common practice is to cache database queries based on frequency of queries ran which provides a O(1) vs O(n) space and time complexity. In addition, setting up load balancers, protocols for database indexes, caching, leveraging batch loads or queues will help you scale and reduce costs. If there is demand or high volume of orders, I would move out of heroku or add more dynos.

Front End

I had used reactJS on the front end as it provides a lot of advantage in View of MVC structure. One problem with MVC is bidrectional communication. It can get hard to debug and understand flow of data when app scales. As an alternative approach, Facebook has introduced Flux which is made of 4 key elements; Actions, Stores, Dispatchers and View. This structure allows for unidirectional communication.

API Architecture

I had applied a Restful CRUD API approach. It uses HTTP protocols like GET, PATCH, DELETE and POST to link resources to actions between client and server. REST also mandates the separation between client and server. From the data layer, I had applied CRUD to CREATE, READ, UPDATE or DELETE.

Test scripts are also included for end points.

What Would You Do Differently?

Things I would have done differently:

1. Use Redux for better state management
2. Use TypeScript instead of ReactJS as static typing allows for better debugging processes and helps to catch errors
3. Work on a database more. It was hard to do sequelize commands without being able to work or see the data results. Production deployment failed due to sequelize models not importing.

Improve or Scale the Application

As mentioned above:

1. Use caching to do more of the calculations. My application uses localStorage to do the initial test validations of the data. This will also save on costs when you hit the API.
2. Use a database with good indexing and structure in place. I didn't focus too much on the database which definitely doesn't work out when you need to use the data to determine answers.
3. Set up additional validation checks on the backend. I had focused most of my effort on the front end checks as data persisted there.
4. I created unit tests to test the end points but ideally should have try to work on some more.
5. I thought about using jwt tokens to track users who had already purchased items. As the data is transmitted back to the user, I would provide a jwt token so you can tack is customer is an existing customer.