DEV Community: Darrel Idiagbor

Development of a simple shopping cart application

Darrel Idiagbor — Mon, 18 Jan 2021 21:39:53 +0000

Problem Statement

The challenge today is to build the backend of a simple shopping cart application using node.js and typescript while using MySQL as the database and postman for documentation purposes.
This shopping cart is assumed to have categories and products having standard attributes such as (SKU, selling price, stock level, expiration date) etc... and should be able to allow a user add to cart, edit what's in the cart as well as remove from cart.

Thoughts and structure

The problem is simple enough to tackle on first glance but as I usually say nothing is ever really as it seems. So to up it up a bit, I would set a personal goal of completing the challenge in 3 days or less, I would also be implementing functionality for dynamically manipulating categories and products as well as unit testing all functionalities on this application and developing this article in real-time as I achieve it.
Now with a little extra difficulty, the first thing I'd do is to assign tasks for these 3 days;

Day 1: Folder structure and general functionalities.
Day 2: Unit testing of all functionalities; although this would most like come before each functionality is developed. That way the entire application would be built using TDD (test-driven-development)
Day 3: Deployment, documentation and editing of this article.

Folder Structure

Although a small and simple application, I structured the application for scale. Below I would discuss the various folders and files and their purpose; were necessary I would include examples.

Files on the structure

Below I would give short descriptions of key files on the root of the folder and what they are meant for and what role they play. These definitions are by no way standard description of what they are officially but my way of describing what they are and the role they play in my codebase.

.env: This is the environment variables file; basically all sensitive variables are kept here such as database URLs or keys both secret and public can be kept here.
.env.example: This file simply provides a structure of how .env should be set up; it could contain just variables without values or consist of mock values and not the actual values
.eslintrc.js: This holds configurations for eslint which is a linter for javascript and even typescript.
.gitignore: This consist of files and folders that should be ignored by git(a version control system)
generateKeyPair.js: This holds an algorithm to generate *.pem files i.e public and private key pairs for tokens generation and verification.
nodemon: This file holds configurations for nodemon which handles spinning up and restarting the development server when specified changes are detected.
package.json: This file holds information about the application and is generated by npm. It is generated with the npm init command
README.md: This file tells anyone visiting the codebase what to do, how to do it or what the application is about.
tsconfig.json: This file holds information about how typescript should work on the application and is generated by typescript. It is generated with the tsc init command.

Now, the onto the folders

Below I would describe the folders and the kind of files they are meant to hold; I would not necessarily go in-dept on the files within the folders.

/prisma: This folder is generated by prisma, which is an ORM (object-relational mapping) for MySQL which is the database for this shopping cart application. This folder holds the schema and migrations folder which are generated and manipulated by Prisma. Subsequently, the seed.ts file also sits here and its purpose is to populate the database with data to get started. To get started with Prisma and generate the folder, run npx prisma init. Given that you have @prisma/cli installed.

Note: This walkthrough assumes you have nodejs installed on your local computer. Go to Nodejs if you don't have it.

/src: This is the working directory of the application and all other paths below would be relative to this.
/api/controllers: This folder holds controllers that routes link to; these controllers effect validations, perform validations of themselves and call the business logic from service folder.
/api/database/repository: This folder holds repositories for the business logic and these are simply database connections and actions e.g a repository could have a create method that connects to the database and creates a new record or row with the information passed to it. This is done to enable future change in database. Although this is a small application, Imagine a gigantic application with several hundred endpoints and functionality and all of a sudden there is a need to move from an SQL database to a NoSQL database like MongoDB. It would be cumbersome to go to each page and change database connection. But this way, all the service knows is that it calls a create method and is returned the created record.
/api/routes: This folder holds all routes/endpoints for the application in question.
/api/validators: This folder holds request body validation rules using the express validator, other validations like query and params are done within the controller. Although these can also be done with the express validator, I did them within the controller to show different approaches to carrying out validation. Personally, I find using express validator relieving.
/assets: This folder holds all assets on the application such as images, audios, videos or any type of asset.
/config: This folder holds configuration files. e.g the index.ts file in this folder maps variables from .env. Such that access to the .env variables stem from a single source rather than scattered across the application.
/core: This holds self-defined class-based functionality. For example, this folder holds classes that perform error and response handling among others.
/helpers: This folder is similar to /core although rather than self-defined classes they are simple functions.
/jobs: This folder holds cron jobs. Basically, pieces of code that have to be run periodically.
/services: I have made reference to the folder above. This folder holds classes that handle the business logic of the application. Basically, the major functionality of applications is resolved within the classes in the services folder.
/subscribers: This folder hold events. Events, in this case, are functions that can run in a non-blocking way. Example of this is the sending of a confirmation email once a user registers can be sent to an event within subscribers and it'll run even after a response has been sent to the client.
/types: This holds all types, interfaces and namespaces to be used throughout the application. Since this is a typescript solution thus the need for types.

