DEV Community: Chiranjeev Thomas

LLD : N X N Tic Tac Toe with O(1) checks

Chiranjeev Thomas — Sun, 21 Jul 2024 10:38:58 +0000

🚀 *The Importance of Low-Level Design (LLD) in Interviews * 🚀

In today's tech interviews, mastering Low-Level Design (LLD) is crucial.

It demonstrates your ability to think through the detailed aspects of system design, ensuring robustness, scalability, and maintainability.

Let's explore how to design a software system for such interviews with an advanced N x N Tic Tac Toe game! 🎉

🔍 Overview:

This project brings a modern twist to the classic Tic Tac Toe game, allowing players to compete on a flexible N x N board.

The first player to align N marks in a row, column, or diagonal wins the game. If the board is filled without any player achieving this, the game ends in a tie.

📝 Game Rules:

Players:

Player 1 ('Bob')
Player 2 ('Alice')

GamePlay:

Player 1 starts the game by placing a 'Bob' on the board.
Player 2 follows by placing an 'Alice'.
Players take turns to place their marks in an empty cell of the board.
The game continues until a player wins or the board is full.

Winning Conditions:

A player wins by placing N marks consecutively in a row, column, or diagonal.
If all cells are filled and no player has N consecutive marks, the game is a tie.

💡 Classes:

Player:

Represents a player in the game.
Can be extended to include additional player attributes and methods.

Board:

Manages the state of the game board.
Contains the business logic to check for valid moves and determine the game status (win/tie).

Game:

Orchestrates the game flow.
Interacts with the Player and Board classes to manage turns and check for game completion.

⚙️ Algorithm Design:

The time complexity for determining whether a player has won, tied, or has more moves left is constant time, O(1).

🎮 Ready to dive in? Check out the GitHub repository and start playing! 🕹️

GitHub Link : https://lnkd.in/gGShtCTF

Reference Video : https://lnkd.in/gr6D5uBG

LowLevelDesign #TicTacToe #Python #GameDevelopment #OOP #DesignPatterns #Coding #SoftwareEngineering #GitHub #Tech #Interviews

🚀 The Importance of Understanding Social Networking Basics 🚀

Chiranjeev Thomas — Tue, 28 May 2024 11:05:52 +0000

In today's digital era, almost every website incorporates social media components. Whether you're browsing through reviews on Amazon, checking out product ratings on Flipkart, or engaging in discussions on Reddit, social networking features are ubiquitous. They drive user interaction and engagement, making it crucial for tech enthusiasts and professionals to grasp the fundamentals of social networking websites.

🔍 Why Should You Care?

Understanding these basics is not just about building traditional social media platforms like Facebook or Twitter

E-commerce Sites: User reviews and ratings (like on Amazon) play a vital role in purchasing decisions.
Content Platforms: Comments, likes, and shares (as seen on YouTube and blogs) increase user interaction.
Professional Networks: LinkedIn recommendations and endorsements help build professional credibility.

🛠️ Exciting Backend Project Opportunity!

This backend project that encapsulates these social networking principles, designed with industry best practices like Test-Driven Development (TDD).
Here's a glimpse into the project features:

🌐 Application Routes

🔑 Auth Routes

/auth/login: Log in a user using their credentials.
/auth/register: Register a new user to the system.
/auth/logout: Log out a user from the system.
/auth/refresh: Refresh the user's authentication token.

👤 User Routes

/users: Fetch a list of all users.
/users/:userId: Fetch details of a specific user.
/users/:userId/avatar: Fetch the avatar of a specific user.
/users/:userId/follow: Follow a specific user.
/users/:userId/unfollow: Unfollow a specific user.
/users/:userId/recommendations: Fetch recommendations for a specific user

📝 Post Routes

/posts: Fetch a list of all posts.
/posts/:postId: Fetch details of a specific post.
/posts/:postId/photo: Fetch the photo of a specific post.
/posts/:postId/comment: Comment on a specific post.
/posts/:postId/uncomment: Delete a comment on a specific post.
/posts/:postId/like: Like a specific post.
/posts/:postId/unlike: Unlike a specific post.
/posts/by/user/:userId: Fetch all posts by a specific user.
/posts/feed/user/:userId: Get the feed for a specific user.

📋 Self Routes

/self: Fetch information about the logged-in user.

🔧 Built with Precision
This project adheres to best practices, including TDD, to ensure robust and maintainable code. In a job market that increasingly demands senior-level expertise, writing clean and efficient code is non-negotiable.

📎 Check it Out on GitHub!
Explore the project in detail on my GitHub profile: https://lnkd.in/gCiFTSfF

Stay tuned! The frontend for this backend application will be released soon, providing a complete full-stack solution.

Happy coding! 🌟

My First Tech Startup ... An Accident?

Chiranjeev Thomas — Thu, 19 Oct 2023 08:29:12 +0000

How solving a problem for my college mates gave me a glimpse into the world of tech startups

Prelude :

Let me begin by stating that it would be a long stretch for me to even call the humbe website I built for a few hundred people while still at the university, a legitimate startup .

Heck , I didn't even code it ... just went on Google Sites and used predefined templates to put together a functional static website .

At that moment , it was more about solving a problem I had myself, so that others like me would not have to struggle with it as much as I did.

However , it did use digital technology to address a pain point , so I'll stick to calling it a tech - startup !

Scenario :

Every year students have to appear for 2 main exams , a unit test and submit a couple of assignments that are taken by 180 people of a specific Course ( MCA )

As per exam paper trends , About 60 - 70 % of the Topics / Questions are repeated from the last 5 years papers in every subject

Theoretically, if you come prepared with the answers to the past 5 years' exam questions, then you will be able to pass the exam without buying any books, making notes, or attending classes (of course, you should keep attendance in mind)

The Problem : Digital Copies of Question papers are non-existant , and the only way to get ones hands on the previous years papers is to go to the 2nd floor of the University's Library and take a zerox of each and every question paper .

And this needs to be done by everyone who wants to benefit from the question papers .

So , theoretically , 180 people will have to go through this arduous process EVERY YEAR

What I did not consider at the start :

How would I scale it ? ( will it even scale )

What's the monetisation stategy going to be ?

How will I market it ?

What I did cosider at the start :

Will people actually benefit from it ? ( does solving the problem have value )

Will it make the life of even 1 person a bit better ?

Will it solve a recurring problem ? ( i.e Will solving this problem have a long term impact , albeit , for a small group of people )

Some metrics :

Starting Assumtion : Maximum Number of people estimated to be helped at any point in time : 60 * 3 = 180 ( 3 batches of classes )

Actual Number of page visits per month on average : 33.52 ( Google Analytics )

Actual Number of unique visitors throughout the lifetime of the website : 1106 ( Google Analytics )

Maximum number of people to ever visit the website in a given month : 120 ( Google Analytics )

Money spent on marketing the product : 0

Simply put , the problem that I was trying to solve was the lack of digital resources for students to study for upcoming exams.

To address this problem, I decided to create a website that would host digitally scanned exam papers.

I used my own Google Drive to store the scanned papers, and I made it simple for students to access them through the website.

The website was designed to be user-friendly and easy to navigate, mobile responsive , with a clean and modern design.

The website gained a lot of traction since its launch.

It has received positive reviews from students , who have found it to be a helpful resource for their studies and their careers.

The website has also received favorable reviews from users on Quora and Facebook.

Quora : " "

However, the website did not generate any sponsorships / income for me. ( but then , that was never the objective )

In conclusion, my startup project was a success ( or at least how i defined success for this particuar project ) .

I was able to solve a real-world problem by creating a simple website that hosted digitally scanned question papers that catered to the needs of a few hundred students .

Concluding Thoughts :

How would I have scaled the startup, had I chosen to !

I could have made the website usefull for all the students at the university ( More than 1,000,000 students ) by making it easy for individuals from all courses to submit scanned papers to the website

Which feature would have made the website 10X more usefull ?

M.L algorithms that would have scanned question papers and predited the questions to be asked with high accuracy for all courses .

How could I have monetise the startup ?

Google Ads

Ed-tech sponsorships

Mentoring Framework ( 1 to 1 ) from industry exprets

Premium Question paper generation with highest % of accuracy

How would I have marketed it ?

Posting about the website on Facebook groups of all the courses , along with the accuracy of the website to predict upcoming exam questions would have generated suffiient buzz and impetus for people to start using and contributing to the website

( p.s : I did not purchase even a single text book during the 3 years of my masters and solely relied on Google Search+ Digital Question papers to prepare for my exame )

( p.p.s : I spent no more than 6 hours of prep time / subject using the exam papers and scored above 60% in aggregate)

Click to View the Website: In case you wanted to have a look

Embracing Clean Architecture: A Journey to Better Code

Chiranjeev Thomas — Thu, 19 Oct 2023 08:27:02 +0000

"DevReferral's journey from MVC to Clean Architecture: Discover how adopting Clean Architecture improved code quality, enabled Test-Driven Development (TDD), and paved the way for scalability, all while reducing technical debt. Explore the benefits of this transformation for startups seeking resilient and adaptable software solutions."

In the fast-paced world of startups, it's crucial to build a strong foundation for your software from the very beginning. One of the most common challenges startups face is maintaining code that can adapt to evolving requirements while remaining maintainable and testable. At DevReferral, we embarked on a journey to transform our codebase by adopting Clean Architecture, and in this article, we'll share our experiences and insights along the way.

The Road to Clean Architecture

DevReferral began as a small startup with big ambitions. Like many startups, we initially developed our application using the traditional MVC (Model-View-Controller) architecture with JavaScript in an Express.js Node.js app. This choice allowed us to quickly prototype and develop our application, but it came with its set of challenges.

Our MVC architecture led to a tightly coupled system, where dependencies were intertwined, making any change a complex, error-prone process. To exacerbate the issue, our testing strategy primarily focused on router-level tests using tools like Supertest, leaving individual modules of code untested. This practice left us vulnerable to regressions and made the development process slower and riskier.

As we realized the limitations of our initial architecture, we began exploring alternative approaches. Domain-Driven Design (DDD) and Clean Architecture stood out as promising options, each offering a unique set of benefits. Ultimately, we decided to adopt Clean Architecture because of its clear separation of concerns and its potential to facilitate the transition to microservices in the future.

Understanding Clean Architecture

Clean Architecture, introduced by Robert C. Martin, is a software architectural pattern that emphasizes modularity, maintainability, and testability. At its core, Clean Architecture advocates for a strict separation of concerns by dividing the codebase into concentric circles or layers, each with a specific responsibility. Let's explore these layers:

Entities: At the center of the architecture are the entities, which represent the core business domain. These entities are independent of any external frameworks or technologies and encapsulate the business rules.
Use Cases: Surrounding the entities are use cases or interactors. These use cases define the application's business logic. They serve as an intermediary layer between the entities and the external world.
Interfaces: Moving outward, we have the interfaces layer. This layer defines the boundaries through which data flows in and out of the application. It includes interfaces for communication with external systems, such as APIs and databases.
Frameworks and Drivers: The outermost layer consists of frameworks and drivers. This layer is responsible for handling external concerns like the user interface, web frameworks (e.g., Express.js), and database access. It's essential to note that this layer depends on the inner layers, but the inner layers remain independent of the outer layers.

Benefits of Clean Architecture

Separation of Concerns: Clean Architecture enforces a strict separation of concerns, making it easier to reason about different parts of your application. This separation improves code organization and maintainability.
Test-Driven Development (TDD): Clean Architecture facilitates the practice of TDD by allowing you to write isolated unit tests for each component. With well-defined boundaries, it becomes simpler to mock dependencies and ensure that your code behaves as expected.
Scalability and Adaptability: By decoupling the core business logic from external frameworks and technologies, Clean Architecture makes it easier to adapt to changing requirements and even transition to microservices when your startup grows.
Reduced Technical Debt: With cleaner code and well-defined boundaries, you'll accumulate less technical debt over time. This leads to a more efficient development process and fewer bugs. --- Our Journey with Clean Architecture Adopting Clean Architecture at DevReferral was not without its challenges. Here are some key steps we took on our journey:
Education: We invested time in understanding the principles of Clean Architecture thoroughly. This involved reading books, articles, and attending workshops to ensure our team had a shared understanding of the approach.
Refactoring: We started refactoring our existing codebase incrementally. This process involved identifying the core entities and use cases and gradually migrating them to fit the Clean Architecture structure.
Dependency Injection: We adopted dependency injection to manage dependencies between layers. This allowed us to replace real implementations with mocks during testing, making our unit tests more isolated.
Testing Culture: We cultivated a testing culture within our team. We began writing unit tests for all our use cases and entities to ensure they behaved correctly. This approach helped us identify and fix issues early in the development process.
Code Reviews and Knowledge Sharing: We encouraged code reviews and knowledge sharing sessions among team members. This facilitated learning and ensured that the Clean Architecture principles were consistently applied. --- Conclusion In the journey of adopting Clean Architecture at DevReferral, we witnessed a significant transformation in our codebase. The separation of concerns, emphasis on testability, and scalability provided by Clean Architecture have empowered our team to build more robust and adaptable software. While transitioning to Clean Architecture required effort and commitment, the benefits it brought to our startup far outweighed the initial challenges. Clean Architecture has not only improved our code quality but also set the stage for future growth and the potential transition to microservices. As a startup, investing in Clean Architecture early on has proven to be a wise decision. It's a testament to the importance of building a solid foundation for your software, one that can withstand the evolving demands of your business. In conclusion, if you're a startup founder or developer looking to build maintainable, scalable, and testable software, consider embarking on your own journey to Clean Architecture. It's a path that can lead to code that's not only clean but also resilient in the face of change, ultimately setting your startup on a path to success.