Process Flow

The process flow is fairly straightforward at first glance but I would walk you through the thought process of creating this and possible improvements below.

Once a request is sent to an endpoint on this shopping cart application e.g http://localhost:3500/auth/v1/register. It first hits the router for that endpoint and then if it is a public endpoint such as this one it goes to the controller that handles that. If it is a private endpoint like http://localhost:3500/product/v1/create it first advances to get you authenticated with a token that should be on the request header and if available and valid it proceeds to the controller for that route. Subsequently, if this is an admin protected route it further checks the authorized user if the type is that of Admin and if it is you then proceed to the controller.
All-access routes end up accessing the service class which holds the business logic or actual implementation of the route.

This implementation is sufficient for a simple application such as this but for a more verbose and production-ready application, it is advisable to have a process flow as that below.

Not much has changed from the last one except for the introduction of app keys which give all your route some level of security and preserves your server from any kind of misuse with authorization. App keys are usually issued when you register on the application and opt to use the APIs.

Unit Testing

run npx ts-jest config:init to initialize tests with typescript
run npx jest --init to initialize tests with javascript,

Testing is so important in the development of any application, be it large or small. I use testing to ensure that the core functionalities of each chunk of code are maintained no matter the implementation style or pattern. I also love it because when younger people join the team, it prevents from accidental non-working commits or deployments.

Let's talk about some why's

Why category has status and product doesn't

The way the application is structured is in such a way that you need to link a category to a product; if that is the case if a category were to be deleted what would happen to the link?
So to mitigate this, if you don't want a category you simply switch the status to Inactive. The product doesn't on the other hand because:

It stores more data or has more fields
It doesn't link to anything or rather no other table is dependent on it.

Why static methods over instance methods?

//Example of static method in a class
class animal {
  public static color() {
    // ... some functionality here
  }
}

// How you call this method like 
animal.color();

Static methods give you direct access to the method without creating an instance of the class; one immediate benefit is it doesn't use memory to store the instance.
Static methods are used where the method has no interaction with class properties. Thus only one of such methods exists per class whereas instance methods you can create as many instances as needed.

//Example of instance method in a class
class animal {
  public color() {
    // ... some functionality here
  }
}

// How you call this method like 
const animalInstance = new animal();
animalInstance.color();

One of the benefits you see immediately is that with instance methods you can access the constructor function when initializing the class and a draw back as we discussed is the extra pointers in memory to link these instances.

These were the thoughts I had in mind when deciding whether to use static or instance methods.

Why use abstract classes?

//Example of abstract class
 abstract class animal {
  public color() {
    // ... some functionality here
  }
}

An abstract class is more or less a blueprint class i.e you cannot instantiate these classes, rather you extend them and work with them from a subclass. This is because as an abstract class it can have incomplete methods hence the term blueprint class.

Why Redis for the cart and not MySQL?

The choice of Redis for the cart system stems from a desire to improve the performance of the cart system. Redis insertion and retrieval big O notation is O(1) whereas that of MySQL is O(n). What this means is that anytime you try to retrieve or insert a record from a Redis server it would take a constant time, while on the MySQL it'll vary based on the number of records stored on the table.

Conclusion

If there is one thing I believe in it is constant change and evolution and as such, I make it a habit to learn something every time I develop applications. By no way is this a perfect solution to structuring backend applications but I simply collated knowledge from different sources and across time and experience. I am always open to improving on this. Although I initially set out to complete this in 3 days, I ended up completing it in 4 days. This isn't a bad feat; more to come 🚀🚀🚀

Thank you for reading!
You can find the endpoints for this shopping cart application on this postman collection shopping cart postman
The base URL for this shopping cart application is here base url
I can be found on Twitter at https://twitter.com/idiagbordarrel or
please find out more about me on my website at https://idarrel.netlify.app.

Development Of Crypto Based Transfer Payments - Part 1 of 2

Darrel Idiagbor — Tue, 05 Jan 2021 20:36:52 +0000

As a way of introduction, I would start by wishing you all a happy new year and good tidings this year. Although not being a core technical writer. I do want to venture into documenting and helping others through difficult tasks by highlighting some of mine. This will be the first of many I would write over the course of 2021 and beyond.
The project I would be talking about today is one that deals with the transfer of money across borders via cryptocurrency: To shed more light on it, you send money, it converts it and sends it to a receiving cryptocurrency account in the country of your choice, it's converted to the local currency and then resolved in the recipient bank account.