GPT Prompts: A Next.js 13 App ( App Router )

Chiranjeev Thomas — Thu, 19 Oct 2023 08:24:24 +0000

A Next.js 13 + Tailwind app, that lets users submit prompts that can be used to perform various tasks using CHAT GPT

GPT Prompts: Live Project

GitHub Repo

System Design (Comprehensive List)

Chiranjeev Thomas — Thu, 19 Oct 2023 08:22:38 +0000

System Design Concepts List and related links to comprehensive reviews

Objectives :

💎 To have a comprehensive understanding of different software architectures ( SOA , Monoliths , Micro-Services )

💎 To confidently design complex systems such as Stripe , Amazon , Instagram ... While discussing the tradeoffs of a selected architectural style

💎 Identify and select various auxiliary services for special use cases in a system , while discussing their benefits and trade offs

Key Concepts ( Pre - Req's )

1> Scalability

2> Availability

3> Reliability

4> Replication

5> Load Balancing

   > a. What problems do load balancers solve ?
   > 
   > b. Types of Load Balancer
   > 
   > c. Different Algorithms used in Load balancers
   > 
   > d.  Pros & Cons (discussing the trade-offs when to use LBs are when to avoid)

6> Caching

  - What is caching? And what problems caching systems are trying to solve?
  - Cache Invalidation & Cache eviction policies

7> Sharding Or Data Partitioning

 - Partitioning Techniques
 - Leader Selection

8> Challenges that Sharding brings into the system

Joins & Denormalization

Enforcing Integrity Checks & Validations

Rebalancing

9> Indexing

Need for Indexing and the problem Indexing is trying to solve

MySQL Indexes

NoSQL Indexes Challenges that Indexes bring into the systems

10> Proxies

11> Proxy Servers

What problem Proxy servers are trying to solve?

Types of Proxy Servers

12> Reverse Proxy Servers

13> Importance of Replication and Redundancy

14> NoSQL vs SQL
> - Differences between SQL & NoSQL (Storage, Schema, ACID properties, Scalability)

15> CAP (Consistency, Availability & Fault Tolerance) theorem

16> Distributed Hash Tables (DHTS) & Consistent Hashing

What Problem Consistent Hashing is trying to solve?

Examples when to use consistent hashing

17> HTTP Long Polling, Server Sent Events & Web-sockets

18> APIs (Application Programming Interfaces)

19> Client-Server Architecture and Peer-to-peer

20> Microservice Patterns

Decomposition Pattern

Strangler Pattern

SAGA Pattern

CQRS Pattern

20>Different Types of Storage
> - Object
> - File
> - Block

21> Message Queues

22> Gossip Protocols

23> Rate Limiting

Framework To Design Systems in System Design Interviews

Gathering Requirements
> - Functional
> - Non-Functional
>

High Level APIs provided by the system

Capacity Planning

Data Models

High Level Design

Focus On 1-2 individual components in the system

Network Protocols

Bottlenecks & Single Point Of Failures in the system

Caching

Security

Data Compression

Designing Distributed Systems (From Scratch)

Designing Uber, Rapido & Ola

Designing Swiggy, Zepto & Blinkit

Design Amazon Retail

Designing Facebook/Instagram

Design File sharing platforms (DropBox, Google Drive)

Design A Key-Value Store (Like Amazon DynamoDB)

REST API USING TYPESCRIPT ( CRUD )

Chiranjeev Thomas — Thu, 19 Oct 2023 08:20:08 +0000

An MVC Express Typescript App with CRUD operations, including File Upload and proper Authentication and Authorization using JWT

In this Article, we'll delve into the process of creating a RESTful API that implements CRUD operations using JWT for authorization

A basic CRUD api has options to CREATE / READ / UPDATE and DELETE items , along with Authentication and Authorisation in place , so as to ensure that the app transactions are secure

👀 NOTE : This APP has not been created using the best testing practices ( i.e TDD or BDD ) , but we'll mitigate this issue later by creating a similar app , where WE'LL BE FOLLOWING TDD / BDD practices , and buiding it using the principles of CEAN ARCHITECTURE

An Overview Of The Project :

✅ The project is an e-commerce app that lets the ADMIN add products to the backend (The product has some text details and a picture )

✅ Sign up: Users can register by creating a new account using an email address and password.

✅ Authentication: Registered users can login and logout.

✅ Only admins are allowed to create products

✅ Protected user profile: Only registered users can view individual user details after signing in.

18. ✅ We'll be using JWT to provide Authorization / Authentication in the app

The API we'll be creating :

Let's first talk about the USER MODEL

A person who registers on the app can either have the role of a user or an admin .
An admin has all permissions but a user is limited to only viewing products and their own information


import { Document, Schema, model } from 'mongoose';

// Define the interface for the User document
const enum Role {
  ADMIN = 'admin',
  USER = 'user',
}
export interface IUser extends Document {
  username: string;
  email: string;
  password: string;
  role: Role;
}

// Declare the Schema of the Mongo model
const userSchema = new Schema<IUser>(
  {
    username: {
      type: String,
      required: true,
      index: true,
    },
    email: {
      type: String,
      required: true,
      unique: true,
    },
    password: {
      type: String,
      required: true,
    },
    role: {
      type: String,
      enum: [Role.ADMIN, Role.USER],
      default: Role.USER,
    },
  },
  {
    timestamps: true,
  }
);

// Export the model
export default model<IUser>('User', userSchema);

So in the above userSchema , we define the username , email and password for a user to register , along with a role that's set to user by default

The roles are set as Enums deliberately , so as to avoid illegal assignment .

const enum Role {
  ADMIN = 'admin',
  USER = 'user',
}

Now , let's look at the `registerUser` controller

Steps taken to register a user :

Step 1 : [+] validate the request and extract info

Step 2 : [+] check if user is in database already

Step 3: [+] hash password to encrypt

Step 4: [+] create user object

Setp 5: [+] save user to database

Setp 6 : [+] create access_token ( JWT )

Step 7 : [+] create refresh_token ( JWT )

Step 8 : [+] save refresh_token to db

Step 9 : [+] send json response to frontend ( with the newly created refresh_token and the access_token )

Step 10 :[+] send async exception to next(err)

//registerUser.ts

import { NextFunction, Request, Response } from 'express';
import { NextFunction, Request, Response } from 'express';
import { REFRESH_TOKEN_SECRET } from '../../config';
import { RefreshToken, User } from '../../models';
import { IUser } from '../../models/UserModel';
import CustomErrorHandler from '../../services/CustomErrorHandler';
import EncryptionService from '../../services/EncryptionService';
import JwtService from '../../services/JwtService';
import { RegisterUserRequest, RegisterUserResponse, Role } from '../../types';
import { registerSchema } from '../../validation';

type Tokens = {
  access_token: string;
  refresh_token: string;
};


const registerUser = async (
  req: Request<RegisterUserRequest>,
  res: Response<RegisterUserResponse, Tokens>,
  next: NextFunction
): Promise<void> => {
  try {
    // [+] validate the request and extract info
    const { username, email, password } = await registerSchema.parseAsync(
      req.body
    );

    //[+] check if user is in database already
    const userExists = await User.exists({ email });

    if (userExists)
      return next(
        CustomErrorHandler.alreadyExists('This email is already taken')
      );

    //[+] hash password to encrypt
    const hashedPassword = await EncryptionService.getHashedToken(password);

    //[+] create user object
    const userInfo = {
      username,
      email,
      password: hashedPassword,
      role: Role.ADMIN,
    };

    //[+] save user to database
    const user: IUser = await User.create(userInfo);

    //[+] create access_token
    const access_token = await JwtService.sign({
      _id: user._id as string,
      role: user.role,
    });

    //[+] create refresh_token
    const refresh_token = await JwtService.sign(
      {
        // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
        _id: user.id,
        role: user.role,
      },
      '1y',
      REFRESH_TOKEN_SECRET
    );

    //[+] save refresh_token to db
    await RefreshToken.create({ token: refresh_token });

    // [+] send response
    const tokens: Tokens = { access_token, refresh_token };
    res.json(tokens);
  } catch (err) {
    next(err);
  }
};

export default {
  registerUser,
};

Let's turn our attention to the multiple imports we have at the top of the `resgisterUser` code ( p.s : this is a bad sign , as the number of imports shows how coupled our code is with other modules )


import { NextFunction, Request, Response } from 'express';
import { REFRESH_TOKEN_SECRET } from '../../config';
import { RefreshToken, User } from '../../models';
import { IUser } from '../../models/UserModel';
import CustomErrorHandler from '../../services/CustomErrorHandler';
import EncryptionService from '../../services/EncryptionService';
import JwtService from '../../services/JwtService';
import { RegisterUserRequest, RegisterUserResponse, Role } from '../../types';
import { registerSchema } from '../../validation';

Validation using Zod :


// validationSchemas.ts
import { z } from 'zod';

/* The `.refine()` method is used to add additional validation rules to the validation schema. In
  this case, it is checking if the `password` field is equal to the `repeat_password` field. If
  they are not equal, it will throw an error with the specified message ("Passwords don't match")
  and the path of the error will be set to `['repeat_password']`. This allows for more specific
  error messages and error paths when validating the data. */
export const registerSchema = z
  .object({
    username: z.string().min(3).max(20).trim(),
    email: z.string().email().trim(),
    password: z.string().min(6),
    repeat_password: z.string().min(6),
  })
  .refine((data) => data.password === data.repeat_password, {
    message: " : Passwords don't match",
    path: ['repeat_password'], // path of error
  });

Custom Error Handler :

*A Convenient and Elegant way to handle errors is to create a custom error handler and define all errors over there

*We will throw our custom errors if and when the need arises

*By following this pattern, we are in complete control of the declariation and summoning of Errors from a single source of truth

class CustomErrorHandler extends Error {
  constructor(public status: number, public message: string) {
    super();
    this.status = status;
    this.message = message;
  }

  /**
   * The function returns a new instance of a custom error handler with a status code of 409 and a
   * given error message.
   * @param {string} message - The `message` parameter is a string that represents the error message to
   * be displayed.
   * @returns A new instance of the CustomErrorHandler class with a status code of 409 and the provided
   * message.
   */
  static alreadyExists(message: string) {
    return new CustomErrorHandler(409, message);
  }

  /**
   * The function returns a custom error handler with a 401 status code and a message indicating that
   * the user authentication failed due to an invalid password or email.
   * @param [message=password or email invalid] - The message parameter is a string that represents the
   * error message to be displayed when the user authentication fails. By default, the message is set
   * to 'password or email invalid'.
   * @returns A new instance of the CustomErrorHandler class with a status code of 401 and a message of
   * "password or email invalid".
   */
  static userAuthFailed(message = 'missing or invalid jwt') {
    /* The line `return new CustomErrorHandler(401, message);` is creating a new instance of the
  `CustomErrorHandler` class with a status code of 401 and the provided error message. This instance
  is then returned by the `wrongUserCredentials` static method. */
    return new CustomErrorHandler(401, message);
  }

  /**
   * The function returns a custom error handler with a 401 status code and a message indicating
   * invalid password or email.
   * @param [message=password or email invalid] - The message parameter is a string that represents the
   * error message to be displayed when the user credentials are invalid. The default value is
   * 'password or email invalid'.
   * @returns a new instance of the CustomErrorHandler class with a status code of 401 and a message of
   * "password or email invalid".
   */
  static wrongCredentials(message = 'password or email invalid') {
    return new CustomErrorHandler(401, message);
  }

  static notFound(message = 'Not Found') {
    return new CustomErrorHandler(404, message);
  }

  static unAuthorized(message = 'auth failed') {
    return new CustomErrorHandler(401, message);
  }

  static multerError(message = 'Multer File Upload Error') {
    return new CustomErrorHandler(401, message);
  }
}

export default CustomErrorHandler;

You can View the Complete Project on my GitHub profile : here

Test Driven Development ( TDD )

Chiranjeev Thomas — Thu, 19 Oct 2023 08:18:24 +0000

The Benefits of Test-Driven Development in a TypeScript Express Project

Test-driven development (TDD) is a software development practice that involves writing tests before writing the code. This approach helps ensure that the code is thoroughly tested and meets the requirements before release. In the context of a TypeScript Express project, TDD can help improve the quality of the code and reduce the number of bugs.

By following TDD, developers can write tests first and then write the code to make those tests pass. This approach can help catch bugs early in the development process and ensure the code is well-structured and easy to maintain. Additionally, TDD can help developers focus on the project's requirements and avoid getting bogged down in the implementation details.

To start learning about TDD in a TypeScript Express project, wait for the upcoming exercises. In the exercises, you'll learn how to write tests using Jest and Typescript, and how to implement TDD in a simple Express project. By the end of the exercises, you'll have a better understanding of the benefits of TDD in a TypeScript Express project.

Meanwhile, you can try your hand at TDD by attempting any of the following exercises: TDD Buddy Exercises

Update: Exercises Added

1 . Character Copy Kata

Character Copy Kata ( Test Driven Development )

Chiranjeev Thomas — Thu, 19 Oct 2023 08:15:39 +0000

A great kata for introducing jest mocks functions in your project.

Try attempting to solve the kata yourself before looking at the solution : Click here to view the Kata

This Kata expects you to create a character copier class that reads characters from a source and copies them to a destination. The class must copy and write one character at a time

To do this, you need to create a Copier class that takes in a Source and a Destination

The Source interface has a method
char ReadChar() and the Destination interface has a method void WriteChar(char c). The Copier class has a method void Copy() that reads from the ISource one character at a time and writes to the IDestination until a newline (\n) is encountered.

@ The copying and writing is done 1 character at a time.

@ Only the Copier class may exist as a concrete class.

@ You can use any language to implement the Source and Destination interfaces

We're going to solve the following problem using Typescript and the Jest testing framework

First, lets identify all the possible tests you could think of for this scenario

[ ❓ ] No characters , ending in newline

[ ❓ ] Once character , ending in newline

[ ❓ ] Two characters , ending in newline

[ ❓ ] Many characters, ending in newline

[ ❓ ] Order of characters copied should be maintained

[ ❓ ] Characters after newline should not be written

Case 1 : [❓] No characters , ending in newline

Step 1 : Define the most basic test case scenario


//copy.test.ts

  describe('when no character is read', () => {


    it('does not call the desination interface`s writeChar method ', () => {
      const src: Source = getSource([]); // helper method

      const dest = getDestination(); // helper method

      const sut = new Copier(src, dest);

      sut.copy();

      expect(dest.writeChar).toBeCalledTimes(0);
    });
  });

Step 2 : Defining the helper functions

To write tests, we will need two helper methods called getSource and getDestination
that will provide us with the Source and Destination interfaces.

This will allow us to avoid repeatedly creating them for each test, and also make it easier to change any implementation details if needed

( p.s : This step can come at a later stage too, after the tests become repetative.
But in our case, we'll be defining them from the very beginning )


//copier.helper.ts

import { Source } from './character-copier';

/* The code is creating a mock function `mockCharReader` using `jest.fn()`. This mock function will be
used to simulate the behavior of a character reader object. */

export const getSource = (elements: string[]): Source => {

  const mockCharReader = jest.fn();

  elements.forEach((e) => mockCharReader.mockReturnValueOnce(e));

  /* The line `mockCharReader.mockReturnValue('\n');` is setting the return value of the `mockCharReader`
function to be the newline character (`'\n'`). This means that when `readChar` is called on the mock
character reader object, it will return `'\n'` as the next character from the source. */

  mockCharReader.mockReturnValue('\n');

  /* The `return` statement is creating an object with a property `readChar` that is assigned the value
  of the `mockCharReader` function. This object is then returned by the `getSource` function. */

  return {
    readChar: mockCharReader,
  };
};


//copier.helper.ts

/* The code is defining a function named `getDestination` that returns an object with two properties:
`writeChar` and `getWrittenChars`. */

export const getDestination = () => {
  const copiedChars: string[] = [];

  return {

   /* The `writeChar` property is a function that is defined using `jest.fn()`. This creates a mock
   function that can be used to simulate the behavior of a `writeChar` function. */

    writeChar: jest.fn((c: string) => {
      copiedChars.push(c);
    }),

/* The `getWrittenChars` property is a function that returns the `copiedChars` array.
This function can be used to retrieve the characters that have been written to the destination. */

    getWrittenChars: () => copiedChars,

  };
};

Now let's look at the code for our concrete Copy Class


\\Copy.ts

export class Copier {
  constructor(
    private readonly src: Source,
    private readonly dest: Destination
  ) {}

  /* The `copy()` method in the `Copier` class is responsible for copying characters from the source
  (`src`) to the destination (`dest`). */
  copy() {
    let char = this.src.readChar();

    while (char !== '\n') {
      this.dest.writeChar(char);

      char = this.src.readChar();
    }
  }
}

export interface Source {
  readChar(): string;
}

export interface Destination {
  writeChar(c: string): void;
}

✅ Result : A passing test 🎉

In a similar format , we impelement all the rest of the test cases too


//[+] Once character , ending in newline

  describe('when 1 character is read', () => {
    it.each([{ char: 'a' }, { char: 'b' }, { char: 'c' }, { char: 'd' }])(
      'reads first char from source',
      ({ char }) => {
        const src: Source = getSource([char]);

        const dest = getDestination();

        const sut = new Copier(src, dest);

        sut.copy();

        expect(dest.writeChar).toHaveBeenCalledWith(char);
      }
    );
  });

  //[+] Two characters , ending in newline
  describe('Two characters , ending in newline', () => {
    it.each([
      { chars: ['a', 'b'] },
      { chars: ['c', 'd'] },
      { chars: ['e', 'f'] },
    ])('reads exactly 2 times before encountering a newline', ({ chars }) => {
      const src: Source = getSource(chars);

      const dest = getDestination();

      const sut = new Copier(src, dest);

      sut.copy();

      expect(dest.writeChar).toHaveBeenCalledWith(chars[0]);
      expect(dest.writeChar).toHaveBeenCalledWith(chars[1]);
      expect(dest.writeChar).toBeCalledTimes(2);
    });
  });

  //[+] Many characters, ending in newline
  describe('Many characters, ending in newline', () => {
    it.each([
      { chars: ['a', 'b', 'c', 'd', 'g', 'c'] },
      { chars: ['c', 'd', 'e', 'f', 'd', 'f', 'd'] },
      { chars: ['e', 'f', 'g', 'd', 'd', ''] },
    ])(
      'reads exactly $chars.length times before encountering a newline',
      ({ chars }) => {
        const src: Source = getSource(chars);

        const dest = getDestination();

        const sut = new Copier(src, dest);

        sut.copy();

        expect(dest.writeChar).toBeCalledTimes(chars.length);

        //multiple characters written (order does not matter)
        chars.forEach((c) => expect(dest.writeChar).toHaveBeenCalledWith(c));

        // confirm last called character
        expect(dest.writeChar).toHaveBeenLastCalledWith(
          chars[chars.length - 1]
        );
      }
    );
  });

  //[+] Order of characters
  describe('Order of characters', () => {
    it.each([
      { chars: ['a', 'b', 'c', 'd', 'g', 'c'] },
      { chars: ['c', 'd', 'e', 'f', 'd', 'f', 'd'] },
      { chars: ['e', 'f', 'g', 'd', 'd', ''] },
    ])('has all characters copied in the same order', ({ chars }) => {
      const src: Source = getSource(chars);

      const dest = getDestination();

      const sut = new Copier(src, dest);

      sut.copy();

      expect(dest.writeChar).toBeCalledTimes(chars.length);

      expect(dest.getWrittenChars()).toEqual(chars);
    });
  });

  //[+] Characters after newline should not be written
  describe('Characters after newline should not be written', () => {
    it.each([
      {
        chars: [`1`, `2`, `3`, `4`, `5`, `6`, `7`, `\n`, `a`, `b`],
        before: [`1`, `2`, `3`, `4`, `5`, `6`, `7`],
        after: [`a`, `b`],
      },
      {
        chars: [`1`, `2`, `7`, `5`, `4`, `\n`, `c`, `d`],
        before: [`1`, `2`, `7`, `5`, `4`],
        after: [`c`, `d`],
      },
    ])(
      'has all characters before : $before , the newline  and none after : $after',
      ({ chars, before, after }) => {
        const src: Source = getSource(chars);

        const dest = getDestination();

        const sut = new Copier(src, dest);

        sut.copy();

        expect(dest.getWrittenChars()).toStrictEqual(before);
        expect(!isIntersection(after, dest.getWrittenChars())).toBe(true);
      }
    );
  });

✅ Result : We pass all the tests 🔥🔥

We do need one more helper function isIntersection , that lets us find out if any element in one array is present in another array ( i.e Is there an intersection between the values of 2 arrays ? )


//copy.helper.ts

 /* The `isIntersection` function takes in two arrays `a` and `b` as parameters. It checks
if there is any element in array `a` that is also present in array `b`. It does this by
using the `some` method on array `a`, which returns `true` if at least one element
satisfies the provided condition. The condition being checked is whether `b` includes
the current element `e` from array `a`. If there is at least one element that satisfies
this condition, the function returns `true`, indicating that there is an intersection
between the two arrays. Otherwise, it returns `false`, indicating that there is no
intersection. */

export const isIntersection = (a: string[], b: string[]) =>a.some((e) => b.includes(e));

👍 Great !! This concludes our tutorial .

If you want , you can have a look at the souce code on GitHub : Click Here To View Source Code

If you have any questions regarding the exercise , you're free to add a comment on the blog post and i'll try to answer it ASAP 🧑‍💻 !

Writing User Info to files in CSV format ( TDD Kata ) - Part 2

Chiranjeev Thomas — Thu, 19 Oct 2023 08:12:25 +0000

Part 2 of the Writing User Info to files in CSV format kata.

In this particular kata, we are faced with the challenge of batch-processing our user data, as importing and writing millions of records resulted in our server crashing.

Summary :

We continue from Part 1 ( start with this post ) , where we defined the problem and suggested the probable solution for it , given the scenario .

Now, we have a different requriement. Our product manager has informed us that because we're trying to write millions of customer records to a file , our backend server keeps on crashing ... and because of that we're been tasked with creating a batched processing feature .

So , in this case , we'll be able to specify the amout of Customer Info we'll batch together and write in 1 go , before the next batch comes in . Thereby preventing the backend from getting overwhelmened and eventually crasing !

We need to also ensure that previous tests don't break, which can be achieved by building on top of the previous impelemtations , rather than modifying them , i.e : adhere to the Open Closed Principle and the Single Responsibility Principle .

Objectives of ths Post :

1 : Create a batched processing system

2 : Extend the functionality of the existing app , without failing previous tests

3 : Manage the test suit , while expanding the functionality

4 : Follow the SOLID principles ( particularly Single Responsibility and Open Closed Principles )

Writing User Info to files in CSV format ( TDD Kata ) - Part 1

Chiranjeev Thomas — Thu, 19 Oct 2023 08:10:37 +0000

How does one handle changes to the requirements in a real-life setting while building software using Test Driven Development?

This article explores different techniques one can apply in situations where requirements for a feature keep changing constantly

Summary :

How does one handle changes in feature requirements while building software using Test Driven Development ?

This article explores different techniques one can apply in situations where requirements for a feature keep changing constantly .

We will require the knowledge of S.O.L.I.D principles , Typescript and some knowledge of creating and using mocks in Jest ( However , you're free to use whichever language and testing framework you like )

There will be 4 different parts to this exercise , reflecting the different requirements that were brought in by the product manager at different stages of the prouduct development process

Task 1 : Write Customer information to a file in CSV format

Task 2 : Write Customer information in batches of N customers at a time

Task 3 : Wrire Customer information , with no duplicate entries

Task 4 : Write Customer information to 2 different sources ( one with duplicates and one without for monitoring purposes )

In this specific post , we'll be concerntating on the 1st task and getting things set up !

First Let's look at the UML Diagram for the particular situation :

Code :

//Customer.ts

class Customer {
  constructor(private _name: string, private _contactNumber: string) {}
  constructor(private _name: string, private _contactNumber: string) {}

  public get name(): string {
    return this._name;
  }

  public set name(value: string) {
    this._name = value;
  }

  public get contactNumber(): string {
    return this._contactNumber;
  }

  public set contactNumber(value: string) {
    this._contactNumber = value;
  }


}

export default Customer;

\\FileWriter.ts

interface FileWriter {
  writeLine(fileName: string, line: string): void;
}

export default FileWriter;

//CustomerFileWriter.ts

export class CustomerFileWriter  {
  constructor(private readonly fileWriter: FileWriter) {}

  writeCustomers(fileName: string, customers: Customer[]) {
   // to implement !!! 
  }

  private customerToString = (customer: Customer) => {
    return `${customer.name},${customer.contactNumber}`;
  };
}

( We'll be exploring a slightly different flavor of Test Driven Development called Behavior Driven Development )

What separates this methodology from traditional T.D.D is the focus on getting a feature to work, and single-mindedly writing tests to achieve the same.

Personally, I aim to get the happy paths for a given feature passing, as soon as possible !

The are 3 things you should always keep in mind while formulating a B.D.D test

GIVEN ( the starting condition )

WHEN ( some action occurs )

THEN ( expected result achieved )

To further discuss the test cases for the behavior we expect when attempting to write a customer's information to a file, we can consider the following scenarios:

Case 1 :

given : there is no customer object in the customers array

when : we try to write customers to a file

then : nothing is written to a file ( i.e writeLine function is not called)

\\customer-file-writer.test.ts


 it(' will not write to file , when there is no customer', () => {

    //arrange
    const fileWriter = getFileWriter();

    const fileName = 'myfile.pdf';

    //act
    const sut = getCustomerFileWriter(fileWriter);

    sut.writeCustomers(fileName, []);

    //assert
    expect(fileWriter.writeLine).toBeCalledTimes(0);

  });

Helper functions :

  \\customer-file-writer.helper.ts

  export const getFileWriter = (): FileWriter => {
  return {
    writeLine: jest.fn((_fileName: string, _line: string) => {}),
  };
};

export const getCustomerFileWriter = (
  fileWriter: FileWriter
): ICustomerFileWriter => {
  return new CustomerFileWriter(fileWriter);
};

Result : ✅ Passing Test

🧐 Let's reflect on what we just did :

We are able to pass this test without even implementing any logic ! Great !

So now what would happen when we have 1 customer is the customer array ?

What do we expect in that case ?

Case 2 :

given : single customer object is present

when : we try to write the object info to file

then : only single object with the given info gets written

\\customer-file-writer.test.ts

 it('single customer object is present', () => {
    //arrange
    const fileWriter = getFileWriter();
    const customer = getCustomer('Glen', '32');
    const fileName = 'myfile.pdf';

    //act
    const sut = getCustomerFileWriter(fileWriter);
    sut.writeCustomers(fileName, [customer]);

    //assert

    expect(fileWriter.writeLine).toBeCalledTimes(1);
    expect(fileWriter.writeLine).toHaveBeenLastCalledWith(
      fileName,
      customerToString(customer)
    );
  });

Helper function :

//customer-file-writer.helper.ts

export const getCustomer = (name: string, contactNumber: string): Customer => {
  return new Customer(name, contactNumber);
};

export const customerToString = (customer: Customer) => {
  return `${customer.name},${customer.contactNumber}`;
};

❌ Now if you try to run the test , you'll encounter a test failure .

To mitigate that you'll have to write the least possible code in CustomerFileWriter to get the test passing

Before Modification :  customer-file-writer.ts

//customer-file-writer.ts

export class CustomerFileWriter  {
  constructor(private readonly fileWriter: FileWriter) {}

  writeCustomers(fileName: string, customers: Customer[]) {
 // to implement !!! 
  }

  private customerToString = (customer: Customer) => {
    return `${customer.name},${customer.contactNumber}`;
  };
}

\\ Modified :  customer-file-writer.ts

export class CustomerFileWriter implements ICustomerFileWriter {
  constructor(private readonly fileWriter: FileWriter) {}

  writeCustomers(fileName: string, customers: Customer[]) {

   // this is the single implementation change we make

 this.fileWriter.writeLine(fileName, this.customerToString(customers[0]));

   //

  }

  private customerToString = (customer: Customer) => {
    return `${customer.name},${customer.contactNumber}`;
  };
}

Result : ✅ Passing test !

🧐 Let's reflect on what we did :

We changed a single line , and wrote a single customer's information to a file .

Will this work for multiple customers ?

Case 3 :

given : multiple customer objects are present

when : we try to write the objects info to file

then : the exact number and the exact order of customers are written to file

\\ customer-file-writer.test.ts

 it.each([
    {
      customers: createCustomers(3),
    },
    {
      customers: createCustomers(12),
    },
  ])(
    '$customers.length customers info gets written , in the proper order ',
    ({ customers }) => {

   //arrange
      const fileWriter = getFileWriter();
      const fileName = 'narnia.ts';


     //act
      const sut = getCustomerFileWriter(fileWriter);

      sut.writeCustomers(fileName, customers);

      //assert
      assertCustomersHaveBeenWritten(fileWriter, fileName, customers);

  //has same number of items as the number of customers

      expect(fileWriter.writeLine).toHaveBeenCalledTimes(customers.length);

// items written in same order , i.e last item written last 

      expect(fileWriter.writeLine).toHaveBeenLastCalledWith(
        fileName,
        `${customers[customers.length - 1].name},${
          customers[customers.length - 1].contactNumber
        }`
      );
    }

Helper Function :

  //customer-file-writer.helper.ts

  export const createCustomers = (count: number) => {
  const customers: Customer[] = [];

  for (let i = 1; i <= count; i++) {
    customers.push(getCustomer(i + '', i + ''));
  }

  return customers;
};

❌ This again results in a test failure

Now, let's again think about the least amount of code we can write to make the tests pass .

\\ Modified :  customer-file-writer.ts


export class CustomerFileWriter implements ICustomerFileWriter {
  constructor(private readonly fileWriter: FileWriter) {}

  writeCustomers(fileName: string, customers: Customer[]) {

 // we modified this line : this.fileWriter.writeLine(fileName, this.customerToString(customers[0]));

 // rather than writing a single customer , this time , we write multiple customers 

    customers.forEach((customer) => {
      this.fileWriter.writeLine(fileName, this.customerToString(customer));

    });

  }  }

Result : ✅ Our tests for multiple customer pass 🔥🔥

That's all for now !

Stay tuned for when our product manager arrives with a new set of modifications for our Customer File Writer feature .

We'll have to modify and adapt to the new requrements , and ensure we do the least amount of modification to our code and keep our implementation SOLID compliant .

Click Here : GitHub Code Repo

Clean Architecture: Notes Backend in Node - Typescript

Chiranjeev Thomas — Mon, 18 Sep 2023 08:48:10 +0000

I hate complicated code! 😠

But do you know what I absolutely despise ~~from the depths of my cold, black heart~~ ?

" Needlessly Complicated Code " - That is the worst !! 🤬

An abomination of the highest order, I tell you !!!

So, you can imagine the horror of me seeing my codebase mutate into a quagmire
of interconnected code segments, i.e. files with a needlessly long list of dependencies that would break if I even looked at them the wrong way .It was a mess !!

So, what did I do next? I started researching Software Architecture.
I was looking for something that would produce decoupled code and give the added advantage of helping us migrate to microservices , if the need arose.

Long story short, I decided to go with Clean Architecture

Why you ask? Well, you can read it all about here : Embracing Clean Architecture: A Journey to Better Code

Let's now look into the fundamentals of Clean Architecture before trying to implement it for a simple Notes App

( Why a simple notes app? Cause, understanding clean architecture is hard enough … If we add more complexity, it would end up being incomprehensible for someone getting introduced to clean architecture for the first time )

Clean Architecture stands on the following pillars:

1️⃣ Inversion of Control ( Dependency Inversion )
2️⃣ Separation of Concerns ( Software Divided into layers - Presentation, Data, Application, Domain )
3️⃣ One-way flow of data ( From the outer layer to the inner layer, with the inner layers knowing nothing about the outer layers)

* * You can read about Clean Architecture in detail on : Uncle Bob's Website

I found this to be the simplest way to visualise Clean Architecture

( WHAT'S GREAT ABOUT THIS PICTURE IS THAT YOU CAN DIRECTLY TRANSLATE IT TO CODE )

main.ts

A look at our Project`s Directory Structure :

/src │── main.ts │── server.ts │── presentation │ └── routers │ └── notes-router.ts ├── domain │ ├── interfaces │ │ ├── repositories │ │ │ └── notes-repository.ts │ │ └── use-cases │ │ └── notes │ │ ├── create-note-use-case.ts │ │ ├── delete-note-use-case.ts │ │ ├── get-all-notes-use-case.ts │ │ ├── get-one-note-use-case.ts │ │ └── update-note-use-case.ts │ ├── models │ │ └── note.ts │ ├── repositories │ │ └── notes-repository.ts │ └── use-cases │ └── notes │ ├── create-note.ts │ ├── delete-note.ts │ ├── get-all-notes.ts │ ├── get-one-note.ts │ └── update-note.ts └── data ├── interfaces │ └── data-sources │ ├── nosql-database-wrapper.ts │ └── note-data-source.ts └── data-sources ├── mongodb └── mongodb-notes-data-source.ts

Let's start with our first use case test : [ Create Note ]

(Observe how few dependencies we have in our test file )

In each Test File, we are going to test the implementation of a Single Unit of Test ( SUT ), and are going to mock all the related dependencies

So in the case of the create note use case our SUT is the implementation of the create note use case interface ,i.e : the CreateNote class , and we have a single dependency to mock : NotesRepository

When we try to execute this file, we'll encounter failure immediately, as nothing has been implemented as yet! That's great, and it's by design … as we'll be practising the TDD way of doing things.
The great thing about following Clean Architecture is that it allows you to apply TDD practices from the get-go and in a very convenient way. The whole system of Clean Architecture promotes separation of concerns and dependency injection, which are great for testing, as mocks can be easily created and injected into a SUT

So, let's get started by defining the CreateNotesUseCase Interface

Now, we observe that we need to define 2 more types to work with the Create Note Use Case Interface.

These 2 types, namely the NoteRequestModel and NoteResponseModel describe the format of the input data that are supplied to the CreateNoteUseCase's execute method and the format of the data we'll get in response to saving it to the Database using the NotesRepository abstraction.

Let's quickly define these 2 types :

Great, now we need to mock our singular dependency for the create note use case : ( NotesRepository )
The NotesReposity interface would provide the methods to CREATE, READ, UPDATE and DELETE notes.
Let's define the NotesRepository interface before mocking it :

Finally , it's time for us to create the NotesRepository mock , and a helper function called getMockNotesRepository

Another helper required to run our test :

Now, we need to define our SUT ( the concrete implementation of the CreateNoteUseCase )

With all the setup done, we can finally go ahead and run our test!

And, we get a passing test :

What's next? Well as an assignment, go ahead and try to implement the rest of the use cases ( DeleteNoteUseCase, UpdateNoteUseCase, GetNotesUseCase, GetOneNoteUseCase ).

Do follow the same TDD methodology while implementing your tests

We'll meet again and test the NotesRepository, till then … Adios !!

You can view the complete code and the repository with all test cases implemented over here: GutHub Repo

My blog is inspired by a number of other blogs on the same subject, which are as follows :

1 . Clean Architecture Contacts
2 . Clean Architecture Fundamentals
3.TDD Fundamentals

DEV Community: Chiranjeev Thomas

LLD : N X N Tic Tac Toe with O(1) checks

LowLevelDesign #TicTacToe #Python #GameDevelopment #OOP #DesignPatterns #Coding #SoftwareEngineering #GitHub #Tech #Interviews

🚀 The Importance of Understanding Social Networking Basics 🚀

🌐 Application Routes

🔑 Auth Routes

👤 User Routes

📝 Post Routes

📋 Self Routes

My First Tech Startup ... An Accident?

Prelude :

Simply put , the problem that I was trying to solve was the lack of digital resources for students to study for upcoming exams.

To address this problem, I decided to create a website that would host digitally scanned exam papers.

I used my own Google Drive to store the scanned papers, and I made it simple for students to access them through the website.

The website was designed to be user-friendly and easy to navigate, mobile responsive , with a clean and modern design.

The website gained a lot of traction since its launch.

It has received positive reviews from students , who have found it to be a helpful resource for their studies and their careers.

The website has also received favorable reviews from users on Quora and Facebook.

However, the website did not generate any sponsorships / income for me. ( but then , that was never the objective )

In conclusion, my startup project was a success ( or at least how i defined success for this particuar project ) .

I was able to solve a real-world problem by creating a simple website that hosted digitally scanned question papers that catered to the needs of a few hundred students .

Embracing Clean Architecture: A Journey to Better Code

The Road to Clean Architecture

GPT Prompts: A Next.js 13 App ( App Router )

System Design (Comprehensive List)

Objectives :

Key Concepts ( Pre - Req's )

Framework To Design Systems in System Design Interviews

Designing Distributed Systems (From Scratch)

REST API USING TYPESCRIPT ( CRUD )

In this Article, we'll delve into the process of creating a RESTful API that implements CRUD operations using JWT for authorization

An Overview Of The Project :

18. ✅ We'll be using JWT to provide Authorization / Authentication in the app

The API we'll be creating :

Let's first talk about the USER MODEL

Now , let's look at the registerUser controller

Steps taken to register a user :

Let's turn our attention to the multiple imports we have at the top of the resgisterUser code ( p.s : this is a bad sign , as the number of imports shows how coupled our code is with other modules )

Validation using Zod :

Custom Error Handler :

You can View the Complete Project on my GitHub profile : here

Test Driven Development ( TDD )

Meanwhile, you can try your hand at TDD by attempting any of the following exercises: TDD Buddy Exercises

Character Copy Kata ( Test Driven Development )

This Kata expects you to create a character copier class that reads characters from a source and copies them to a destination. The class must copy and write one character at a time

To do this, you need to create a Copier class that takes in a Source and a Destination

First, lets identify all the possible tests you could think of for this scenario

Now let's look at the code for our concrete Copy Class

In a similar format , we impelement all the rest of the test cases too

👍 Great !! This concludes our tutorial .

If you want , you can have a look at the souce code on GitHub : Click Here To View Source Code

Writing User Info to files in CSV format ( TDD Kata ) - Part 2

Summary :

Writing User Info to files in CSV format ( TDD Kata ) - Part 1

Summary :

In this specific post , we'll be concerntating on the 1st task and getting things set up !

First Let's look at the UML Diagram for the particular situation :

What separates this methodology from traditional T.D.D is the focus on getting a feature to work, and single-mindedly writing tests to achieve the same.

To further discuss the test cases for the behavior we expect when attempting to write a customer's information to a file, we can consider the following scenarios:

Clean Architecture: Notes Backend in Node - Typescript

I hate complicated code! 😠

Let's now look into the fundamentals of Clean Architecture before trying to implement it for a simple Notes App

I found this to be the simplest way to visualise Clean Architecture

A look at our Project`s Directory Structure :

Let's start with our first use case test : [ Create Note ]

In each Test File, we are going to test the implementation of a Single Unit of Test ( SUT ), and are going to mock all the related dependencies

So, let's get started by defining the CreateNotesUseCase Interface

Let's quickly define these 2 types :

Finally , it's time for us to create the NotesRepository mock , and a helper function called getMockNotesRepository

Another helper required to run our test :

Now, we need to define our SUT ( the concrete implementation of the CreateNoteUseCase )

And, we get a passing test :

Do follow the same TDD methodology while implementing your tests

We'll meet again and test the NotesRepository, till then … Adios !!

Now , let's look at the `registerUser` controller

Let's turn our attention to the multiple imports we have at the top of the `resgisterUser` code ( p.s : this is a bad sign , as the number of imports shows how coupled our code is with other modules )