Prototype

Before venturing into my thoughts and analysis do have a look at these:

Current Implementation: RapidPay Website
Proposed Implementation: RapidPay Prototype

First Thoughts

My first thought on this, when approached by the contractors, was oh quite simple, given that there is an existing platform they ride with, and the API's already existed. But as I've come to understand over the years, nothing is ever as it seems.

Second Thoughts: More Structured Thinking

Taking another stab at it, I first thought about the flow from the entry into the website until you get value and secondly, I thought about the emotion or feeling you get while you move through the platform.

On the flow aspect I thought about a form that initializes the whole transfer process from the moment you land the website, with enough guides and adequate breakdowns to give you a sense of what's going on and more information about the business and value propositions. Then I thought about separating the value flow from the information flow - more on this later such that once you have started the process you are not distracted until you complete the process. Finally, I thought of having some tracker to give you a sense of where you're at on your transfer process.
On the emotional aspect of the website, the use of gradient was adopted on the first and second iteration of the home page rather than plain white which seemed to be the general theme for other platforms that perform similar services. The choice of a gradient and one that would be animated - more on this in the implementation phase is to give the user a sort of warmth and relaxed and welcoming feeling when they first land of the website. The form section of the landing page would also be animated to bounce slowly such that the users' attention can still be drawn to the main focal point of the platform despite the general overlay. Finally, the use of icons in many parts of the website is to appeal to one's sense of wonder and creativity and allow users infer in one glance what a section is about without having to read the text.

Deep dive into the screens

I would talk about most of the screens designed and the thinking behind them and compare them to the previously implemented solution where applicable.

Home Screen

Old Home Landing Screen

The old screen has a static image on the background, a single form that handles the entire process; the drawback of which doesn't give you an idea of how far of or close you are along in the process. If an error hits, it stalls the whole process and doesn't give much room to go back to specific points. Also, the support link is simply a call icon which doesn't give insight to what it does.

New Home Landing Screen

Iteration 1

The first iteration of the new home landing screen shows an animated gradient background that serves as a form of warm feeling to the user on entry into the website and the form element that initializes the transfer process. It features all the conversion rates in real-time as well as fees, in a bid to uphold transparency in the process. Finally, there is a dedicated contact support button that informs the user on where to get help.

Iteration 2

The second iteration of the new home landing screen shows the animated gradient background, but simply over the form element and my intention here was to take the warmth gradients bring to the core selling point or value point of the screen while still giving a sense of seriousness that white backgrounds bring.

Iteration 3

The third iteration of the new home landing screen is intended to give off a serious vibe and that is depicted with the choice of a completely white background. The ribbon-like illustration is simply for demarcation between the landing section and the rest sections of the home screen, while the mango-like illustration was placed there with the intention of being a friendly aesthetic complement to the seriousness white brings.

Old Customer Reviews Screen

The old customer review screen consists of a world mapped background and tiny icons at different spots on the map with no clear way of noticing the comments or information about the commenters. This approaches drawback consists of the fact that comments are not intuitive and leaves the user bemused at first sight as comments are conveyed by hovering on the tiny icons which becomes a further issue on mobile screens that do not provide hovering functionalities.

New Customer Reviews Screen

The new customer review screen, however, is more descriptive as it includes a continuous slider of the actual review comment as well as the star rating and minor biodata of the commenter, the reason for this is to give a sense that this product is actually interacted with by real faced individuals.

Call To Action Screen

This is a new addition on the new home flow that lacks on the previous home screen, and this screen is important because it prompts the user to perform an action after seeing all the information following it, rather than hope the user scrolls to the top to act.

Transfer Flow Screen

This set of screens lack on the old version as the entire flow occurred all on the same form item. This flow enables the user to have a sense of where they are along the process and return to specific points on the flow.
The flow begins at different steps depending on where you enter through if you begin at the landing page of the website, you will move to the second step on the transfer flow because an amount already exists. However, if you enter through the call to action, you would have to start at the first screen.
These screens are not exhaustive of the entire process but highlight the overall look and feel of the flow.

Conclusion

To recap, this part discussed the various screens and sections of the new flow, why it was created that way and how it differs from the previous design. This is to give insights into the thought and ideas that went into the look, feel and flow of the platform.

The next part would discuss the actual frontend implementation of this design. Some of the challenges faced how especially challenging UI components were implemented, and such matters as reusability in frontend codebases.

Thank you for reading!
I can be found on Twitter at https://twitter.com/idiagbordarrel or
please find out more about me on my website at https://idarrel.netlify.app.