Remote work newsletter

Building a Music SaaS

Sat, 04 Jan 2025 14:50:51 GMT

Building a Music SaaS

In this article, we will explore the process of building a music Software as a Service (SaaS) platform that enables creators to engage their audience by allowing them to vote on the music played during live streams. This comprehensive examination will cover both the conceptual framework and technical implementation involved in developing such a platform.

We will begin with an overview of the Music SaaS architecture, breaking it down into essential components such as user authentication, stream management, and audience interaction features. Following this, we will delve into the technical aspects of implementing these components using modern technologies, including database management, API integrations, and real-time streaming capabilities.

For those who prefer visual learning, a video presentation of this article's content is available on YouTube at

The article will cover everything from user experience design and security considerations to video playback and voting mechanisms, offering valuable insights into the infrastructure and workflows that underpin successful music streaming platforms. By understanding these elements, developers will be better equipped to create engaging and interactive experiences that meet the needs of users in the evolving landscape of digital music consumption.

To follow along with the code examples in this lecture, please refer to the GitHub repository https://github.com/code100x/muzer/commit/76be1650935af46e4d92fee69ef892b4bd98a3e0

Introduction to the Music SaaS Platform Project

Context and Motivation

The following blog post aims to provide a comprehensive overview of the process involved in developing a music SaaS (Software as a Service) platform. This project was initiated with the goal of rebuilding a system that was originally developed in college. The primary motivations behind this endeavor were twofold:

Live Streaming: The creator plans to engage in live streaming activities, and this platform will become essential for selecting music during these events.
Super 30 Cohort: The project is also aligned with the upcoming Super 30 cohort, an on-site program where this product will likely be highly useful.

Project Structure and Objectives

The video is divided into nine parts, each focusing on a specific aspect of the development process. Here is a detailed breakdown of the project structure:

Part 0: High-Level Context
- This part provides an overview of the entire project, including its objectives and the steps involved in the development process.
Part 1: Initializing the Application
- The first part involves initializing the application, which is a relatively straightforward step.
Part 2: Adding Authentication
- In this part, the focus is on adding authentication to the application using Next.js.
Part 3: Designing the Schema
- The third part is dedicated to designing the schema, which involves understanding the structure of the database.
Part 4: Back End Development
- This section covers the back-end development of the application, including setting up the server and handling requests.
Part 5: Front End Development
- The front-end development is a critical component, and it took the most time to complete. This part involves creating the user interface and user experience.
Part 6: Polishing and Testing
- In this phase, the focus is on adding last-minute polishes to ensure there are no vulnerabilities and to cover as many edge cases as possible.
Part 7: Deployment
- The final part involves deploying the application on the internet, making it accessible to users.

Technical Details

Database Schema: The database schema is a crucial aspect of the project. It defines the structure of the database, including tables, columns, and relationships between them.
Authentication: The use of Next.js for authentication ensures that only authorized users can access the application.
Front End Development: The front-end development involves creating a user-friendly interface that interacts with the back-end to provide a seamless user experience.
Polishing and Testing: This phase includes various testing methodologies to ensure the application is stable and secure. It also involves fixing any bugs or issues that arise during testing.

Future Development

Open Issues: The creator has identified a few issues that were not addressed during the initial development phase. These issues are documented in the repository, and contributors are encouraged to pick them up and resolve them.
Community Involvement: The project aims to become a useful platform for creators, and the community is invited to contribute to its development.

Conclusion

The music SaaS platform project is a comprehensive endeavor that involves multiple stages of development, from high-level context to deployment. By understanding the technical details and objectives of each part, developers can better appreciate the complexity and scope of such projects. The project's open nature and community involvement make it an excellent example of collaborative development in the tech industry.

This blog post provides a detailed overview of the music SaaS platform project, covering every aspect mentioned in the transcript segment. It sets the context, explains the motivations, and outlines the technical details involved in each part of the project. The post also highlights the importance of community involvement and future development opportunities.

Part 2: Initializing the Application

Introduction

In the previous section, we discussed the context and motivation behind our music SaaS platform. This section delves into the initial setup of the application, highlighting the key components and technologies involved.

Problem Statement and Inspiration

The idea for our music SaaS platform was inspired by a project from our college days. During this time, we worked on an application called "M" within the SDS Labs campus group. The application was a gated website where a few lab members could choose from various audio or video tracks. These tracks were scripted in-house and stored on a server, not using YouTube as we do today. The website displayed recently played tracks and allowed users to search for specific music tracks using a search bar. Once a track was selected, it would enter a pending queue where members could decide which track to play next. Tracks with more upvotes would be pushed to the top of the queue, ensuring that the most popular tracks were played next.

This collaborative music player was useful for lab sessions where music was played continuously through speakers. However, it had its limitations, such as not everyone enjoying the same type of music. For instance, Punjabi songs might not be everyone's cup of tea, leading to potential conflicts.

Modernizing the Idea

Fast forward to today, we aim to modernize this concept by integrating it into a more sophisticated SaaS platform. The primary goal is to create a platform where users can choose the next song to play during live streaming sessions, such as on YouTube. This would involve users upvoting their preferred tracks, ensuring that the most popular ones get played. Additionally, we plan to introduce a payment system where users can pay to have their chosen song played immediately, even if it's not currently at the top of the queue.

Use Cases

Colleges and University Groups: The platform can be highly useful for college groups and university settings where music is often played in common areas. It provides a democratic way to choose the next song, ensuring that everyone has a say in what gets played.
Live Streaming: During live streaming sessions on platforms like YouTube, users can interact with the stream by choosing the next song to play. This enhances viewer engagement and provides a more interactive experience.
On-Site Development Programs: We are planning to implement this platform in our upcoming on-site development program, Super 30. This program involves a batch of 30 people who will learn and develop for 3-4 hours each day. The music room will be a central part of this program, allowing participants to code while enjoying music chosen democratically by the group.

Technical Requirements

Frontend Framework: We will use Next.js for the frontend development, which is well-suited for building server-side rendered applications with React.
Database Schema: The database schema will need to handle real-time calculations and updates efficiently. This might involve using PostgreSQL with Prisma for database management.
Real-Time Updates: To handle real-time updates, we will need to implement a mechanism for updating the leaderboard in real-time. This could involve using WebSockets or long polling, although we have decided to keep it simple with long polling for now.
Payment Integration: If we decide to implement payment verification, we will need to use Web3.js and Solana wallet adapter for handling cryptocurrency transactions. However, this part is still under consideration and might not be implemented initially.
UI Design: For the UI design, we will use Tailwind CSS and possibly Shad CN to make the components look visually appealing.
API Integration: We will need to integrate with APIs like YouTube and Spotify to handle track selection and ID extraction. Ensuring there are no collisions where the same song is pushed twice is crucial.
Real-Time Leaderboards: Implementing real-time leaderboards is a challenging task, especially if we have a large number of tracks. This might require building something similar to a real-time leaderboard, which is a hard problem to solve.

Conclusion

In this section, we have outlined the initial setup of our music SaaS platform, including its inspiration, use cases, and technical requirements. By understanding these components, we can appreciate the complexity and scope of such projects. The platform's open nature and community involvement make it an excellent example of collaborative development in the tech industry. In the next sections, we will delve deeper into the authentication process, database schema design, backend development, frontend development, and deployment of the application.

Part 3: Initializing the Application

Initializing a Next.js application is a crucial step in the development process. This section will guide you through the process of setting up a new Next.js project, including the necessary commands and configurations.

Step 1: Initializing the Next.js Project

To begin, you need to create a new Next.js project. You can do this using the create-next-app command line tool. Here are the steps to initialize a new project:

Open Terminal:
- Ensure you have Node.js and npm installed on your system. If you're using Windows, consider using Git Bash or the Windows Subsystem for Linux (WSL) for better compatibility with UNIX-specific commands.
Create a New Project Directory:
- Navigate to the directory where you want to create your project.
- Run the following command to create a new Next.js project:

npx create-next-app@latest my-next-project --use-pnpm --example ""

- This command uses the create-next-app tool to set up a new Next.js project with the specified template. The -use-pnpm flag ensures that pnpm is used as the package manager, which can be beneficial for those experiencing issues with npm locally.
Navigate to the Project Directory:
- Once the installation is complete, navigate to the newly created project directory:

cd my-next-project

Start the Development Server:
- To start the development server, run:

pnpm dev

- This command will start the Next.js development server on port 3000. You can verify this by opening

http://localhost:3000

- in your browser.

Customizing the Project Setup

When initializing the project, you may be prompted with several options. Here’s a breakdown of the common configurations:

Project Name: You can specify a name for your project.
Use TypeScript: You can choose to use TypeScript for your project.
Use ESLint: You can enable ESLint for code linting.
Use Tailwind CSS: You can enable Tailwind CSS for styling.
Source Directory: You can choose to keep your application code in a src directory.
App Router: You can use the App Router instead of the Pages Router.
Customize Imports: You can configure the import alias (@/* by default).

Cleaning Up the Initial Project

After initializing the project, you may want to clean up the initial files to better understand the structure and start from scratch. Here’s how you can do it:

Remove Default Text:
- Open the pages/index.tsx file and remove any default text.
- This will help you start with a clean slate and ensure that you understand how to add content to your pages.
Remove Global Styles:
- Open the styles/global.css file and remove all styles except for the Tailwind CSS imports.
- This will help you understand how to use Tailwind CSS for styling your components.
Add a Basic Greeting:
- Add a simple h1 element to the pages/index.tsx file to verify that the project is set up correctly.
Run the Development Server:
- Navigate to the app directory and run:

pnpm dev

- This will start the development server, and you should see a basic Next.js page with your greeting.

By following these steps, you can ensure that your Next.js project is set up correctly and you are ready to proceed with adding authentication, designing the schema, and other subsequent steps in the development process.

Part 4: Adding Authentication Using Next.js

Introduction to Authentication

Authentication is a crucial aspect of any web application, ensuring that only authorized users can access and interact with the platform. In this section, we will delve into the process of adding authentication to our music platform using Next.js, focusing on integrating Google login.

Setting Up Next.js for Authentication

To begin, we need to add Next.js as a dependency to our project. Since we are using pnpm, we can run the following command:

pnpm add next

If you are using npm, you would use:

npm install next

If you are using yarn, you would use:

yarn add next

Initializing Routes

After adding Next.js, we need to initialize the routes. However, we are not using the Pages router; instead, we are using the new app router. This is evident from the file structure of our project, which includes an app folder instead of a Pages folder. The app router is used in Next.js 13 and above, and it requires us to define route handlers.

Hands on Coding Implementation

1] Authentication and AppBar Components

Defining Route Handlers

To handle requests to the /api endpoint, we need to create a specific route handler. This involves creating a folder structure like app/api/[...slug].ts and defining a handler function inside it. The handler function will catch all requests to the /api endpoint and handle them accordingly.

Using Google Authentication Provider

Next.js provides various providers for authentication, including Google. To use the Google authentication provider, we need to import it from next-auth/providers/google.

Set Environment Variables:

Create an .env file in the root of your project to store the Google client ID and client secret.

GOOGLE_CLIENT_ID=your-client-id
GOOGLE_CLIENT_SECRET=your-client-secret

1. Authentication Route: `app/api/auth/[...nextauth]/route.ts`

This file sets up the authentication logic using NextAuth with Google as the provider.

import GoogleProvider from "next-auth/providers/google";
import NextAuth from "next-auth";
import { prismaClient } from "@/app/lib/db";

const handler = NextAuth({
    providers: [
        GoogleProvider({
            clientId: process.env.GOOGLE_CLIENT_ID ?? "",
            clientSecret: process.env.GOOGLE_CLIENT_SECRET ?? ""
        })
    ],
    secret: process.env.NEXTAUTH_SECRET ?? "secret",
    callbacks: {
        async signIn(params) {
            if (!params.user.email) {
                return false; // Prevent sign-in if email is not available
            }

            try {
                await prismaClient.user.create({
                    data: {
                        email: params.user.email,
                        provider: "Google" // Store the provider information
                    }
                });
            } catch (e) {
                // Handle any errors that occur during the user creation
            }
            return true; // Allow sign-in if everything is successful
        }
    }
});

export { handler as GET, handler as POST };

Key Components Explained:

Providers: The GoogleProvider is configured with clientId and clientSecret, which are retrieved from environment variables. This allows users to authenticate using their Google accounts.
Secret: The NEXTAUTH_SECRET is used to encrypt session tokens, ensuring secure communication between the client and server.
Callbacks:
- signIn: This callback is invoked when a user attempts to sign in. It checks if the user's email is present. If not, it returns false, preventing the sign-in. If the email is present, it tries to create a new user in the database using Prisma. If successful, it returns true, allowing the sign-in process to continue.
Exporting Handler: The handler is exported for handling both GET and POST requests, making it versatile for various authentication actions like signing in and signing out.

2. AppBar Component: `app/components/Appbar.tsx`

The AppBar component provides a user interface for signing in and out of the application.

"use client";
import { signIn, signOut, useSession } from "next-auth/react";
import Link from "next/link";
import { Button } from "@/components/ui/button";

export function Appbar() {
    const session = useSession(); // Get session data

    return (
        
            
                Muzer
            
            
                {session.data?.user ? (
                    
                ) : (
                    
                )}
            
        
    );
}

Key Components Explained:

useSession Hook: This hook retrieves the current session state, which contains user information if logged in.
Conditional Rendering:
- If a user is logged in (session.data?.user is truthy), a "Logout" button is displayed. Clicking this button will invoke the signOut function to log the user out.
- If no user is logged in, a "Signin" button is shown. Clicking this button invokes the signIn function, which triggers the authentication flow.
Styling: The component uses Tailwind CSS classes for styling, ensuring a responsive and visually appealing interface.

3. Providers Component: `app/providers.tsx`

This component wraps the application in a session provider context.

"use client";

import { SessionProvider } from "next-auth/react";

export function Providers({ children }: { children: React.ReactNode }) {
    return {children};
}

Key Components Explained:

SessionProvider: This component provides session context to its children, allowing any component within the tree to access session data via hooks like useSession.

4. Layout Component: `app/layout.tsx`

The layout component integrates all parts of the application together.

import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";
import { Providers } from "./provider";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
    title: "Create Next App",
    description: "Generated by create next app",
};

export default function RootLayout({ children }: Readonly<{ children: React.ReactNode; }>) {
    return (
        
            
                
                    {children}
                
            
        
    );
}

Key Components Explained:

Metadata: Defines metadata for SEO purposes.
Root Layout:
- Wraps all child components with , ensuring that session management is available throughout the application.
- Uses Google Fonts for styling and applies global CSS for consistent design.

These components collectively establish a robust authentication system using NextAuth with Google as a provider while providing an intuitive user interface for managing sessions. The use of Prisma for database interactions ensures that user data is stored securely and efficiently.

2] Database Schemas & Management

This section provides a detailed explanation of the Prisma schema file (prisma/schema.prisma), the API routes for managing streams (app/api/streams/route.ts), and the database client setup (app/lib/db.ts). These components work together to define the data structure and interactions for the music SaaS platform.

1. Prisma Schema: `prisma/schema.prisma`

The Prisma schema is a crucial part of the application, defining the data models, their relationships, and how they interact with the database.

// This is your Prisma schema file,
// learn more about it in the docs: 

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id        String      @id @default(uuid())
  email     String      @unique
  provider  Provider
  streams   Stream[]    @relation("user")
  upvotes   Upvote[]
}

model Stream {
  id            String      @id @default(uuid())
  type          StreamType
  url           String
  extractedId   String
  title         String      @default("")
  smallImg      String      @default("")
  bigImg        String      @default("")
  active        Boolean     @default(true)
  played        Boolean     @default(false)
  playedTs      DateTime?
  createAt      DateTime    @default(now())
  upvotes       Upvote[]
  userId        String
  user          User        @relation(fields: [userId], references: [id], name: "user")
  currentStream CurrentStream?
}

model CurrentStream {
  userId       String    @id
  streamId     String?   @unique
  stream       Stream?   @relation(fields: [streamId], references: [id])
}

model Upvote {
  id        String      @id @default(uuid())
  userId    String
  streamId  String
  user      User        @relation(fields: [userId], references: [id])
  stream    Stream      @relation(fields: [streamId], references: [id], onDelete: Cascade)
  @@unique([userId, streamId])
}

enum StreamType {
  Spotify
  Youtube
}

enum Provider {
  Google
}

Key Components Explained:

Generator:
- The generator client block specifies that Prisma Client will be generated using JavaScript. This client allows interaction with the database through defined models.
Datasource:
- The datasource db block defines the database connection. It specifies PostgreSQL as the database provider and retrieves the connection URL from an environment variable (DATABASE_URL).
Models:
- User: Represents users of the application.
  - id: Unique identifier for each user.
  - email: Unique email for authentication.
  - provider: Indicates which authentication provider (e.g., Google) was used.
  - streams: A one-to-many relationship with streams created by this user.
  - upvotes: A one-to-many relationship with upvotes associated with this user.
- Stream: Represents a music stream.
  - id: Unique identifier for each stream.
  - type: Specifies whether the stream is from Spotify or YouTube (using the StreamType enum).
  - url, extractedId, title, etc.: Various attributes related to the stream.
  - userId: Foreign key linking to the creator of the stream (User).
  - currentStream: Optional relation to track if this stream is currently active.
- CurrentStream: Tracks which stream is currently being played for a specific user.
  - Contains foreign keys linking to both User and Stream.
- Upvote: Represents a user's upvote on a stream.
  - Contains foreign keys linking to both User and Stream, ensuring that each user can only upvote a specific stream once (enforced by the unique constraint on [userId, streamId]).
Enums:
- StreamType: Enum defining possible types of streams (Spotify or YouTube).
- Provider: Enum defining possible authentication providers (Google).

2. API Route for Streams: `app/api/streams/route.ts`

To add a stream, we need to create an endpoint that accepts a POST request containing the necessary data. The data should include the creator ID and the URL of the stream. We will use Zod to validate the incoming data and ensure it conforms to our schema.

Imports and Constants

import { prismaClient } from "@/app/lib/db";
import { NextRequest, NextResponse } from "next/server";
import { z } from "zod";
//@ts-ignore
import youtubesearchapi from "youtube-search-api";
import { YT_REGEX } from "@/app/lib/utils";
import { getServerSession } from "next-auth";

const CreateStreamSchema = z.object({
    creatorId: z.string(),
    url: z.string()
});

const MAX_QUEUE_LEN = 20;

Imports:
- prismaClient: Used to interact with the database via Prisma ORM.
- NextRequest and NextResponse: Used to handle HTTP requests and responses in Next.js.
- z: A validation library (Zod) used for schema validation.
- youtubesearchapi: A library for fetching YouTube video details.
- YT_REGEX: A regular expression for validating YouTube URLs.
- getServerSession: A function to retrieve the current session using NextAuth.
Constants:
- CreateStreamSchema: Defines the expected structure of the request body for creating a stream, requiring a creatorId and a url.
- MAX_QUEUE_LEN: Sets a limit on the number of active streams a user can have.

POST Request Handler

export async function POST(req: NextRequest) {
    try {
        const data = CreateStreamSchema.parse(await req.json());
        const isYt = data.url.match(YT_REGEX);
        if (!isYt) {
            return NextResponse.json({
                message: "Wrong URL format"
            }, {
                status: 411
            });
        }

        const extractedId = data.url.split("?v=")[1];

        const res = await youtubesearchapi.GetVideoDetails(extractedId);

        const thumbnails = res.thumbnail.thumbnails;
        thumbnails.sort((a: {width: number}, b: {width: number}) => a.width < b.width ? -1 : 1);

        const existingActiveStream = await prismaClient.stream.count({
            where: {
                userId: data.creatorId
            }
        });

        if (existingActiveStream > MAX_QUEUE_LEN) {
            return NextResponse.json({
                message: "Already at limit"
            }, {
                status: 411
            });
        }

        const stream = await prismaClient.stream.create({
            data: {
                userId: data.creatorId,
                url: data.url,
                extractedId,
                type: "Youtube",
                title: res.title ?? "Cant find video",
                smallImg: (thumbnails.length > 1 ? thumbnails[thumbnails.length - 2].url : thumbnails[thumbnails.length - 1].url) ?? "",
                bigImg: thumbnails[thumbnails.length - 1].url ?? ""
            }
        });

        return NextResponse.json({
            ...stream,
            hasUpvoted: false,
            upvotes: 0
        });
    } catch(e) {
        console.log(e);
        return NextResponse.json({
            message: "Error while adding a stream"
        }, {
            status: 411
        });
    }
}

Key Components Explained:

Request Parsing and Validation:
- The request body is parsed as JSON, and the schema is validated using Zod. If validation fails, an error response is returned.
YouTube URL Validation:
- The URL is checked against the YT_REGEX to ensure it is a valid YouTube link. If it does not match, an error response is returned.
Extracting Video ID:
- The video ID is extracted from the URL by splitting it at "?v=".
Fetching Video Details:
- The YouTube API is called to get details about the video using the extracted ID. This includes information like title and thumbnails.
Thumbnail Handling:
- Thumbnails are sorted by width to select appropriate images for display.
Active Stream Count Check:
- The current number of active streams for the creator is counted. If this exceeds the maximum allowed (MAX_QUEUE_LEN), an error response is returned.
Creating a New Stream:
- A new stream entry is created in the database using Prisma Client with relevant details such as user ID, URL, video title, and thumbnail images.
Successful Response:
- If successful, a JSON response containing the newly created stream data is returned, along with default values for upvotes and whether the user has upvoted.

GET Request Handler

export async function GET(req: NextRequest) {
    const creatorId = req.nextUrl.searchParams.get("creatorId");
    const session = await getServerSession();
    // TODO: You can get rid of the db call here
    const user = await prismaClient.user.findFirst({
        where: {
            email: session?.user?.email ?? ""
        }
    });

    if (!user) {
        return NextResponse.json({
            message: "Unauthenticated"
        }, {
            status: 403
        });
    }

    if (!creatorId) {
        return NextResponse.json({
            message: "Error"
        }, {
            status: 411
        });
    }

    const [streams, activeStream] = await Promise.all([
        await prismaClient.stream.findMany({
            where: {
                userId: creatorId,
                played: false
            },
            include: {
                _count: {
                    select: {
                        upvotes: true
                    }
                },
                upvotes: {
                    where: {
                        userId: user.id
                    }
                }
            }
        }),

        prismaClient.currentStream.findFirst({
            where: {
                userId: creatorId
            },
            include: {
                stream: true
            }
        })
    ]);

    return NextResponse.json({
        streams: streams.map(({_count, ...rest}) => ({
            ...rest,
            upvotes: _count.upvotes,
            haveUpvoted: rest.upvotes.length ? true : false
        })),
        activeStream
    });
}

Key Components Explained:

Query Parameters:
- The creatorId is retrieved from the query parameters of the request URL.
Session Handling:
- The session is retrieved using getServerSession(). If there is no authenticated user, a 403 Forbidden response is returned.
Error Handling:
- If no creatorId is provided in the request, an error response with status code 411 is returned.
Fetching Streams:
- Two asynchronous calls are made using Promise.all() to fetch both unplayed streams associated with the creator and the current active stream.
Data Inclusion:
- For each stream fetched, it includes counts of upvotes and checks if the current user has upvoted each stream.
Response Formatting:
- The response JSON includes all relevant stream details along with additional computed properties like total upvotes and whether the user has upvoted each stream.

The API route defined in app/api/streams/route.ts provides essential functionality for managing music streams in the application. It allows users to create new streams by validating YouTube URLs and storing relevant metadata in a database. Additionally, it retrieves existing unplayed streams and their associated data based on user authentication. This structure facilitates robust interaction between users and their music streams, enhancing overall engagement within the platform.

3. Database Client Setup: `app/lib/db.ts`

This file initializes Prisma Client for database interactions.

import { PrismaClient } from "@prisma/client";

export const prismaClient = new PrismaClient();
// this isn't the best; we should introduce a singleton here

Key Components Explained:

Prisma Client Instance:
- An instance of PrismaClient is created to interact with the database. This instance can be used throughout the application to perform CRUD operations on defined models.
Singleton Note:
- The comment suggests that implementing a singleton pattern would be beneficial to prevent multiple instances of Prisma Client from being created, which can lead to performance issues in serverless environments.

The combination of these files establishes a robust backend architecture for managing users, streams, and upvotes within the music SaaS platform. The schema defines clear relationships between entities, while API routes provide endpoints for creating and retrieving data efficiently. The use of validation libraries like Zod enhances input safety, ensuring that only valid data interacts with the database.

3] Downvote Upvote Stream Routes

This section provides a detailed explanation of the API routes for handling upvotes and downvotes on streams in the music SaaS platform. These routes interact with the database to manage user interactions with streams, specifically allowing users to upvote or downvote a stream.

1. Downvote Route: `app/api/streams/downvote/route.ts`

This file handles the logic for removing an upvote from a stream.

import { prismaClient } from "@/app/lib/db";
import { getServerSession } from "next-auth";
import { NextRequest, NextResponse } from "next/server";
import { z } from "zod";

const UpvoteSchema = z.object({
    streamId: z.string(),
})

export async function POST(req: NextRequest) {
    const session = await getServerSession();

    // TODO: You can get rid of the db call here
    const user = await prismaClient.user.findFirst({
        where: {
            email: session?.user?.email ?? ""
        }
    });

    if (!user) {
        return NextResponse.json({
            message: "Unauthenticated"
        }, {
            status: 403
        });
    }

    try {
        const data = UpvoteSchema.parse(await req.json());
        await prismaClient.upvote.delete({
            where: {
                userId_streamId: {
                    userId: user.id,
                    streamId: data.streamId
                }
            }
        });

        return NextResponse.json({
            message: "Done!"
        });
    } catch(e) {
        return NextResponse.json({
            message: "Error while upvoting"
        }, {
            status: 403
        });
    }
}

Key Components Explained:

Zod Schema:
- The UpvoteSchema defines the expected structure of incoming requests, requiring a streamId to identify which stream is being downvoted.
Session Handling:
- The session is retrieved using getServerSession(), which checks if the user is authenticated. If not, it returns a 403 status with an "Unauthenticated" message.
Database Interaction:
- The code attempts to find the user in the database based on their email. This is a point of improvement, as it could be optimized by using session information directly instead of making a database call.
Deleting an Upvote:
- If the user is authenticated, the code parses the request body and deletes the corresponding upvote from the database using Prisma Client. The deletion is based on a composite key (userId_streamId), ensuring that only the specific upvote by that user for that stream is removed.
Response Handling:
- If successful, it returns a success message. If there’s an error (e.g., invalid input), it catches the exception and returns an error message with a 403 status.

2. Upvote Route: `app/api/streams/upvote/route.ts`

To upvote a stream, we need to create an endpoint that accepts a POST request containing the stream ID. We will use the Prisma client to update the upvotes count for the specified stream.

This file handles adding an upvote to a stream.

import { prismaClient } from "@/app/lib/db";
import { getServerSession } from "next-auth";
import { NextRequest, NextResponse } from "next/server";
import { z } from "zod";

const UpvoteSchema = z.object({
    streamId: z.string(),
})

export async function POST(req: NextRequest) {
    const session = await getServerSession();

    // TODO: You can get rid of the db call here
    const user = await prismaClient.user.findFirst({
        where: {
            email: session?.user?.email ?? ""
        }
    });

    if (!user) {
        return NextResponse.json({
            message: "Unauthenticated"
        }, {
            status: 403
        });
    }

    try {
        const data = UpvoteSchema.parse(await req.json());
        await prismaClient.upvote.create({
            data: {
                userId: user.id,
                streamId: data.streamId
            }
        });

        return NextResponse.json({
            message: "Done!"
        });
    } catch(e) {
        return NextResponse.json({
            message: "Error while upvoting"
        }, {
            status: 403
        });
    }
}

Key Components Explained:

Zod Schema:
- Similar to the downvote route, this schema validates that incoming requests contain a valid streamId.
Session Handling:
- The session is again retrieved to check if the user is authenticated. If not, it returns a 403 status.
Database Interaction:
- After confirming authentication, it attempts to find the user in the database based on their email (again, this could be optimized).
Creating an Upvote:
- If validation passes and the user exists, it creates a new entry in the upvotes table using Prisma Client. This associates the current user with the specified stream via their IDs.
Response Handling:
- Returns a success message upon successful creation or an error message if any issues arise during processing.

Comparison with Stream Management Route (`app/api/streams/route.ts`)

The app/api/streams/route.ts file manages streams by allowing users to create new streams and retrieve existing ones. Here’s how it relates to upvotes and downvotes:

User Interaction:
- All three routes (creating streams, upvoting, and downvoting) require authentication to ensure that only logged-in users can perform actions.
- The streams route allows users to create new streams, while upvotes and downvotes manage interactions with those streams.
Data Integrity:
- Each route interacts with the same underlying data models defined in Prisma (User, Stream, Upvote). This ensures that changes made by one route are reflected across others.
- The upvote and downvote routes specifically ensure that users can only interact with streams they have access to, maintaining data integrity through foreign key relationships.
Error Handling:
- All routes implement error handling for both authentication failures and operational issues (like invalid input or database errors). This consistency improves robustness and user experience.
Optimizations:
- Both upvote routes have a commented note suggesting that unnecessary database calls can be eliminated by leveraging session information directly instead of querying for user details each time.

The upvote and downvote API routes provide essential functionality for managing user interactions with streams in the music SaaS platform. They ensure that users can express their preferences while maintaining robust authentication and error handling practices. Together with the stream management route, they form a cohesive system that enhances user engagement within the platform.

4] Building Landing Page & Components

This section provides a detailed explanation of the landing page (app/page.tsx) and its related components (app/components/Appbar.tsx, app/components/Redirect.tsx, and app/components/StreamView.tsx). These components work together to create the main user interface and functionality of the music SaaS platform.

In the development of the music platform, the front end plays a crucial role in creating a user-friendly interface. This section will delve into the technical details of designing and implementing the front end using Next.js and Tailwind CSS.

Landing Page: `app/page.tsx`

The landing page serves as the main entry point for users visiting the application. It showcases the platform's features and encourages users to sign up or learn more about the service.

import Link from "next/link";
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Users, Radio, Headphones } from "lucide-react";
import { Appbar } from "./components/Appbar";
import { Redirect } from "./components/Redirect";

export default function LandingPage() {
  return (
    
      
      
      {/* ... */}
    
  );
}

Key Components Explained:

Background: The page uses a gradient background to create a visually appealing layout.
Appbar: The Appbar component is included, providing a consistent navigation bar across the application.
Redirect: The Redirect component is used to redirect authenticated users to the dashboard page, ensuring they don't see the landing page if they are already logged in.

The landing page is divided into several sections:

Hero Section:
- Displays a catchy headline and a brief description of the platform's main feature: letting fans choose the music.
- Includes two buttons: "Get Started" and "Learn More" to guide users towards sign-up or learning more about the service.
Key Features Section:
- Highlights three key features of the platform: fan interaction, live streaming, and high-quality audio.
- Each feature is represented by an icon and a short description.
Sign-Up Section:
- Encourages users to sign up for the service by providing an email input field and a "Sign Up" button.
- Includes a call-to-action message emphasizing the platform's ability to transform streams.
Footer:
- Displays copyright information and links to the terms of service and privacy policy.

Appbar Component: `app/components/Appbar.tsx`

The Appbar component provides a consistent navigation bar across the application. It includes the platform's name and handles user authentication.

"use client";
import { signIn, signOut, useSession } from "next-auth/react";
import Link from "next/link";
import { Button } from "@/components/ui/button";

export function Appbar() {
    const session = useSession();

    return (
        
            
                Muzer
            
            
                {session.data?.user ? (
                    
                ) : (
                    
                )}
            
        
    );
}

Key Components Explained:

Conditional Rendering: The Appbar conditionally renders a "Logout" button if the user is logged in or a "Signin" button if the user is not logged in.
Sign-In and Sign-Out: The "Signin" and "Logout" buttons trigger the sign-in and sign-out actions using the signIn and signOut functions provided by NextAuth.

Redirect Component: `app/components/Redirect.tsx`

The Redirect component checks if a user is logged in and redirects them to the dashboard page if they are.

"use client";

import { useSession } from "next-auth/react";
import { useRouter } from "next/navigation";
import { useEffect } from "react";

export function Redirect() {
    const session = useSession();
    const router = useRouter();

    useEffect(() => {
        if (session?.data?.user) {
            router.push("/dashboard");
        }
    }, [session]);

    return null;
}

Key Components Explained:

Session Data: The component retrieves the session data using the useSession hook provided by NextAuth.
Redirect Logic: If the user is logged in (session?.data?.user), the component uses the useRouter hook to redirect them to the "/dashboard" route.
Conditional Rendering: The component doesn't render anything visually; it only performs the redirect logic.

StreamView Component: `app/components/StreamView.tsx`

The StreamView component is responsible for displaying the current stream and the upcoming songs in the queue. It allows users to vote on songs and adds new songs to the queue.

"use client";

import { useEffect, useRef, useState } from 'react';
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Card, CardContent } from "@/components/ui/card";
import { ChevronUp, ChevronDown, ThumbsDown, Play, Share2, Axis3DIcon } from "lucide-react";
import { toast, ToastContainer } from 'react-toastify';
import 'react-toastify/dist/ReactToastify.css';
import { Appbar } from '../components/Appbar';
import LiteYouTubeEmbed from 'react-lite-youtube-embed';
import 'react-lite-youtube-embed/dist/LiteYouTubeEmbed.css';
import { YT_REGEX } from '../lib/utils';
import YouTubePlayer from 'youtube-player';

interface Video {
  "id": string,
  "type": string,
  "url": string,
  "extractedId": string,
  "title": string,
  "smallImg": string,
  "bigImg": string,
  "active": boolean,
  "userId": string,
  "upvotes": number,
  "haveUpvoted": boolean
}

// ...

The StreamView component includes various features such as:

Displaying the current video:
- Shows the title and thumbnail of the currently playing video.
- Embeds the video using the LiteYouTubeEmbed component.
Upcoming songs queue:
- Displays a list of upcoming songs in the queue.
- Allows users to upvote or downvote songs in the queue.
Adding new songs to the queue:
- Provides an input field for users to enter a YouTube video URL.
- Validates the URL format using a regular expression (YT_REGEX).
- Sends a POST request to the /api/streams endpoint to add the new song to the queue.
Automatic playback:
- Uses the YouTubePlayer library to control the video playback.
- Automatically plays the next song in the queue when the current one ends.
Refreshing the stream data:
- Periodically fetches the latest stream data from the /api/streams endpoint using the refreshStreams function.
- Updates the queue and the currently playing video based on the fetched data.
Sharing the stream link:
- Provides a "Share" button that copies the shareable link to the clipboard.
- Uses the toast library to display a success or error message based on the copy operation's result.

The landing page, Appbar, Redirect, and StreamView components work together to create an engaging user experience for the music SaaS platform. The landing page introduces the platform's features and encourages sign-ups, while the Appbar and Redirect components handle authentication and navigation. The StreamView component is the heart of the application, allowing users to interact with the live stream by adding songs, voting on them, and sharing the stream with others.

5] Building Dashboard Page, Utils, Finishing API Routes

This section provides a detailed explanation of the dashboard page (app/dashboard/page.tsx) and its related files (app/api/streams/my/route.ts, app/lib/utils.ts, app/creator/[creatorId]/page.tsx, and app/api/streams/next/route.ts). These components work together to create the main user interface and functionality of the music SaaS platform's dashboard.

Dashboard Page: `app/dashboard/page.tsx`

The dashboard page serves as the main interface for users to manage their streams and interact with the live stream.

"use client";
import { useEffect, useState } from 'react';
import { Button } from "@/components/ui/button";
import { Input } from "@/components/ui/input";
import { Card, CardContent } from "@/components/ui/card";
import { ChevronUp, ChevronDown, ThumbsDown, Play, Share2 } from "lucide-react";
import { toast, ToastContainer } from 'react-toastify';
import 'react-toastify/dist/ReactToastify.css';
import { Appbar } from '../components/Appbar';
import LiteYouTubeEmbed from 'react-lite-youtube-embed';
import 'react-lite-youtube-embed/dist/LiteYouTubeEmbed.css';
import { YT_REGEX } from '../lib/utils';
import StreamView from '../components/StreamView';

interface Video {
    "id": string,
    "type": string,
    "url": string,
    "extractedId": string,
    "title": string,
    "smallImg": string,
    "bigImg": string,
    "active": boolean,
    "userId": string,
    "upvotes": number,
    "haveUpvoted": boolean
}

const REFRESH_INTERVAL_MS = 10 * 1000;

const creatorId = "3ce10574-0396-43ac-8274-02882cde607b"

export default async function Component() {
    try {
        const data = await fetch("/api/user").then(res => res.json());

        return 
    } catch(e) {
        return null
    }
}

export const dynamic = 'auto'

Key Components Explained:

Fetching User Data: The dashboard page fetches the user's data from the /api/user endpoint using the fetch function. This data is used to retrieve the user's streams and display them in the StreamView component.
Rendering StreamView: The StreamView component is rendered with the user's ID and the playVideo prop set to true. This allows the dashboard to display the current stream and the upcoming songs in the queue.
Dynamic Rendering: The export const dynamic = 'auto' statement ensures that the page can be rendered dynamically, allowing for efficient rendering of the StreamView component.

API Route for User's Streams: `app/api/streams/my/route.ts`

This file handles API requests related to retrieving a user's streams.

import { prismaClient } from "@/app/lib/db";
import { getServerSession } from "next-auth";
import { NextRequest, NextResponse } from "next/server";

export async function GET(req: NextRequest) {
    const session = await getServerSession();
    // TODO: You can get rid of the db call here
    const user = await prismaClient.user.findFirst({
        where: {
            email: session?.user?.email ?? ""
        }
    });

    if (!user) {
        return NextResponse.json({
            message: "Unauthenticated"
        }, {
            status: 403
        });
    }

    const streams = await prismaClient.stream.findMany({
        where: {
            userId: user.id
        },
        include: {
            _count: {
                select: {
                    upvotes: true
                }
            },
            upvotes: {
                where: {
                    userId: user.id
                }
            }
        }
    });

    return NextResponse.json({
        streams: streams.map(({_count, ...rest}) => ({
            ...rest,
            upvotes: _count.upvotes,
            haveUpvoted: rest.upvotes.length ? true : false
        }))
    });
}

Key Components Explained:

Authentication: The route checks if the user is authenticated by retrieving the session data using getServerSession(). If the user is not authenticated, it returns a 403 Forbidden response.
Fetching Streams: If the user is authenticated, the route fetches all the streams associated with the user's ID using Prisma Client's findMany() method. It includes the count of upvotes for each stream and checks if the current user has upvoted each stream.
Response: The route returns a JSON response containing the user's streams with additional information like the number of upvotes and whether the current user has upvoted each stream.

Utility Functions: `app/lib/utils.ts`

This file contains utility functions and constants used throughout the application.

Using Regular Expressions for URL Validation

Regular expressions can be used to validate URLs and extract specific parts of them. For example, to check if a URL is a valid YouTube URL, we can use the following regular expression:

const youtubeRegex = /^.*(?:youtu.be\\\\/|v\\\\/|u\\\\/\\\\w\\\\/|embed\\\\/|watch\\\\?v=)([^#&?]*)(?:\\\\&.*+)?$/.test(data.url);

This regular expression checks if the URL contains 'youtube' and extracts the video ID.

import { type ClassValue, clsx } from "clsx";
import { twMerge } from "tailwind-merge";

export const YT_REGEX = /^(?:(?:https?:)?\\\\/\\\\/)?(?:www\\\\.)?(?:m\\\\.)?(?:youtu(?:be)?\\\\.com\\\\/(?:v\\\\/|embed\\\\/|watch(?:\\\\/|\\\\?v=))|youtu\\\\.be\\\\/)((?:\\\\w|-){11})(?:\\\\S+)?$/;

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs));
}

Key Components Explained:

YT_REGEX: A regular expression pattern used to validate YouTube video URLs.
cn Function: A utility function that combines multiple class names using the clsx and tailwind-merge libraries. This function helps with conditional styling and merging class names.

Creator Page: `app/creator/[creatorId]/page.tsx`

This file defines the page for displaying a specific creator's stream.

import StreamView from "@/app/components/StreamView";

export default function Creator({
    params: {
        creatorId
    }
}: {
    params: {
        creatorId: string;
    }
}) {
    return 
        
    
}

Key Components Explained:

Rendering StreamView: The StreamView component is rendered with the creatorId parameter passed from the URL. The playVideo prop is set to false to prevent automatic playback of the stream.
Accessing URL Parameters: The params object is used to access the creatorId parameter from the URL.

API Route for Next Stream: `app/api/streams/next/route.ts`

This file handles API requests related to retrieving the next stream to be played.

import { prismaClient } from "@/app/lib/db";
import { getServerSession } from "next-auth";
import { NextResponse } from "next/server";

export async function GET() {
    const session = await getServerSession();
    // TODO: You can get rid of the db call here
    const user = await prismaClient.user.findFirst({
       where: {
           email: session?.user?.email ?? ""
       }
   });

   if (!user) {
       return NextResponse.json({
           message: "Unauthenticated"
       }, {
           status: 403
       });
   }

   const mostUpvotedStream = await prismaClient.stream.findFirst({
        where: {
            userId: user.id,
            played: false
        },
        orderBy: {
            upvotes: {
                _count: 'desc'
            }
        }
   });

   await Promise.all([prismaClient.currentStream.upsert({
        where: {
            userId: user.id
        },
        update: {
            userId: user.id,
            streamId: mostUpvotedStream?.id
        },
        create: {
            userId: user.id,
            streamId: mostUpvotedStream?.id
        }
    }), prismaClient.stream.update({
        where: {
            id: mostUpvotedStream?.id ?? ""
        },
        data: {
            played: true,
            playedTs: new Date()
        }
   })])

   return NextResponse.json({
    stream: mostUpvotedStream
   });
}

Key Components Explained:

Authentication: The route checks if the user is authenticated by retrieving the session data using getServerSession(). If the user is not authenticated, it returns a 403 Forbidden response.
Fetching Next Stream: If the user is authenticated, the route fetches the most upvoted unplayed stream associated with the user's ID using Prisma Client's findFirst() method. It orders the streams by the count of upvotes in descending order.
Updating Current Stream: The route uses Prisma Client's upsert() method to update or create the current stream for the user. It sets the streamId to the ID of the most upvoted unplayed stream.
Updating Stream Status: The route updates the played status of the most upvoted unplayed stream using Prisma Client's update() method. It sets the played flag to true and the playedTs to the current timestamp.
Response: The route returns a JSON response containing the most upvoted unplayed stream.

The dashboard page, API routes, utility functions, and creator page work together to provide a comprehensive user interface for managing streams and interacting with live streams. The dashboard fetches the user's streams and displays them using the StreamView component. The API routes handle authentication and CRUD operations for streams, while utility functions provide helper functions and constants. The creator page allows users to view a specific creator's stream without automatic playback.

Technical Details

Database Schema: Uses PostgreSQL with Prisma for efficient real-time calculations and updates.
Authentication: Uses Next.js for secure user access.
Front End Development: Focuses on creating a user-friendly interface with Tailwind CSS.
Real-Time Updates: Implements long polling for real-time updates to the leaderboard.
Payment Integration: Plans to use Web3.js and Solana wallet adapter for handling cryptocurrency transactions, though this is still under consideration.
API Integration: Integrates with APIs like YouTube and Spotify to handle track selection and ID extraction, ensuring no song collisions.

Future Development

Open Issues: Identified issues are documented in the repository for community contribution.
Community Involvement: Encourages community contribution to enhance the platform.

Building WazirX End to End

Fri, 03 Jan 2025 14:50:49 GMT

In this article, we will explore the process of building a centralized cryptocurrency exchange (CEX) similar to WazirX from the ground up, providing a thorough examination of both the conceptual framework and technical implementation involved in such a platform.

We will begin with an overview of the CEX architecture, breaking it down into essential components such as user onboarding, wallet management, and trading functionalities. Following this, we will delve into the technical aspects of implementing these components using modern technologies, including database management, API integrations, and security protocols.

For those who prefer visual learning, a video presentation of this article's content is available on YouTube at

The article will cover everything from regulatory compliance and security considerations to liquidity management and user experience design, offering valuable insights into the infrastructure and workflows that underpin successful cryptocurrency exchanges. By understanding these elements, developers will be better equipped to create secure and efficient trading platforms that meet the needs of users in the evolving crypto landscape.

To follow along with the code examples in this lecture, please refer to the GitHub repository https://github.com/code100x/cdex.

Building a Centralized Exchange: Key Considerations and Architectural Differences

Building a centralized exchange (CEX) is a complex task that requires careful consideration of several critical factors. In this section, we will delve into the architecture of a CEX, discuss the challenges faced by previous exchanges like Binance (BZX) and FTX, and outline the steps necessary to build a secure and compliant CEX in India. We will also explore the use of multi-signature wallets (multis), market makers, and the importance of INR-USDT markets in the Indian context.

Architecture of a Centralized Exchange

A centralized exchange is a platform where users can buy, sell, and trade cryptocurrencies. The architecture of such an exchange involves several key components:

Front-end Development:
- The first step in building a CEX is to create the front-end interface. This includes designing and developing user-friendly pages for signing up, logging in, viewing balances, and swapping cryptocurrencies.
- For instance, you would need to create a sign-up page, a balances page, and a swap page. The sign-up and sign-in logic should be implemented with basic backend functionality to handle user authentication.
Backend Development:
- The backend of the exchange handles the core functionality such as transaction processing, user account management, and security measures.
- Initially, you will need to implement basic backend logic without integrating banking APIs. This involves mocking out payment processes using services like Razorpay or Stripe but ensuring that these services do not flag your business as a crypto exchange due to regulatory restrictions.
Multi-Signature Wallets (Multis):
- Multi-signature wallets are used to enhance security by requiring multiple signatures for transactions. This is particularly useful in preventing single-point failures and ensuring that no single entity can control all funds.
- In this tutorial, we will explore how to create and integrate multisig wallets on various blockchains such as Solana and Ethereum.
Market Makers and Spot Trading:
- Market makers are crucial for providing liquidity to an exchange. They buy and sell assets at the best available prices to maintain market stability.
- Spot trading refers to the immediate exchange of one cryptocurrency for another without involving any derivatives. In the context of a CEX, spot trading allows users to swap INR for Ethereum or Ethereum for INR directly.
India-Specific Challenges:
- Building an exchange in India comes with unique challenges due to regulatory requirements.
- One major challenge is handling crypto taxes every time a user swaps cryptocurrencies. Additionally, withdrawals are restricted; users can only withdraw funds using Indian Rupees (INR). This means that users can only buy cryptocurrencies using INR and sell them back into INR but cannot withdraw them directly from the exchange.
- This regulatory environment necessitates careful planning and compliance with Indian laws regarding cryptocurrency transactions.
INR-USDT Market:
- The INR-USDT market is critical for exchanges operating in India. USDT (Tether), a stablecoin pegged to the US dollar, is often used as a bridge between fiat currencies like INR and other cryptocurrencies.
- Ensuring a stable and liquid INR-USDT market is essential for user trust and exchange stability.
Licensing and Banking APIs:
- To integrate banking APIs directly with your exchange, you need an FIU (Financial Intelligence Unit) license. This license allows you to handle financial transactions securely and comply with anti-money laundering (AML) and know-your-customer (KYC) regulations.
- Without an FIU license, you cannot integrate directly with payment providers like Razorpay or Stripe, which are essential for onboarding users and facilitating transactions.
Security Considerations:
- Despite best efforts, centralized exchanges are not immune to security threats. Attack vectors such as phishing attacks, smart contract vulnerabilities, and insider threats must be identified and mitigated.
- We will discuss common attack vectors associated with centralized exchanges and provide strategies for addressing them effectively.

Conclusion

Building a centralized exchange requires meticulous planning and adherence to regulatory requirements specific to the region you operate in. By understanding the architecture of a CEX, addressing India-specific challenges, and implementing robust security measures, you can create a reliable platform for cryptocurrency trading. This tutorial will guide you through each step of building your own CEX while highlighting potential pitfalls and solutions along the way.

Understanding Users and Market Makers

Centralized exchanges (CEXs) are pivotal in the digital currency ecosystem, serving as primary hubs for trading cryptocurrencies. These platforms are managed by a central authority and are designed to facilitate the buying, selling, and trading of various digital assets. To build a CEX, particularly in a country like India, one must understand the architecture involving two key components: end users and market makers.

End Users

End users are individuals who want to buy or sell cryptocurrencies. In the context of an Indian CEX, such as Vazir X, the process is relatively straightforward:

User Onboarding: The user signs up for the platform, which involves a simple registration process. Many companies offer KYC (Know Your Customer) services as a service, making this step easier for the platform to manage.
Funding: Users deposit INR (Indian Rupees) from their bank accounts into the platform. This is facilitated by integrating directly with banks like HDFC or SBI, allowing users to send funds easily.
Trading: Once funded, users can convert their INR into cryptocurrencies like USDT or Ethereum. For example, a user might swap 10,000 rupees for $10 USDT or Ethereum.
Order Execution: Users place orders to buy or sell cryptocurrencies. The platform's order book matches these orders based on the best available prices.

Market Makers

Market makers are crucial for providing liquidity to the exchange. They are entities that always have a position in the market and are willing to take the other side of trades. In India, attracting market makers poses significant challenges:

Liquidity Requirements: Liquidity refers to the ability of the market to absorb buy and sell orders without significantly affecting the market price. In India, market makers face high transaction costs due to regulatory requirements, which can be as high as 1% of each transaction.
Market Maker Incentives: Market makers need to have substantial capital to maintain their positions on the order book. They must be incentivized to join the platform, which can be challenging due to high transaction costs.
Order Book Management: The order book is a list of buy and sell orders that are publicly available, showing market depth. Market makers fill this order book by providing liquidity, ensuring that there are always buyers and sellers available for trades.

Architectural Components

To build a robust CEX, several architectural components must be considered:

Trading Engine: The trading engine processes transactions, matches buy and sell orders, and calculates balances. It must ensure high performance and low latency for efficient trading.
User Interface (UI): The UI is critical for user experience, providing easy navigation and access to essential information like market charts, order books, and trading history.
Wallet Infrastructure: Users store their cryptocurrencies in custodial wallets controlled by the exchange. This setup allows for efficient trading but also poses risks if the exchange's security is compromised.
Security Measures: Robust security measures such as two-factor authentication, encryption, and regular security audits are essential to protect user assets from hacking and other threats.

Example Scenario

Let's consider an example scenario on a centralized exchange like Vazir X:

User Action: A user deposits 20,000 INR into their INR wallet on the platform.
Order Placement: The user places an order to buy 0.001 Ethereum (ETH) at the best available price.
Order Matching: The order is matched with an existing sell order in the order book, resulting in the user buying 0.0017 ETH for 5.56 USDT.
Portfolio Update: The user's portfolio is updated to reflect the new balance of ETH and USDT.

Challenges in India

In India, there are specific regulations that affect how CEXs operate:

Regulatory Compliance: Users can only deposit INR and must withdraw it back to their bank accounts. This regulation restricts the ability to hold cryptocurrencies outside the exchange ecosystem.
Liquidity Challenges: High transaction costs due to regulatory requirements make it challenging for market makers to provide liquidity, leading to higher spreads in the order book.

Conclusion

Building a centralized exchange in India requires careful consideration of both end users and market makers. Ensuring sufficient liquidity through market makers is crucial for providing a smooth trading experience. The architectural components of a CEX must be designed with security and user experience in mind, addressing the unique challenges posed by Indian regulations.

For a deeper dive into the technical aspects of building such systems, it is recommended to explore detailed guides and videos that cover topics like deposit addresses, sweeping wallets, and primary wallets that are critical for maintaining security in centralized exchanges.

Understanding the Hacking of FTX and Centralized Exchanges

Centralized cryptocurrency exchanges (CEXs) have been a cornerstone of the digital asset market, providing users with a platform to buy, sell, and trade various cryptocurrencies. However, these exchanges are not immune to security breaches, as exemplified by the high-profile hack of FTX. In this section, we will delve into the specifics of how FTX was hacked and explore the broader implications for centralized exchanges.

How Exchanges Get Hacked

Centralized exchanges hold users' assets in their primary wallets. If these wallets are compromised, the exchange is vulnerable to hacking. The scenario can be likened to a real estate platform where users do not directly own the land but rather see a representation of ownership on their dashboard. If the company managing the land's assets is hacked, the users' assets are at risk (Section 4 of the transcript).

The FTX Hack

FTX's primary wallet was compromised, leading to a significant loss of assets. The hack involved a multisig wallet, which is designed to require multiple signatures for transactions. However, in FTX's case, all four signers were using a central website to sign messages, which was hacked by an attacker (Section 4 of the transcript). This central attack vector allowed the hacker to manipulate the system and steal funds.

Preventing Hacks in Centralized Exchanges

To prevent such attacks, exchanges can implement more secure practices. One approach is to run code locally rather than relying on internet-facing websites. This method ensures that the code is under constant review and cannot be manipulated by external actors (Section 4 of the transcript). Additionally, using decentralized architectures with multiple data centers and automated signers can significantly reduce the risk of hacking. Each signer should have access to different cloud providers, making it difficult for a single entity to compromise all systems (Section 4 of the transcript).

Multisig Wallets

Multisig wallets are designed to provide an additional layer of security by requiring multiple signatures for transactions. This approach is useful for resiliency, as it ensures that even if one signer's private key is compromised, the funds cannot be accessed without the cooperation of other signers (Section 4 of the transcript). However, as seen in FTX's case, if all signers are compromised through a central attack vector, the security benefits of multisig wallets are negated.

Decentralized Exchanges (DEXs)

Decentralized exchanges offer an alternative to centralized exchanges by providing liquidity through automated market makers or other decentralized mechanisms. This approach avoids the need for market makers to physically interact with the exchange, reducing the risk of central points of attack (Section 4 of the transcript). DEXs are particularly useful in regions like India where market makers may be deterred by high transaction taxes (TDS).

Market Makers

Market makers play a crucial role in maintaining liquidity on centralized exchanges. They provide incentives such as trading rewards or exclusive benefits to traders who actively participate in the market. However, in India, high TDS rates discourage market makers from participating, leading to liquidity issues (Section 4 of the transcript).

India-Specific Challenges

Building a centralized cryptocurrency exchange in India comes with unique challenges:

Taxes: India imposes a 1% TDS on every trade, which significantly discourages active trading and attracts market makers (Section 4 of the transcript).
Withdrawals: Retail users cannot withdraw cryptocurrencies from exchanges like CoinDCX, which restricts their ability to own and manage their digital assets (Section 4 of the transcript).
Licensing: Exchanges must obtain an FIU license to connect with banks and facilitate user transactions (Section 4 of the transcript).
Banking APIs: Access to banking APIs is restricted unless an exchange has a valid license, further limiting user transactions (Section 4 of the transcript).

Architecture of Our Exchange

Our exchange will adopt a mildly decentralized architecture to address these challenges:

Liquidity: By using decentralized mechanisms, we aim to avoid the chicken-and-egg problem of attracting market makers.
Security: This architecture ensures that users' assets are not solely held in a central wallet, reducing the risk of hacking.
Proof of Reserves: Users can easily verify that their assets are owned by the exchange through on-chain proof of reserves.

This approach balances the need for security with the practical challenges of operating in a highly regulated environment like India.

Conclusion

The hacking of FTX highlights the vulnerabilities of centralized exchanges and underscores the importance of robust security measures. By understanding these vulnerabilities and implementing decentralized architectures, we can build more secure and resilient platforms for cryptocurrency trading. The unique challenges faced by exchanges in India, such as high TDS rates and restrictive withdrawal policies, necessitate innovative solutions that balance security with regulatory compliance.

Additional Resources

For a deeper understanding of these concepts, refer to our previous sections on multisig wallets, decentralized exchanges, and market makers. Additionally, our video series on building a cryptocurrency exchange provides detailed explanations of these topics.

This section provides a comprehensive overview of how centralized exchanges can be hacked, the specific case of FTX's hack, and the broader implications for security measures in cryptocurrency trading. It also addresses India-specific challenges and outlines our approach to building a mildly decentralized exchange that balances security with regulatory compliance.

Architecture of a Decentralized Exchange vs. Centralized Exchange

In the realm of cryptocurrency trading, the architecture of an exchange is crucial for ensuring a smooth user experience, maintaining the integrity of the trading process, and safeguarding the assets of both traders and the exchange itself. This section delves into the differences between a centralized exchange and a decentralized exchange, focusing on the approach of a normal exchange versus a "wallet as a service" model.

Normal Centralized Exchange

A traditional centralized exchange (CEX) operates by aggregating all user funds into a single wallet. For instance, if an exchange like CoinDCX has 1,000 users, all their funds are held in a single wallet. This approach raises significant security concerns because it centralizes the storage of vast amounts of cryptocurrency, making it a prime target for hackers. Moreover, proving reserves becomes challenging as users cannot verify on-chain that their funds are securely held. Instead, exchanges often provide proof of reserves, which may not be entirely transparent or reliable.

Wallet as a Service (WaaS)

In contrast, a "wallet as a service" model, as described in the transcript, diverges from the traditional centralized exchange architecture. Instead of holding all user funds in a single wallet, this approach creates individual wallets for each user. This means that every user's funds are securely stored in their own wallet, which can be verified on-chain. For example, if a user has $10,000 in their wallet, they can prove this by checking their public address on the blockchain. This approach eliminates the trust problem associated with centralized exchanges, where users are uncertain about where their funds are being held.

Key Differences

Security and Trust:
- Centralized Exchange: Centralized exchanges hold all user funds in a single wallet, making them vulnerable to hacks and compromising user trust.
- Wallet as a Service: Each user has their own wallet, ensuring that funds are distributed across millions of wallets rather than being aggregated in one central location. This significantly enhances security and transparency.
Proof of Reserves:
- Centralized Exchange: Proving reserves is complex because it involves verifying the existence of funds in a single wallet.
- Wallet as a Service: Since each user has their own wallet, proof of reserves becomes straightforward as users can verify their funds directly on-chain.
Liquidity Sourcing:
- Centralized Exchange: Finding market makers to provide liquidity is challenging, especially in regions with stringent regulations like India.
- Wallet as a Service: By sourcing liquidity from decentralized exchanges (DEXs), the need for market makers is mitigated. DEXs like Jupiter on Solana allow users to swap assets seamlessly without relying on centralized market makers.
User Experience and Functionality:
- Centralized Exchange: Exchanges offer fast trading due to their centralized systems but may charge higher trading fees.
- Wallet as a Service: While transactions are slower due to on-chain verification and associated gas fees, this approach provides a more transparent and secure user experience.
Regulatory Compliance:
- Centralized Exchange: Centralized exchanges typically require KYC (Know Your Customer) and AML (Anti-Money Laundering) compliance for both users and market makers.
- Wallet as a Service: Since market makers on DEXs do not need to undergo KYC, regulatory compliance becomes more complex. However, this approach aligns with the decentralized nature of blockchain technology.

Conclusion

The choice between a centralized exchange and a "wallet as a service" model hinges on security, trust, and regulatory considerations. While centralized exchanges offer fast trading with robust security measures, they centralize user funds, making them vulnerable to hacks. In contrast, a "wallet as a service" model distributes user funds across individual wallets, enhancing security and transparency. However, this approach comes with its own set of challenges, including slower transaction times and regulatory complexities. Understanding these differences is crucial for building a secure and reliable cryptocurrency trading platform.

Additional Considerations

Government Regulations:
- The government's stance on decentralized exchanges can be challenging due to the lack of KYC for market makers. This could lead to regulatory issues if the source of liquidity is not transparent.
User Education:
- Users need to understand the differences between centralized and decentralized exchanges to make informed decisions about their cryptocurrency holdings.
Technical Implementation:
- Implementing a "wallet as a service" model requires robust technical infrastructure, including secure wallet creation and management systems.
User Experience Optimization:
- Balancing security with user experience is essential. Providing intuitive interfaces for users to manage their wallets and trade cryptocurrencies seamlessly is crucial for adoption.

By understanding these architectural differences, developers can design cryptocurrency trading platforms that prioritize both security and user experience, ultimately enhancing the overall integrity of the digital asset ecosystem.

Building a Decentralized Exchange

Creating a decentralized exchange (DEX) involves several complex steps, from setting up the front-end and back-end infrastructure to integrating wallet services and handling user authentication. In this section, we will delve into the detailed process of building a DEX, focusing on the key aspects such as wallet as a service, user authentication, and database management.

Wallet as a Service

One of the critical components of our DEX is the wallet as a service approach. This method involves creating a wallet for users without them having to manage their private keys directly. Instead, the service manages the private keys on behalf of the users, providing a secure and user-friendly experience.

Wallet Address: The wallet address is the public key of the user's wallet, which is held by the service provider (e.g., Tiplink). This address can be used to verify the user's balance on any blockchain explorer.

Example: If a user signs up on our platform, they will receive a wallet address that they can use to view their balance on a blockchain explorer like Solscan. For instance, if the user has $1.46 in their wallet, this information will be visible on Solscan.

Benefits:

Safety: By not allowing users to own their private keys, we ensure that their funds are safer from unauthorized access.
Regulatory Compliance: In India, exchanges are required to hold user funds rather than allowing users to own their private keys. Our wallet as a service approach complies with these regulations.
Ease of Withdrawal: If the Indian government allows withdrawals from centralized exchanges in the future, users can easily withdraw their funds by receiving their private keys from the service provider.

Architecture Overview

To build our DEX, we will follow a two-part approach: easy implementation and hard implementation.

Easy Implementation:

Front-end Setup: Create a simple sign-up and sign-in page using Next.js.
Database Schema: Define a user model with email, name, and wallet details (public key, private key).
Wallet Generation: Generate a Solana wallet for each user and store its details in the database.

Hard Implementation:

Market Makers: Integrate market makers to provide liquidity for INR-USDT conversions.
Spot Trading: Allow users to swap Solana for Ethereum or USDT for Solana.
Security Measures: Implement robust security measures to prevent attacks and ensure the integrity of user funds.

Hands On Coding

1] Creating a basic NextJS app with NextAuth

To set up the front-end, we will use Next.js as our framework. Here’s how we can create a basic sign-up and sign-in logic:

1. `app/api/auth/[...nextauth]/route.ts`

This file is responsible for setting up authentication using NextAuth, a library that simplifies the process of adding authentication to Next.js applications.

Code Breakdown:

import { authConfig } from "@/app/lib/auth";
import NextAuth from "next-auth";

const handler = NextAuth(authConfig);

export { handler as GET, handler as POST };

console.log({
    clientId: process.env.GOOGLE_CLIENT_ID ?? "",
    clientSecret: process.env.GOOGLE_CLIENT_SECRET ?? ""
});

Imports: The file imports authConfig from a local module and the NextAuth function from the next-auth package.
Handler Setup: The handler variable is created by calling NextAuth(authConfig), which initializes the authentication process with the provided configuration.
Exporting Handlers: The handler is exported as both GET and POST, allowing it to respond to both types of HTTP requests. This is essential for handling sign-in and sign-out actions.
Logging Credentials: The console.log statement outputs the Google client ID and secret to the console. This is useful for debugging but should be removed or secured in a production environment to avoid exposing sensitive information.

2. `app/components/Appbar.tsx`

This component represents the application's navigation bar, providing users with options to sign in or sign out based on their authentication status.

Code Breakdown:

"use client";
import { signIn, signOut, useSession } from "next-auth/react";
import { PrimaryButton } from "./Button";

export const Appbar = () => {
    const session = useSession();
    return (
        
            
                DCEX
            
            
                {session.data?.user ? (
                     {
                        signOut();
                    }}>Logout
                ) : (
                     {
                        signIn();
                    }}>Signin
                )}
            
        
    );
};

Client Component: The "use client" directive indicates that this component should be rendered on the client side.
Session Management: The useSession hook retrieves the current user's session data, which includes information about whether the user is logged in.
Conditional Rendering: The component conditionally renders either a "Logout" button or a "Signin" button based on whether a user is authenticated (session.data?.user).
Styling: The component uses Tailwind CSS classes for styling, ensuring a responsive and visually appealing layout.

3. `app/layout.tsx`

This file defines the root layout of the application, which wraps all pages and components within a consistent structure.

Code Breakdown:

import type { Metadata } from "next";
import { Inter } from "next/font/google";
import "./globals.css";
import { Appbar } from "./components/Appbar";
import { Providers } from "./providers";

const inter = Inter({ subsets: ["latin"] });

export const metadata: Metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    
      
        
          
          {children}
        
      
    
  );
}

Metadata Definition: The metadata object contains information about the page's title and description, which can be used for SEO purposes.
Font Import: The Inter font is imported for use throughout the application, ensuring consistent typography.
Root Layout Structure: The RootLayout function defines the main HTML structure. It wraps children components with and tags.
Providers Component: The Providers component wraps around child components to provide context (like authentication state) across the application.

4. `app/page.tsx`

This file represents the main page of the application, rendering the hero section prominently.

Code Breakdown:

import Image from "next/image";
import { Hero } from "./components/Hero";

export default function Home() {
  return (
    
      
    
  );
}

Image Import: The Image component from Next.js is imported for optimized image handling (though it's not used directly in this snippet).
Hero Component: The main content of this page consists of rendering a component, which likely contains introductory content or promotional material.
Styling: The
element uses Tailwind CSS classes to ensure it takes up at least the full height of the screen and centers its content both vertically and horizontally.

5. `app/providers.tsx`

This file sets up context providers necessary for managing session state across the application.

Code Breakdown:

'use client';

import { SessionProvider } from "next-auth/react";

export const Providers = ({ children }: { children: React.ReactNode; }) => {
    return (
        
            {children}
        
    );
};

Client Component Directive: Similar to other files, "use client" indicates that this component should run on the client side.
Session Provider Setup: The SessionProvider wraps its children with context that provides session data throughout the app. This allows any component within this provider to access user session information easily.

Conclusion

These files collectively establish a foundational structure for a Next.js application that integrates authentication using NextAuth. Each component plays a critical role in managing user sessions, rendering UI elements, and maintaining an organized layout, all while adhering to best practices in modern web development.

2] Building the Landing Page

1. `app/components/Button.tsx`

This file defines three button components: PrimaryButton, SecondaryButton, and TabButton. Each component is designed to handle user interactions while providing a consistent styling approach.

Code Breakdown:

"use client";

export const PrimaryButton = ({children, onClick}: {
    children: React.ReactNode,
    onClick: () => void
}) => {
    return (
        
    );
};

PrimaryButton: This component renders a button styled with Tailwind CSS classes. It accepts children (the button label) and an onClick function as props. The button's appearance changes on hover and focus, enhancing user experience.

export const SecondaryButton = ({children, onClick, prefix}: {
    children: React.ReactNode,
    onClick: () => void,
    prefix?: React.ReactNode
}) => {
    return (
        
    );
};

SecondaryButton: Similar to the PrimaryButton, this component includes an optional prefix prop that allows for additional content (like an icon) to be displayed alongside the button label. It also uses Tailwind CSS for styling and has hover effects.

export const TabButton = ({active, children, onClick}: {
    active: boolean;
    children: React.ReactNode,
    onClick: () => void
}) => {
    return (
        
    );
};

TabButton: This component is designed for tab navigation. It accepts an active prop to determine its styling based on whether it is currently selected. The button's background color changes according to its active state, providing visual feedback to users.

2. `app/components/Hero.tsx`

The Hero component serves as a prominent introductory section of the application, displaying key messages and actions for users.

Code Breakdown:

"use client";

import { signIn, useSession } from "next-auth/react";
import { SecondaryButton } from "./Button";
import { useRouter } from "next/navigation";

export const Hero = () => {
    const session = useSession();
    const router = useRouter();

    return (
        
            
                The Indian Cryptocurrency
                Revolution
            
            
                Create a frictionless wallet from India with just a Google Account.
            
            
                Convert your INR into Cryptocurrency
            
            
                {session.data?.user ? (
                     {
                        router.push("/dashboard");
                    }}>Go to Dashboard
                ) : (
                     {
                        signIn("google");
                    }}>Login with Google
                )}
            
        
    );
};

Client Component Directive: The "use client" directive indicates that this component should be rendered client-side.
Session Management: The useSession hook retrieves the current user's session data. If a user is logged in, they will see a "Go to Dashboard" button; otherwise, they will see a "Login with Google" button.
Styling and Layout: The component uses Tailwind CSS classes for layout and typography. It features large headings and centered text to create an impactful visual presentation.

Summary

These two components (Button.tsx and Hero.tsx) play crucial roles in enhancing user interaction within the application:

Button Components:
- Provide reusable UI elements (PrimaryButton, SecondaryButton, and TabButton) with consistent styling and behavior.
- Allow for different types of user actions (e.g., logging in, navigating tabs).
Hero Component:
- Acts as an engaging introduction to the application.
- Guides users towards authentication or navigation based on their session state.

Together, they contribute to a cohesive user experience in the WazirX clone application by ensuring that buttons are easily accessible and visually appealing while providing clear calls to action.

3] Schemas & Database Management

To manage user data and wallets, we will use Prisma as our ORM tool. Here’s how we can define our schema:

1. `prisma/schema.prisma`

This file defines the database schema for the application using Prisma, an ORM (Object-Relational Mapping) tool that simplifies database interactions.

Code Breakdown:

// This is your Prisma schema file,
// learn more about it in the docs: 

// Looking for ways to speed up your queries, or scale easily with your serverless or edge functions?
// Try Prisma Accelerate: 

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

Comments: The initial comments provide context and links to documentation, guiding developers on how to use the schema file effectively.
Generator: The generator client block specifies that Prisma should generate a client library using the JavaScript client (prisma-client-js). This client is used in the application to interact with the database.
Datasource: The datasource db block defines the database connection. It specifies that PostgreSQL is the database provider and retrieves the connection URL from an environment variable (DATABASE_URL).

Model Definitions:

model User {
  id              String    @id  @default(uuid())
  username        String
  sub             String    @default("")
  name            String?
  profilePicture  String?
  password        String?
  solWalletId     String?
  solWallet       SolWallet?
  inrWalletId     String?
  inrWallet       InrWalet?
  provider        Provider
}

User Model: This model represents a user in the application. It includes fields for user identification (id, username, sub), optional fields for user details (name, profilePicture, password), and relationships to wallet models (solWallet, inrWallet). The @id directive marks id as the primary key, and @default(uuid()) automatically generates a unique identifier.

model InrWalet {
  id          String    @id  @default(uuid())
  balance     Int
  userId      String   @unique
  user        User     @relation(fields: [userId], references: [id])
}

InrWalet Model: Represents an INR wallet associated with a user. It includes a balance field and establishes a one-to-one relationship with the User model, ensuring that each wallet is linked to a unique user.

model SolWallet {
  id          String   @id  @default(uuid())
  publicKey   String
  privateKey  String
  userId      String   @unique
  user        User     @relation(fields: [userId], references: [id])
}

SolWallet Model: Represents a Solana wallet linked to a user. It includes fields for public and private keys, along with a relationship to the User model.

enum Provider {
  Google
}

Provider Enum: Defines an enumeration for authentication providers. In this case, it includes only Google, which indicates that users can log in using their Google accounts.

2. `app/db/index.ts`

This file initializes and exports a singleton instance of the Prisma Client, ensuring that only one instance is used throughout the application.

Code Breakdown:

import { PrismaClient } from '@prisma/client';

const prismaClientSingleton = () => {
  return new PrismaClient();
};

type PrismaClientSingleton = ReturnType;

// eslint-disable-next-line
const globalForPrisma = globalThis as unknown as {
  prisma: PrismaClientSingleton | undefined;
};

const prisma = globalForPrisma.prisma ?? prismaClientSingleton();

export default prisma;

if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma;

Imports: The file imports PrismaClient from the Prisma package, which is essential for database operations.
Singleton Function: The prismaClientSingleton function creates a new instance of PrismaClient. This pattern helps manage database connections efficiently.
Type Definition: The type alias PrismaClientSingleton defines the return type of the singleton function, ensuring type safety.
Global Variable Setup: The code creates a global variable (globalForPrisma) to hold the singleton instance of Prisma Client. This approach helps avoid multiple instances in environments like serverless functions where multiple invocations can occur.
Instance Creation: The line const prisma = globalForPrisma.prisma ?? prismaClientSingleton(); checks if an instance already exists; if not, it creates one. This ensures that only one instance of Prisma Client is used throughout the application lifecycle.
Exporting Prisma Instance: The final line exports the singleton instance of Prisma Client for use in other parts of the application.
Environment Check: The conditional statement at the end ensures that in non-production environments (like development), the global variable is set to hold the created instance. This prevents issues related to hot reloading during development.

Summary

The files collectively establish a robust data management layer for the WazirX clone application:

Schema Definition (schema.prisma):
- Defines models for users and wallets, establishing relationships and constraints.
- Utilizes enums for managing authentication providers.
- Facilitates easy interaction with PostgreSQL through generated client code.
Database Client Initialization (index.ts):
- Implements a singleton pattern for managing database connections efficiently.
- Ensures only one instance of Prisma Client is used across different parts of the application.
- Provides type safety and handles environment-specific configurations seamlessly.

Together, these components lay down a solid foundation for managing user data and interactions within the application while adhering to best practices in software development.

4] Building the Dashboard Page

The dashboard component will display the user's name, profile picture, and asset balances.

1. `app/dashboard/page.tsx`

This file represents the dashboard page of the application, where users can view their wallet information and interact with various features related to their cryptocurrency holdings.

Code Breakdown:

import { getServerSession } from "next-auth";
import { ProfileCard } from "../components/ProfileCard";
import db from "@/app/db";
import { authConfig } from "../lib/auth";

async function getUserWallet() {
    const session = await getServerSession(authConfig);

    const userWallet = await db.solWallet.findFirst({
        where: {
            userId: session?.user?.uid
        },
        select: {
            publicKey: true
        }
    });

    if (!userWallet) {
        return {
            error: "No Solana wallet found associated to the user"
        };
    }

    return { error: null, userWallet };
}

export default async function Dashboard() {
    const userWallet = await getUserWallet();

    if (userWallet.error || !userWallet.userWallet?.publicKey) {
        return <>No Solana wallet found;
    }

    return (
        
            
        
    );
}

Imports: The file imports necessary functions and components, including getServerSession for session management, ProfileCard for displaying user wallet information, and the database instance (db) for querying.
getUserWallet Function: This asynchronous function retrieves the user's Solana wallet based on their session. It checks if a session exists and queries the database for the user's wallet using their unique identifier (uid). If no wallet is found, it returns an error message.
Dashboard Component: The main component that renders the dashboard. It calls getUserWallet to fetch the user's wallet information. If an error occurs or if no public key is found, it displays a message indicating that no wallet exists. Otherwise, it renders the ProfileCard component, passing the public key as a prop.

2. `app/components/ProfileCard.tsx`

This component displays the user's profile information and allows interaction with various features related to their cryptocurrency holdings.

Code Breakdown:

"use client";

import { useSession } from "next-auth/react";
import { useRouter } from "next/navigation";
import { PrimaryButton, TabButton } from "./Button";
import { useEffect, useState } from "react";
import { TokenWithbalance, useTokens } from "../api/hooks/useTokens";
import { TokenList } from "./TokenList";
import { Swap } from "./Swap";

type Tab = "tokens" | "send" | "add_funds" | "swap" | "withdraw";
const tabs: { id: Tab; name: string }[] = [
    { id: "tokens", name: "Tokens" },
    { id: "send", name: "Send" },
    { id: "add_funds", name: "Add funds" },
    { id: "withdraw", name: "Withdraw" },
    { id: "swap", name: "Swap" },
];

export const ProfileCard = ({ publicKey }: { publicKey: string }) => {
    const session = useSession();
    const router = useRouter();
    const [selectedTab, setSelectedTab] = useState("tokens");
    const { tokenBalances, loading } = useTokens(publicKey);

    if (session.status === "loading") {
        return Loading...;
    }

    if (!session.data?.user) {
        router.push("/");
        return null;
    }

    return (
        
            
                
                
                    {tabs.map(tab => (
                         setSelectedTab(tab.id)}>
                            {tab.name}
                        
                    ))}
                

                
                    
                
                
                    
                
                
                    
                
            
        
    );
};

function Warning() {
    return (
        
            We don't yet support this feature
        
    );
}

function Assets({ publicKey, tokenBalances, loading }: {
    publicKey: string;
    tokenBalances: {
        totalBalance: number,
        tokens: TokenWithbalance[]
    } | null;
    loading: boolean;
}) {
    const [copied, setCopied] = useState(false);

    useEffect(() => {
        if (copied) {
            let timeout = setTimeout(() => setCopied(false), 3000);
            return () => clearTimeout(timeout);
        }
    }, [copied]);

    if (loading) {
        return "Loading...";
    }

    return (
        
            Account assets
            
                
                    ${tokenBalances?.totalBalance}
                    USD
                

                
                     {
                        navigator.clipboard.writeText(publicKey);
                        setCopied(true);
                    }}>
                        {copied ? "Copied" : "Your wallet address"}
                    
                
            

            
                
            
        
    );
}

function Greeting({ image, name }: { image: string; name: string }) {
    return (
        
            
            
               Welcome back, {name}
            
        
    );
}

Client Component Directive: The "use client" directive indicates that this component is rendered on the client side.
Imports: The component imports necessary hooks and components for managing user sessions and displaying information.
Tabs Definition: It defines tab options for navigation within the profile card (e.g., Tokens, Send, Add Funds).
ProfileCard Component:
- Uses useSession to manage authentication state.
- Uses useTokens to fetch token balances based on the provided publicKey.
- Displays a loading state while fetching session data.
- If no user is logged in, it redirects to the home page.
- Renders greeting information and dynamically displays content based on which tab is selected (Assets or Swap).

3. `app/components/TokenList.tsx`

This component displays a list of tokens held by the user along with their balances.

Code Breakdown:

import { TokenWithbalance } from "../api/hooks/useTokens";

export function TokenList({ tokens }: { tokens: TokenWithbalance[] }) {
    return (
        
            {tokens.map(t => (
                
            ))}
        
    );
}

function TokenRow({ token }: { token: TokenWithbalance }) {
    return (
        
            
                
                
                    {token.name}
                    1 {token.name} = ~${token.price}
                
            
            
                {token.usdBalance}
                {token.balance}
            
        
    );
}

TokenList Component:
- Accepts an array of tokens as props.
- Maps over each token and renders a TokenRow for each one.
TokenRow Component:
- Displays individual token details including an image, name, price, USD balance, and actual balance.
- Uses Tailwind CSS for styling to ensure a clean layout.

4. `app/lib/auth.ts`

This file configures authentication using NextAuth with Google as a provider.

Code Breakdown:

import GoogleProvider from "next-auth/providers/google";
import db from "@/app/db";
import { Keypair } from "@solana/web3.js";

import { Session } from 'next-auth';

export interface session extends Session {
    user: {
      email: string;
      name: string;
      image: string;
      uid: string;
    };
}

export const authConfig = {
    secret: process.env.NEXTAUTH_SECRET || 'secr3t',
    providers: [
        GoogleProvider({
            clientId: process.env.GOOGLE_CLIENT_ID ?? "",
            clientSecret: process.env.GOOGLE_CLIENT_SECRET ?? ""
        })
    ],

The configuration sets up Google as an authentication provider using credentials stored in environment variables. The custom session interface extends NextAuth's default session type to include additional properties like uid.

callbacks: {
        session: ({ session, token }: any): session => {
            const newSession: session = session as session;
            if (newSession.user && token.uid) {
              newSession.user.uid = token.uid ?? "";
            }
            return newSession!;
        },

The session callback modifies the session object to include the user's unique ID (uid) after successful authentication.

async jwt({ token, account, profile }: any) {
            const user = await db.user.findFirst({
                where: {
                    sub: account?.providerAccountId ?? ""
                }
            });

            if (user) {
              token.uid = user.id;
            }

            return token;
},

The JWT callback retrieves a user record based on their provider account ID and attaches their UID to the JWT token.

async signIn({ user, account, profile, email, credentials }: any) {
   // Sign-in logic...
}

The signIn callback handles new users by creating their records in the database if they do not already exist. It generates a new Solana wallet for them upon registration.

Summary

These files work together to create a functional dashboard for users in the WazirX clone application:

Dashboard Page (page.tsx):
- Retrieves user wallet information and displays it through the ProfileCard.
- Handles server-side authentication to ensure users have valid sessions.
Profile Card Component (ProfileCard.tsx):
- Displays user-specific information and allows navigation between different functionalities such as viewing tokens or swapping.
- Manages state for selected tabs and fetches relevant data using hooks.
Token List Component (TokenList.tsx):
- Renders a list of tokens along with their balances and prices.
- Provides a structured view of assets held by the user.
Authentication Configuration (auth.ts):
- Sets up Google authentication with NextAuth.
- Manages sessions and JWTs to maintain secure access across the application.

Together, these components provide a seamless experience for users managing their cryptocurrency wallets while ensuring robust security through proper authentication mechanisms.

5] Implementing the Swap Functionality

1. `app/components/Swap.tsx`

This file implements the token swapping functionality, allowing users to exchange one cryptocurrency for another. It utilizes various hooks and components to manage user input and display relevant information.

Code Breakdown:

"use client"
import { ReactNode, useEffect, useState } from "react"
import { SUPPORTED_TOKENS, TokenDetails } from "../lib/tokens"
import { TokenWithbalance } from "../api/hooks/useTokens";
import { PrimaryButton } from "./Button";
import axios from "axios";

Imports: The file imports necessary libraries and components, including React hooks, token details, and the PrimaryButton component for triggering swaps.

export function Swap({ publicKey, tokenBalances }: {
    publicKey: string;
    tokenBalances: {
        totalBalance: number,
        tokens: TokenWithbalance[]
    } | null;
}) {
    const [baseAsset, setBaseAsset] = useState(SUPPORTED_TOKENS[0])
    const [quoteAsset, setQuoteAsset] = useState(SUPPORTED_TOKENS[1])
    const [baseAmount, setBaseAmount] = useState();
    const [quoteAmount, setQuoteAmount] = useState();
    const [fetchingQuote, setFetchingQuote] = useState(false);
    const [quoteResponse, setQuoteResponse] = useState(null);

Component Definition: The Swap component accepts publicKey and tokenBalances as props. It initializes state variables for the base asset (the asset being sold), quote asset (the asset being bought), amounts for both assets, and flags for fetching quotes.

useEffect(() => {
    if (!baseAmount) {
        return;
    }
    setFetchingQuote(true);
    axios.get(`https://quote-api.jup.ag/v6/quote?inputMint=${baseAsset.mint}&outputMint=${quoteAsset.mint}&amount=${Number(baseAmount) * (10 ** baseAsset.decimals)}&slippageBps=50`)
        .then(res => {
            setQuoteAmount((Number(res.data.outAmount) / Number(10 ** quoteAsset.decimals)).toString())
            setFetchingQuote(false);
            setQuoteResponse(res.data);
        })
}, [baseAsset, quoteAsset, baseAmount]);

Fetching Quotes: The useEffect hook triggers whenever the base asset or amount changes. It makes an API call to fetch a quote for the swap using the selected assets and amount. The response is processed to update the quote amount and store the quote response.

return 
    
        Swap Tokens

Rendering: The component renders a title and a series of input rows for swapping tokens.

 {
        setBaseAmount(value);
    }}
    onSelect={(asset) => {
        setBaseAsset(asset)
    }}
    selectedToken={baseAsset}
    title={"You pay:"}
    topBorderEnabled={true}
    bottomBorderEnabled={false}
    subtitle={
        
            Current Balance:
        
        
            {tokenBalances?.tokens.find(x => x.name === baseAsset.name)?.balance} {baseAsset.name}
        
    }
/>

Swap Input Row: The first SwapInputRow allows users to input the amount of the base asset they wish to swap. It displays the current balance of that asset as a subtitle.


     {
        let baseAssetTemp = baseAsset;
        setBaseAsset(quoteAsset);
        setQuoteAsset(baseAssetTemp);
    }} className="cursor-pointer rounded-full w-10 h-10 border absolute mt-[-20px] bg-white flex justify-center pt-2">

Swap Icon: A clickable icon allows users to switch between the base and quote assets.

 {
    setQuoteAsset(asset)
 }} selectedToken={quoteAsset} title={"You receive"}  topBorderEnabled={false} bottomBorderEnabled={true} />

Receiving Input Row: The second SwapInputRow displays the amount of the quote asset that will be received after the swap. It is disabled while fetching quotes.


     {
        // trigger swap
        try {
            const res = await axios.post("/api/swap", {
                quoteResponse
            })
            if (res.data.txnId) {
                alert("Swap done!");
            }
        } catch(e) {
            alert("Error while sending a txn")
        }
    }}>Swap

Swap Button: When clicked, this button triggers an API call to execute the swap using the previously fetched quote response. If successful, it alerts the user that the swap is complete.

2. `app/api/swap/route.ts`

This file handles the backend logic for executing token swaps when a user initiates a swap request.

Code Breakdown:

import { authConfig } from "@/app/lib/auth";
import { getServerSession } from "next-auth";
import { NextRequest, NextResponse } from "next/server";
import db from "@/app/db";
import { Connection, Keypair, VersionedTransaction } from "@solana/web3.js";

export async function POST(req: NextRequest) {

Imports: The file imports necessary modules for session management, database access, and Solana transaction handling.

const connection = new Connection("");
const data: { quoteResponse: any } = await req.json();
const session = await getServerSession(authConfig);

Connection Setup: Establishes a connection to Solana's mainnet using Helius RPC. It also retrieves the request body containing the quote response and checks if the user session is valid.

if (!session?.user) {
    return NextResponse.json({
        message: "You are not logged in"
    }, {
        status: 401
    });
}

Session Validation: If no user session exists, it returns a 401 Unauthorized response.

const solWallet = await db.solWallet.findFirst({
    where: {
        userId: session.user.uid
    }
});

Wallet Retrieval: Queries the database for the user's associated Solana wallet based on their UID.

if (!solWallet) {
    return NextResponse.json({
        message: "Couldn't find associated Solana wallet"
    }, {
        status: 401
    });
}

Wallet Existence Check: If no wallet is found, it returns a 401 Unauthorized response.

const { swapTransaction } = await (
    await fetch('', {
      method: 'POST',
      headers: {
          'Content-Type': 'application/json'
      },
      body: JSON.stringify({
          quoteResponse: data.quoteResponse,
          userPublicKey: solWallet.publicKey,
          wrapAndUnwrapSol: true,
      })
  }).json();

Executing Swap Transaction: Sends a request to Jup.ag's swap endpoint with necessary parameters including user public key and quote response. This initiates a swap transaction on behalf of the user.

const swapTransactionBuf = Buffer.from(swapTransaction, 'base64');
var transaction = VersionedTransaction.deserialize(swapTransactionBuf);
const privateKey = getPrivateKeyFromDb(solWallet.privateKey);
transaction.sign([privateKey]);
const latestBlockHash = await connection.getLatestBlockhash();

Transaction Preparation:
- Converts the base64 encoded transaction string into a buffer.
- Deserializes it into a VersionedTransaction.
- Retrieves the user's private key from the database and signs the transaction.
- Gets the latest blockhash for transaction submission.

const rawTransaction = transaction.serialize();
const txid = await connection.sendRawTransaction(rawTransaction, {
      skipPreflight: true,
      maxRetries: 2
});
await connection.confirmTransaction({
  blockhash: latestBlockHash.blockhash,
  lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,
  signature: txid
});

Sending Transaction:
- Serializes the signed transaction.
- Sends it to Solana's network while skipping preflight checks.
- Confirms that it was successfully processed by checking its status.

return NextResponse.json({
   txid
});

Response:
- Returns a JSON response containing the transaction ID upon successful completion of the swap.

Summary

The files work together to implement a seamless token swapping feature in the WazirX clone application:

Swap Component (Swap.tsx):
- Manages user inputs for selecting tokens and amounts.
- Fetches quotes dynamically based on user input.
- Executes swaps through an API call when users confirm their transactions.
API Route (route.ts):
- Handles backend logic for executing swaps.
- Validates user sessions and retrieves wallet information.
- Interacts with external APIs to facilitate swaps on behalf of users.
- Processes transactions securely on Solana's blockchain.

Together, these components provide a robust framework for enabling users to exchange cryptocurrencies efficiently while ensuring secure interactions with blockchain technology.

Token Swaps on Solana

Token swaps on Solana involve the exchange of one token for another using automated market makers (AMMs) like those provided by Jupiter or Raydium. This process is crucial for decentralized exchanges (DEXs) and other blockchain applications. In this section, we will delve into the technical details of implementing token swaps on Solana, covering key concepts, APIs, and best practices.

Fetching Quotes and Preparing Swaps

To initiate a token swap, the first step is to fetch the quote for the desired tokens. This involves sending a request to the DEX's API to determine the best possible swap rate. For example, using Jupiter's API, you can fetch a quote response that includes the amount of tokens you can receive for a given amount of another token.

// Example request to fetch quote response
const quoteResponse = await axios.get('', {
  params: {
    inToken: 'SOL',
    outToken: 'USDC',
    amount: 0.01,
    slippage: 50 // 50 basis points
  }
});

The response from the API will contain the necessary details for the swap, including the output amount and any relevant metadata. It is essential to handle decimals correctly as different tokens have varying decimal places (e.g., USDC has six decimals).

// Handling decimals in the quote response
const outputAmount = quoteResponse.data.outAmount / Math.pow(10, quoteResponse.data.outToken.decimals);

Implementing the Swap Function

Once you have the quote response, you need to prepare and send the swap transaction. This involves creating a transaction using Solana's web3.js library and signing it with the user's private key.

Deserialize and Serialize Transactions:
- The DEX API will return a raw transaction that needs to be deserialized into a versioned transaction.
- You then serialize this versioned transaction to prepare it for signing.

// Deserializing and serializing transactions
const swapTransactionBuffer = Buffer.from(swapTransactionBase64);
const versionedTransaction = deserializeVersionedTransaction(swapTransactionBuffer);
const serializedTransaction = serializeTransaction(versionedTransaction);

Signing Transactions:
- To sign the transaction, you need to convert the private key from its stored format (e.g., comma-separated string) into a u8 array format required by Solana's web3.js.
- Use the fromSecretKey function from Solana's web3.js to generate a key pair from the private key.

// Converting private key to u8 array format
const privateKeyArray = privateKey.split(',').map(Number);
const keyPair = Keypair.fromSecretKey(privateKeyArray);

// Signing the transaction
const signedTransaction = await signTransaction(serializedTransaction, keyPair);

Sending Transactions:
- After signing, send the transaction to the Solana blockchain using a connection object.
- Wait for the transaction to confirm and return its ID to the user.

// Sending transactions
const connection = new Connection('');
await connection.sendRawTransaction(signedTransaction.serialize());
const transactionId = await connection.confirmTransaction(signedTransaction.id);
return transactionId;

Handling Errors and Improving UX

Token swaps on decentralized exchanges can be slow and prone to errors due to factors like high gas fees or network congestion. To improve user experience:

Debounce Requests: Implement debouncing mechanisms to prevent sending multiple requests in quick succession, which can lead to incorrect quotes or failed transactions.
Error Handling: Use try-catch blocks to handle errors during transaction processing and provide clear error messages to users.
Alerts: Add alerts for successful transactions to notify users when their swaps are complete.

// Example of debouncing requests using useEffect with cancel effect
useEffect(() => {
  if (!mounted.current) return;
  setFetchingQuote(true);
  const fetchQuote = async () => {
    try {
      const quoteResponse = await axios.get('', {
        params: {
          inToken: 'SOL',
          outToken: 'USDC',
          amount: 0.01,
          slippage: 50 // 50 basis points
        }
      });
      // Handle quote response...
    } catch (error) {
      console.error('Error fetching quote:', error);
    } finally {
      setFetchingQuote(false);
    }
  };
  fetchQuote();
}, [mounted]);

// Example of error handling during transaction processing
try {
  const signedTransaction = await signTransaction(serializedTransaction, keyPair);
  const connection = new Connection('');
  await connection.sendRawTransaction(signedTransaction.serialize());
  const transactionId = await connection.confirmTransaction(signedTransaction.id);
  return transactionId;
} catch (error) {
  console.error('Error sending transaction:', error);
  throw new Error('Failed to send transaction');
}

Conclusion

Implementing token swaps on Solana involves fetching quotes from DEX APIs, preparing and signing transactions using Solana's web3.js library, and sending these transactions to the blockchain. By handling errors properly and improving user experience through debouncing and alerts, you can create a more reliable and user-friendly token swap service. However, it is crucial to address issues related to high gas fees and network congestion by exploring alternative solutions such as multi-sig wallets or better RPC providers.

By following these steps and best practices outlined above, you can build a robust decentralized exchange that leverages the power of Solana's blockchain technology while providing a seamless experience for users.

Secure Storage of Private Keys in Centralized Exchanges

The secure storage of private keys is a critical aspect of centralized exchanges, particularly when dealing with cryptocurrencies. In this section, we will delve into the challenges and best practices for managing private keys, highlighting the risks associated with centralized storage and exploring more secure alternatives.

Centralized Storage Risks

Centralized storage of private keys poses significant risks, including the potential for unauthorized access and theft. For instance, if a centralized database contains all private keys, a malicious actor could potentially extract all the private keys and drain the associated funds. This approach, although easier to implement, is highly insecure and has been used by some platforms with limited security measures, such as encrypting the private keys stored in the database. However, this method still leaves the keys vulnerable to unauthorized access.

**Example SQL Query Risk:**
```sql
SELECT private_key FROM users WHERE user_id = 'example_user';

This query can be used to extract a private key from a centralized database, exposing the user's funds to potential theft.

Multi-Signature Approach

A more secure approach involves using multi-signature wallets. This method ensures that no single entity has control over the funds, requiring multiple signatures to authorize transactions. Here’s how it works:

Multi-Signature Setup:
- When a user signs up, create a new multi-signature wallet (vault) with multiple signers.
- Each signer is associated with a different private key, ensuring that no single key can authorize transactions.
Transaction Process:
- When a user initiates a transaction (e.g., swapping or transferring funds), the request must be signed by at least two out of three signers.
- This process ensures that even if one signer is compromised, the transaction cannot be completed without additional verification.
Implementation Considerations:
- Open-Source Solutions: Using open-source multi-signature implementations like Squad on Solana can be effective but comes with a one-time fee per vault creation, which may be impractical for large user bases.
- Custom Implementation: Deploying a custom multi-signature protocol contract can be more cost-effective but requires careful consideration of licensing and security implications.
Attack Vectors:
- Even with multi-signature wallets, there are potential attack vectors such as an engineer within the team sending malicious requests on behalf of users.
- To mitigate this, end-to-end encryption between the user's request and the signers is necessary to ensure that requests are not tampered with or originated from unauthorized sources.
Performance Considerations:
- The multi-signature process can introduce latency as each transaction requires multiple signatures, potentially slowing down transaction times.

Conclusion

Securely storing private keys in centralized exchanges is a complex task that requires careful consideration of both security and performance. While centralized storage is easier to implement, it poses significant risks. The multi-signature approach offers a more secure solution by distributing control among multiple entities, but it also introduces additional complexity and potential latency. By understanding these challenges and implementing robust security measures, exchanges can significantly reduce the risk of unauthorized access and ensure the safety of user funds.

Best Practices for Secure Private Key Storage

Avoid Centralized Databases:
- Do not store all private keys in a single database as this makes them highly vulnerable to theft and unauthorized access.
Use Multi-Signature Wallets:
- Create multi-signature wallets with multiple signers to ensure that no single entity controls the funds.
- Implement end-to-end encryption to prevent tampering with transaction requests.
Choose Secure Storage Solutions:
- Consider using open-source solutions like Squad on Solana or custom implementations that fit your specific needs.
- Ensure that any chosen solution is well-tested and secure.
Monitor and Log Transactions:
- Implement robust logging and monitoring systems to detect any suspicious activity.
- Regularly review transaction logs to identify potential security breaches.
Educate Users:
- Inform users about the importance of keeping their private keys secure and the risks associated with centralized storage.
- Provide guidance on how to manage their keys securely.

By following these best practices, centralized exchanges can significantly enhance the security of private key storage, protecting user funds from potential threats.

References

Stack Overflow: How to store access keys/private keys safely in database
Oracle Documentation: Using Oracle Wallet Manager
Reddit: Secure User Wallet Storage for Centralized Crypto Exchange (CEX)
Chainstack: How to store private keys securely
Bubble Forum: Best practice to save a private key in the database

This comprehensive guide provides detailed insights into the challenges and best practices for securely storing private keys in centralized exchanges, ensuring the safety and integrity of user funds.

Building A Centralized Exchange (Zerodha)

Wed, 17 Jul 2024 21:24:39 GMT

High-Level Requirements of an Exchange

1] User Registration and KYC

Users need to sign up and complete the Know Your Customer (KYC) process
KYC involves providing identification documents like Aadhaar or PAN card
This ensures users have a Demat account and are Indian citizens

2] Balances and Funds Management

Users can view their current balances, including cash and stock holdings
Initially, users have zero cash balance and no stock holdings
Users can transfer funds from their bank account to the exchange

3] Trading Functionality

Users can buy and sell listed stocks on the exchange
Buying stocks deducts the cost from the user's cash balance and credits the stocks
Selling stocks removes the stocks from the user's holdings and adds the sale proceeds to the cash balance

4] Order Types

Users can place different types of orders, such as limit orders and market orders (explained later)

5] Open Orders and Trade History

Users can view their open (pending) orders
Users can access their trade history, including executed orders

How Does an Exchange Work?

1] User Registration and Authentication

Users sign up and sign in to the exchange platform

2] KYC and Demat Account Linking

Users complete the KYC process by providing required documents
Users link their Demat account to the exchange

3] Order Placement

Users can place orders to buy or sell stocks listed on the exchange
Two main order types: limit orders and market orders (explained later)

4] Balance and Holdings Management

Users can view their cash balance and stock holdings
Cash balance is updated based on buy and sell transactions
Stock holdings are updated based on executed buy and sell orders

5] Order Execution and Settlement

Orders are matched and executed based on the exchange's order matching engine
Executed trades are settled, and balances are updated accordingly

Price Determination Through Supply and Demand

The price of a stock or any asset is determined by the principles of supply and demand. Here's how it works in our day to day lives:

1] Supply and Demand Imbalance

If there are more buyers (demand) than sellers (supply) for a particular stock, the price tends to rise
If there are more sellers than buyers, the price tends to fall

2] Buyer and Seller Competition

When there is high demand, buyers compete by offering higher prices to acquire the stock
When there is high supply, sellers compete by lowering prices to attract buyers

Land Buying Example

To illustrate the concept of supply and demand, consider the example of buying a plot of land:

Buyer's Offer: A buyer approaches a broker and expresses willingness to pay, say, ₹40 lakhs for a plot of land
Seller's Counteroffer: The broker contacts the seller (owner of the land), who counters with an offer to sell at ₹42 lakhs
Negotiation and Convergence: The buyer and seller negotiate until they reach an agreed-upon price, or the deal falls through
Multiple Buyers and Limited Supply: If there are multiple buyers interested in the same property (high demand) and limited supply, buyers may outbid each other. This drives up the price as buyers compete to acquire the property
Multiple Sellers and Limited Demand: Conversely, if there are multiple sellers and limited demand, sellers may lower their prices to attract buyers. This drives down the price as sellers compete to sell their properties

The principles of supply and demand apply to various assets, including stocks, real estate, and cryptocurrencies, determining their prices in the market.

Financial Jargons to Understand Exchanges

1] Order Books

An order book is a central record that displays the outstanding buy and sell orders for a particular asset, such as a stock or cryptocurrency. It provides a transparent view of the supply and demand for that asset at various price levels.

To understand order books better, let's consider an example:

Imagine there are eight identical plots of land in Indiranagar, Bangalore. If you are a buyer interested in purchasing one of these plots, you would approach a broker and place your best offer, say ₹40 lakhs.

The broker maintains an order book, which is a record of all the buy and sell orders for these plots. Your offer of ₹40 lakhs would be recorded as a "bid" in the order book, represented by a green circle.

Now, if a seller comes along and is willing to sell one of the plots for ₹42 lakhs, the broker would record this as an "ask" in the order book, represented by a red circle.

The order book would then display:

Bids (green circles): The prices buyers are willing to pay, arranged from highest to lowest.
Asks (red circles): The prices sellers are willing to accept, arranged from lowest to highest.

As more buyers and sellers enter the market, their respective bids and asks are added to the order book. The goal is for the bids and asks to converge, where a buyer's bid matches a seller's ask. At this point, a transaction can occur, and the respective orders are removed from the order book.

For example, if a buyer increases their bid to ₹41 lakhs, and a seller lowers their ask to ₹41.5 lakhs, the spread between the bid and ask narrows. Eventually, when a bid and ask match, the transaction is executed, and the asset (in this case, the plot of land) is transferred from the seller to the buyer.

The order book provides transparency by displaying the current supply and demand for an asset at various price levels. It helps buyers and sellers make informed decisions based on the prevailing market conditions.

Understanding order books is crucial in comprehending the price discovery mechanism in financial markets, as the last executed transaction price becomes the current market price for that asset.

2] Price of a Stock

The price of a stock is determined by the last executed order in the exchange's order book. Here's how it works:

Each stock exchange (e.g., Zerodha, Groww) maintains its own order book for a particular stock.
The order book records all the outstanding buy (bid) and sell (ask) orders for that stock at various price levels.
When a buy order matches a sell order, a transaction is executed at an agreed-upon price.
The price at which this last transaction occurred becomes the current market price of the stock on that exchange.

For example, if the last executed order for Tata Steel on Zerodha was at ₹200.10, then the current market price of Tata Steel on Zerodha would be ₹200.10. However, on a different exchange like Groww, the last executed order for Tata Steel might have been at ₹200.05, making that the current market price on Groww.

While different exchanges may have slightly different prices for the same stock at any given time, the actual real-world price is typically calculated by taking inputs from all major exchanges and determining a consolidated price.

Thus, the price of a stock is not an average of past transactions or a predetermined value. It is simply the last price at which a buy order and a sell order were matched and executed on a particular exchange's order book.[1] This price represents the fair market value of the stock at that moment, as determined by the forces of supply and demand.

3] Limit Order

A limit order is a type of order where the trader specifies the maximum price they are willing to buy or the minimum price they are willing to sell a particular quantity of an asset.

When placing a limit order, the trader sets:

The quantity of the asset (e.g., 10 stocks of Apple)
The limit price at which they want to buy or sell

For example, a buy limit order could be "Buy 10 stocks of Apple at $150 or lower per share." This order will only execute if the market price is $150 or less. If the market price is higher than $150, the order will remain in the order book until the price drops to $150 or lower, or until the order is canceled.

Similarly, a sell limit order could be "Sell 10 stocks of Apple at $160 or higher per share." This order will only execute if the market price is $160 or higher. If the market price is lower than $160, the order will remain in the order book until the price rises to $160 or higher, or until the order is canceled.

Limit orders provide traders with control over the price at which they are willing to execute a trade. However, there is a risk that the order may not execute if the market price never reaches the specified limit price. Hence, they are typically used by traders who have a specific price target in mind and are willing to wait for the market to reach that price level before executing the trade.

4] Market Order

A market order is a type of order where the trader instructs the broker or exchange to execute the trade immediately at the best available market price.

When placing a market order, the trader specifies only the quantity of the asset they want to buy or sell. The price is determined by the current market conditions and the availability of orders in the order book.

For example, if a trader places a market order to buy 100 shares of a stock, the order will be filled by taking the best available ask prices (sell orders) from the order book until the entire quantity of 100 shares is filled.

Market orders are typically used by traders who prioritize immediate execution over a specific price. However, there is a risk that the market order may execute at an unfavorable price, especially in volatile or illiquid markets, as the order will be filled at the best available prices in the order book at the time of execution.

Market orders are often used by retail traders who want to buy or sell an asset quickly without having to specify a limit price. However, it's important to note that market orders can result in higher trading costs due to potential slippage (the difference between the expected price and the actual execution price).

Both limit orders and market orders are essential tools for traders, each with its own advantages and risks. Traders must carefully consider their trading strategies, risk tolerance, and market conditions when deciding which order type to use.

5] Liquidity and Market Depth

Liquidity and market depth refer to the ability of a market to handle large orders without significantly impacting the price of an asset. In the context of an exchange, these terms are closely related and describe the state of the order book.

Liquidity refers to the ease with which an asset can be bought or sold without causing a significant change in its price. A liquid market has a high volume of trading activity and a large number of buy and sell orders in the order book.
Market depth, on the other hand, refers to the quantity of orders available at different price levels in the order book. A market with high depth has a large number of orders concentrated around the current market price, allowing large orders to be executed without significantly moving the price.

When an order book has high liquidity and depth, it can absorb large buy or sell orders without causing significant price fluctuations. This is because there are enough orders on both sides of the book to match the incoming orders without depleting the available supply or demand.

For example, if a trader wants to buy 10,000 shares of a stock, a liquid market with high depth would have enough sell orders at or near the current market price to fill the order without significantly driving up the price. Conversely, if the market lacks depth, a large buy order could quickly consume the available sell orders, causing the price to rise sharply.

Exchanges strive to maintain high liquidity and market depth to ensure efficient price discovery and smooth trading operations. They often incentivize market makers, who are firms or individuals that provide liquidity by continuously placing buy and sell orders in the order book, to enhance market depth and liquidity.

Market makers are incentivized through various means, such as lower trading fees, rebates, or other incentives, to encourage them to provide liquidity and maintain tight bid-ask spreads (the difference between the highest buy order and the lowest sell order).

Maker and Taker

In the context of an exchange, the terms "maker" and "taker" refer to the roles played by traders in executing orders.

A maker is a trader who places an order in the order book, providing liquidity to the market. When a maker's order is matched and executed against an incoming order, they are considered the liquidity provider.
A taker, on the other hand, is a trader who submits an order that is immediately matched and executed against an existing order in the order book, removing liquidity from the market.

For example, if a trader places a buy order at the current market price, they are considered a taker because their order is immediately matched and executed against existing sell orders in the order book, consuming the available liquidity.

Exchanges often incentivize makers by charging them lower trading fees compared to takers. This is because makers are providing liquidity to the market, which is beneficial for the overall health and efficiency of the exchange. Takers, on the other hand, are charged higher fees because they are removing liquidity from the market.

The fee structure for makers and takers can vary across different exchanges and may also depend on factors such as trading volume, account type, or market conditions. Generally, the maker fee is lower than the taker fee, encouraging traders to provide liquidity to the order book.

By incentivizing makers and charging higher fees for takers, exchanges aim to maintain a healthy order book with sufficient liquidity, which ultimately benefits all market participants by facilitating efficient price discovery and trade execution.

It's important to note that the roles of maker and taker are not fixed for a particular trader. A trader can be a maker on one trade and a taker on another, depending on whether their order is adding or removing liquidity from the order book.

Why is Latency Important?

Latency is crucial in the context of exchanges and trading systems. Here's why it's important and how it's addressed for exchanges and traders:

For Exchanges:

Order Placement Time: Exchanges need to process incoming orders (limit or market) and add them to the order book as quickly as possible.
Order Book Updates: The order book is constantly changing, and exchanges must disseminate real-time updates to traders with minimal latency.
Order Acknowledgment Time: Traders need to know if their orders were accepted, filled, or partially filled in a timely manner.

For Traders:

Order Execution: Low latency is critical for traders, especially those engaged in high-frequency trading strategies, to execute orders at the desired price before the market moves.
Order Cancellation: Traders may need to cancel orders quickly in response to market changes, and high latency can lead to significant losses.
Order Priority: Some exchanges prioritize orders from traders who provide more liquidity, and low latency can give them an edge in order execution.

How is Latency Improved?

The ways to improve latency for exchanges as well as for traders are as follows:

For Exchanges:

Faster Programming Languages: Exchanges use low-level, high-performance languages like C, C++, and Rust for critical components to minimize latency.
Efficient Serialization/Deserialization: Optimizing data serialization and deserialization can significantly reduce latency in processing orders and updates.
In-Memory Order Books: Order books are often stored entirely in memory (RAM) instead of databases to minimize access latency, with mechanisms to recover from failures.

For Traders:

Proximity to Exchange Servers: Traders aim to be physically closer to exchange servers to reduce network latency.
Multiple Connections: Traders maintain multiple connections to exchanges and dynamically use the fastest one.
Fast Data Processing: Efficient serialization/deserialization and data processing libraries are used to handle real-time market data with minimal latency.
Low-Latency Prediction Models: Mathematical models are employed to predict current asset prices across exchanges, requiring low-latency data ingestion and processing.

Both exchanges and traders invest significant resources into minimizing latency, as even milliseconds can make a substantial difference in trading outcomes. Exchanges strive to provide a low-latency environment, while traders leverage various techniques and technologies to gain an edge in order execution and market data processing.

Building Exchange Orderbook

1] Requirements:

Support placing limit orders
Orders can be fully or partially executed/filled
Users can query the current order book depth (bids and asks)
Users can retrieve their account balance (cash and stock holdings)
Implement an assignment to handle market orders by first requesting a quote and then placing a limit order at the quoted price

2] Architecture:

HTTP Server
- Use Node.js with Express.js framework
- Written in TypeScript
Routes/Endpoints
- /order endpoint to place a limit order
  - Input: side (buy/sell), price, quantity, ticker/market, user ID
- /balance endpoint to retrieve user's balance
  - Input: user ID
  - Returns: user's cash balance and stock holdings
- /depth endpoint to retrieve the current order book depth
  - Returns: bids (price and quantity) and asks (price and quantity)
Order Book
- Core component to maintain the list of outstanding buy (bid) and sell (ask) orders
- Orders matched based on price-time priority
- Handle partial order fills
Order Matching Engine
- Match buy and sell orders in the order book
- Execute trades when a buy order matches a sell order (or vice versa)
User Accounts
- Maintain user accounts to track cash balances and stock holdings
- Update balances based on executed trades
Market Order Implementation (Assignment)
- User first sends a request to /quote endpoint to get the current best price
- User then places a limit order at the quoted price via the /order endpoint, effectively executing a market order

The architecture involves setting up an HTTP server with specific routes/endpoints to handle order placement, balance retrieval, and order book depth querying. The core components include the order book, order matching engine, and user account management. The assignment focuses on implementing market order functionality by combining quote requests and limit order placement.

Technical Implementation

To implement the order book in a MERN stack (Node.js, Express, and TypeScript), we will follow a structured approach. First, we will set up a Node.js server using Express and TypeScript. Then, we will create the necessary data structures and functions to manage the order book, handle order placement, order matching, and user account management.

Let's initialize a TypeScript backend in Node.js and create an index.ts file to start things off. In this file, we will import the required dependencies, set up the Express server, define routes for handling various requests (e.g., placing orders, retrieving balances, and fetching order book depth), and implement the core functionality of the order book system.

1] Imports and Setup

import express from "express";
import bodyParser from "body-parser";

export const app = express();

app.use(bodyParser({}));

The code imports the necessary modules: express for setting up the HTTP server and body-parser for parsing request bodies.
An instance of the Express application is created and assigned to the app constant.
body-parser middleware is added to parse request bodies.

2] Type Definitions

interface Balances {
  [key: string]: number;
}

interface User {
  id: string;
  balances: Balances;
};

interface Order {
  userId: string;
  price: number;
  quantity: number;
}

The code defines several TypeScript interfaces:
- Balances: An object that maps asset names (strings) to their respective quantities (numbers).
- User: An object representing a user, containing an id (string) and balances (an instance of the Balances interface).
- Order: An object representing an order, containing userId (string), price (number), and quantity (number).

3] Global Variables

export const TICKER = "GOOGLE";

const users: User[] = [{
  id: "1",
  balances: {
    "GOOGLE": 10,
    "USD": 50000
  }
}, {
  id: "2",
  balances: {
    "GOOGLE": 10,
    "USD": 50000
  }
}];

const bids: Order[] = [];
const asks: Order[] = [];

TICKER: A constant string representing the ticker symbol of the asset being traded (in this case, "GOOGLE").
users: An array of User objects, representing the initial user accounts and their balances.
bids: An array of Order objects, representing the outstanding buy orders (bids) in the order book.
asks: An array of Order objects, representing the outstanding sell orders (asks) in the order book.

4] HTTP Endpoints

/order (POST)

app.post("/order", (req: any, res: any) => {
  const side: string = req.body.side;
  const price: number = req.body.price;
  const quantity: number = req.body.quantity;
  const userId: string = req.body.userId;

  const remainingQty = fillOrders(side, price, quantity, userId);

  if (remainingQty === 0) {
    res.json({ filledQuantity: quantity });
    return;
  }

  if (side === "bid") {
    bids.push({
      userId,
      price,
      quantity: remainingQty
    });
    bids.sort((a, b) => a.price < b.price ? -1 : 1);
  } else {
    asks.push({
      userId,
      price,
      quantity: remainingQty
    })
    asks.sort((a, b) => a.price < b.price ? 1 : -1);
  }

  res.json({
    filledQuantity: quantity - remainingQty,
  })
})

- This endpoint handles the placement of limit orders.
- It expects the following request body parameters: side (string, either "bid" or "ask"), price (number), quantity (number), and userId (string).
- The fillOrders function is called to match the incoming order against the existing orders in the order book.
- If the order is fully filled, a JSON response is sent with the filledQuantity equal to the original quantity.
- If the order is partially filled, the remaining quantity is added to the bids or asks array, sorted by price.
- A JSON response is sent with the filledQuantity equal to the filled portion of the order.
/depth (GET)

app.get("/depth", (req: any, res: any) => {
  const depth: {
    [price: string]: {
      type: "bid" | "ask",
      quantity: number,
    }
  } = {};

  for (let i = 0; i < bids.length; i++) {
    if (!depth[bids[i].price]) {
      depth[bids[i].price] = {
        quantity: bids[i].quantity,
        type: "bid"
      };
    } else {
      depth[bids[i].price].quantity += bids[i].quantity;
    }
  }

  for (let i = 0; i < asks.length; i++) {
    if (!depth[asks[i].price]) {
      depth[asks[i].price] = {
        quantity: asks[i].quantity,
        type: "ask"
      }
    } else {
      depth[asks[i].price].quantity += asks[i].quantity;
    }
  }

  res.json({
    depth
  })
})

- This endpoint returns the current order book depth, which is a representation of the outstanding bids and asks at various price levels.
- It iterates through the bids and asks arrays, aggregating the quantities at each price level.
- The resulting depth is returned as a JSON response, where the keys are prices, and the values are objects containing the type ("bid" or "ask") and the aggregated quantity.
/balance/:userId (GET)

app.get("/balance/:userId", (req, res) => {
  const userId = req.params.userId;
  const user = users.find(x => x.id === userId);
  if (!user) {
    return res.json({
      USD: 0,
      [TICKER]: 0
    })
  }
  res.json({ balances: user.balances });
})

- This endpoint retrieves the balance of a specific user.
- It expects the userId as a path parameter.
- It finds the user object in the users array based on the provided userId.
- If the user is found, their balances object is returned as a JSON response.
- If the user is not found, a JSON response with USD and TICKER (GOOGLE) balances set to 0 is returned.
/quote (GET)

app.get("/quote", (req, res) => {
  // TODO: Assignment
});

- This endpoint is currently empty, but it is intended to handle quote requests for market orders (as per the assignment mentioned in the transcript).

5] Helper Functions

flipBalance

function flipBalance(userId1: string, userId2: string, quantity: number, price: number) {
  let user1 = users.find(x => x.id === userId1);
  let user2 = users.find(x => x.id === userId2);
  if (!user1 || !user2) {
    return;
  }
  user1.balances[TICKER] -= quantity;
  user2.balances[TICKER] += quantity;
  user1.balances["USD"] += (quantity * price);
  user2.balances["USD"] -= (quantity * price);
}

- This function is responsible for updating the balances of two users involved in a trade.
- It takes the userId1, userId2, quantity, and price as arguments.
- It finds the corresponding user objects in the users array.
- It updates the TICKER (GOOGLE) and USD balances of the users based on the trade details.
fillOrders

function fillOrders(side: string, price: number, quantity: number, userId: string): number {
  let remainingQuantity = quantity;
  if (side === "bid") {
    for (let i = asks.length - 1; i >= 0; i--) {
      if (asks[i].price > price) {
        continue;
      }
      if (asks[i].quantity > remainingQuantity) {
        asks[i].quantity -= remainingQuantity;
        flipBalance(asks[i].userId, userId, remainingQuantity, asks[i].price);
        return 0;
      } else {
        remainingQuantity -= asks[i].quantity;
        flipBalance(asks[i].userId, userId, asks[i].quantity, asks[i].price);
        asks.pop();
      }
    }
  } else {
    for (let i = bids.length - 1; i >= 0; i--) {
      if (bids[i].price < price) {
        continue;
      }
      if (bids[i].quantity > remainingQuantity) {
        bids[i].quantity -= remainingQuantity;
        flipBalance(userId, bids[i].userId, remainingQuantity, price);
        return 0;
      } else {
        remainingQuantity -= bids[i].quantity;
        flipBalance(userId, bids[i].userId, bids[i].quantity, price);
        bids.pop();
      }
    }
  }

  return remainingQuantity;
}

- This function is responsible for matching an incoming order against the existing orders in the order book.
- It takes the side (bid or ask), price, quantity, and userId as arguments.
- If the incoming order is a bid, it iterates through the asks array in reverse order (from highest price to lowest).
  - If the ask price is higher than the bid price, it skips that ask order.
  - If the ask quantity is greater than the remaining quantity of the bid, it partially fills the ask order, updates the balances using flipBalance, and returns 0 (indicating the bid order is fully filled).
  - If the ask quantity is less than or equal to the remaining quantity of the bid, it fully fills the ask order, updates the balances using flipBalance, removes the ask order from the asks array, and continues to the next ask order.
- If the incoming order is an ask, the process is similar but with the bids array and the order of price comparison reversed.
- If there are no matching orders or the incoming order cannot be fully filled, the remaining quantity is returned.

6] Order Book Management

The order book is represented by two arrays: bids and asks.
When a new order is placed, the fillOrders function attempts to match it against the existing orders in the order book.
If the order is partially filled, the remaining quantity is added to the appropriate bids or asks array, sorted by price.
The bids array is sorted in descending order (highest price first), while the asks array is sorted in ascending order (lowest price first).

7] User Balances

User balances are stored in the users array, where each user object has a balances property.
The balances property is an object that maps asset names (e.g., "GOOGLE" and "USD") to their respective quantities.
When a trade is executed, the flipBalance function updates the balances of the involved users based on the trade details.

Understanding Tests (index.spec.ts)

Importing Dependencies

import { app, TICKER } from "../";
import request from "supertest";

This section imports the app and TICKER constants from the main application file (../index.ts). It also imports the request module from the supertest library, which is used for testing HTTP servers.

Defining the Test Suite

describe("Basic tests", () => {
  // Test cases...
});

This block defines a test suite named "Basic tests" using the describe function provided by Jest.

Test Case: "verify initial balances"

it("verify initial balances", async () => {
  let res = await request(app).get("/balance/1").send();
  expect(res.body.balances[TICKER]).toBe(10);
  res = await request(app).get("/balance/2").send();
  expect(res.body.balances[TICKER]).toBe(10);
});

This test case verifies the initial balances of two users (with IDs "1" and "2") by sending GET requests to the /balance/:userId endpoint using the request function from supertest. It expects the initial balance of the TICKER asset (e.g., "GOOGLE") to be 10 for both users using the expect function provided by Jest.

Test Case: "Can create tests"

it("Can create tests", async () => {
  await request(app).post("/order").send({
    type: "limit",
    side: "bid",
    price: 1400.1,
    quantity: 1,
    userId: "1"
  });

  // Additional order placements...

  let res = await request(app).get("/depth").send();
  expect(res.status).toBe(200);
  expect(res.body.depth["1501"].quantity).toBe(5);
});

This test case creates three limit orders by sending POST requests to the /order endpoint using the request function from supertest. It then sends a GET request to the /depth endpoint to retrieve the order book depth and expects the response status to be 200 (OK) and the quantity at the price level 1501 to be 5.

Test Case: "ensures balances are still the same"

it("ensures balances are still the same", async () => {
  let res = await request(app).get("/balance/1").send();
  expect(res.body.balances[TICKER]).toBe(10);
});

This test case verifies that the balance of user "1" remains unchanged after creating the orders in the previous test case.

Test Case: "Places an order that fills"

it("Places an order that fills", async () => {
  let res = await request(app).post("/order").send({
    type: "limit",
    side: "bid",
    price: 1502,
    quantity: 2,
    userId: "1"
  });
  expect(res.body.filledQuantity).toBe(2);
});

This test case places a buy order (bid) for 2 units of the TICKER asset at a price of 1502 for user "1" by sending a POST request to the /order endpoint using the request function from supertest. It expects the response to indicate that the entire quantity of 2 units was filled.

Test Case: "Ensures orderbook updates"

it("Ensures orderbook updates", async () => {
  let res = await request(app).get("/depth").send();
  expect(res.body.depth["1400.9"]?.quantity).toBe(8);
});

This test case retrieves the order book depth by sending a GET request to the /depth endpoint using the request function from supertest. It expects the quantity at the price level 1400.9 to be 8 (assuming the previous order filled 2 units from the ask order at 1400.9).

Test Case: "Ensures balances update"

it("Ensures balances update", async () => {
  let res = await request(app).get("/balance/1").send();
  expect(res.body.balances[TICKER]).toBe(12);
  expect(res.body.balances["USD"]).toBe(50000 - 2 * 1400.9);

  res = await request(app).get("/balance/2").send();
  expect(res.body.balances[TICKER]).toBe(8);
  expect(res.body.balances["USD"]).toBe(50000 + 2 * 1400.9);
});

This test case verifies the updated balances of users "1" and "2" after the order execution by sending GET requests to the /balance/:userId endpoint using the request function from supertest. For user "1", it expects the TICKER balance to be 12 (initial 10 + 2 units bought) and the USD balance to be decreased by the cost of the 2 units (2 * 1400.9). For user "2", it expects the TICKER balance to be 8 (initial 10 - 2 units sold) and the USD balance to be increased by the proceeds from selling 2 units (2 * 1400.9).

This test suite uses the supertest library to send HTTP requests to the order book system implemented in the Node.js application and verifies the expected behavior by making assertions using the expect function provided by Jest. It covers various aspects of the order book system, including order placement, order matching, order book depth updates, and balance updates after order execution.

Announcing the WEB3 and web-dev Cohort !!

Sun, 07 Jul 2024 20:00:51 GMT

Hello everyone! Welcome to the launch of 100xDevs Cohort 3.0. In this video, I'll guide you through the syllabus for the upcoming cohort, the technologies we'll be learning, the schedule for live classes, pricing details, and the exciting projects we’ll be building. Without further ado, let's dive in!

Reflecting on Cohort 2.0

Before delving into the new syllabus, let’s recap Cohort 2.0:

Topics covered: DevOps, Full Stack Development, multiple projects, open-source contributions, and system design.
Duration: 8 months, from December of last year to July 2024.

Cohort-2 Syllabus

Why Join Cohort 3.0?

Updated Curriculum: Incorporating the latest industry trends and technologies.
Live Classes: Engage in interactive, real-time session.
Teaching Assistant(TA) Support : get your doubts solved at the earliest.
Comprehensive Learning: From fundamentals to advanced concepts, all in one place.
Project-Based Learning: Hands-on projects to build real-world applications and solutions.
Extended Access: Course access for 3 years, allowing flexibility in learning pace.

Syllabus !

Web Dev : Syllabus Easy / Medium / Hard
Devops : Syllabus Easy / Medium / Hard
Web3 Client Side : Syllabus Easy / Medium / Hard
Web3 Contracts : Syllabus Easy / Medium / Hard

Projects !

Testimonials !

FIND MORE TESTIMONIALS HERE

Pricing !?

Web Development and DevOps: ₹4,999
Web3 and Blockchain: ₹4,999

Bundle (Both Cohorts) : ₹6,499 (RECOMMENDED)

Use the coupon code "EARLYBIRD" for a discount.

FAQs

Start Date: August 2nd, 2024
Discord : Starts 20th July.
Live Class Schedule:
- Web Dev : Saturdays and Sundays, 19:00 to 21:00 IST
- Web3 : Fridays, 19:00 to 21:00 IST.
Recordings Available: Yes, for all sessions.
Prerequisites:
- Web Dev : Basic knowledge of HTML, CSS, JavaScript.
- Web3 : JavaScript and basic React.
Duration: 6 to 7 months
Validity : 3 years access to course materials.

Decentralized Exchange In NodeJS

Wed, 26 Jun 2024 05:27:04 GMT

How do we Buy and Store Crypto

There are two main ways to buy and store cryptocurrencies:

Centralized Exchanges (CEXs): You can buy cryptocurrencies on centralized exchanges like Binance, Coinbase, WazirX, etc. These platforms allow you to track your balances and holdings in a user interface. However, the exchange essentially holds your crypto assets, and you don't have direct control over the private keys.
Cold Storage Wallets: These are hardware wallets (like the one shown) or software wallets (browser extensions) that store your private keys, giving you complete ownership and control over your crypto assets. As long as you have access to the wallet, no one can take your money away or block your access.

Storing your crypto in a cold storage wallet is considered more secure as you directly own and control your assets, unlike centralized exchanges where the exchange holds your funds.

How Centralized Exchanges (CEXs) Work

A centralized exchange like Binance acts as an intermediary, facilitating the trading of cryptocurrencies between buyers and sellers. There are two main types of participants on a CEX:

Market Makers: These are companies or traders that continuously place buy and sell orders for various cryptocurrencies based on algorithms that determine the fair price. They aim to buy at slightly lower prices and sell at slightly higher prices to make a profit.
Retail Traders: These are individual traders who place buy or sell orders at the available market prices, without necessarily considering the fair price.

The CEX's goal is to match the buy and sell orders from these two groups of participants and facilitate the exchange of assets, charging a small fee for each transaction.

Here's how a typical transaction works on a CEX:

A retail trader sends their cryptocurrency (e.g., 1 ETH) from their personal wallet to the exchange's wallet address.
The exchange holds this 1 ETH in its wallet.
The retail trader can then use the exchange's interface to trade their 1 ETH for another cryptocurrency (e.g., USDC) or fiat currency (e.g., USD) at the current market rate.
The exchange matches the trader's order with available buy/sell orders from market makers or other traders.
The exchange facilitates the trade, taking a small fee from both parties involved in the transaction.

The main advantage of using a CEX is the ability to easily buy, sell, and trade cryptocurrencies, as well as the option to convert between cryptocurrencies and fiat currencies. However, users don't have direct control over their assets, as the exchange holds the private keys.

How Prices are Determined in a Market

The price of an asset or commodity in a market is primarily determined by the interplay of supply and demand forces. The key factors that influence price determination are:

Number of Buyers and Sellers: The more buyers there are for a particular asset, the higher the demand, which drives up the price. Conversely, if there are more sellers than buyers, the supply exceeds demand, leading to a decrease in price.
Willingness to Buy or Sell: The price is also influenced by the eagerness or desperation of buyers and sellers. If buyers are more willing to pay a higher price, it will drive up the price. Similarly, if sellers are more desperate to sell quickly, they may accept a lower price.
Competition: The presence of competition among sellers can lead to lower prices as they try to undercut each other to attract buyers. On the other hand, limited competition or a monopolistic market can result in higher prices.

The process of price determination can be illustrated with an example of a housing market:

Suppose there are 10 houses for sale in a neighborhood, and multiple potential buyers are interested.
Initially, sellers may list their houses at different prices, say $400,000, $380,000, and $420,000.
Buyers will evaluate these prices based on their willingness to pay and make offers accordingly.
If there are more interested buyers than available houses, buyers may start bidding higher prices to secure a house, driving up the prices.
Conversely, if there are more houses for sale than interested buyers, sellers may lower their prices to attract buyers, leading to a decrease in prices.
The equilibrium price is reached when the number of buyers willing to pay a certain price matches the number of sellers willing to sell at that price.

The price of an asset or commodity in a market is determined by the dynamic interaction of supply (number of sellers and their willingness to sell) and demand (number of buyers and their willingness to buy), as well as the level of competition among sellers.

Some Jargons

1] Broker and Order Book

In traditional financial markets, there is typically a broker who acts as an intermediary between buyers and sellers. The broker maintains an order book, which is a list of buy and sell orders from various market participants, along with the quantities and prices they are willing to trade at.

2] Web2 vs Web3 and Gas Fees

In a Web2 (traditional centralized) system, maintaining an order book is feasible as there is a central authority (the exchange) that can process and match orders efficiently. However, in Web3 (decentralized blockchain-based systems), maintaining a traditional order book on-chain becomes impractical due to the gas fees associated with each transaction.

3] Liquidity Pools and Automated Market Makers (AMMs)

To address this challenge, the concept of liquidity pools and automated market makers (AMMs) was introduced in decentralized finance (DeFi). Instead of an order book, liquidity is provided by participants who deposit pairs of assets (e.g., ETH and USDC) into a shared pool.

The AMM algorithm determines the price of an asset based on the ratio of the assets in the pool, following the constant product formula: x * y = k, where x and y are the quantities of the two assets, and k is a constant.

Example

Consider a liquidity pool with 10 houses and 20 crores (CR) of cash. The initial constant product is 10 * 20 CR = 200 CR.

If someone wants to buy a house, they must deposit cash into the pool, and the price of a house is determined by the constant product formula.
For example, if the first person deposits 2.22 CR, they receive 1 house, and the pool becomes 9 houses and 18 CR (9 * 18 CR = 162 CR).
The next person must deposit more cash to receive a house, as the constant product must be maintained (e.g., 2.78 CR for the next house, leaving 8 houses and 20.78 CR in the pool).

As more assets are traded, the price of the remaining assets increases due to the constant product formula, incentivizing liquidity providers to add more assets to the pool.

Summary

Automated market makers and liquidity pools enable decentralized trading without the need for a traditional order book or market makers. The constant product formula determines the price of assets based on the ratio of assets in the pool, allowing for efficient and gas-efficient trading on blockchain networks.

The more liquidity (assets) in the pool, the smaller the price impact of individual trades, providing better pricing for users. This innovative approach addresses the challenges of maintaining order books on-chain and facilitates decentralized trading in DeFi ecosystems

Difference between CEX and DEX

1] Centralized Exchanges (CEXs)

Use traditional order books to match buy and sell orders
Rely on market makers to provide liquidity
Operated by a central authority that holds user funds
More efficient for high trading volumes
Users face counterparty risk as they don't control their assets

2] Decentralized Exchanges (DEXs)

No order books due to high gas fees for on-chain transactions
Use automated market makers (AMMs) and liquidity pools
Liquidity providers deposit asset pairs into shared pools
Prices determined by the constant product formula (x * y = k)
Decentralized, without a central authority controlling trades
Users maintain self-custody of their assets
May face liquidity challenges for less popular trading pairs

Technical Implementation

With the theoretical understanding of how automated market makers and liquidity pools work for decentralized exchanges, the next step is to implement this concept in code. The key is to create a server that supports the necessary operations for users to interact with the liquidity pool.

To bring the decentralized exchange to life, we need to develop an HTTP server that exposes the following endpoints:

Add Liquidity: This endpoint allows liquidity providers to deposit pairs of assets (e.g., ETH and USDC) into the shared liquidity pool, initializing or contributing to the constant product formula.
Buy Asset: Users can call this endpoint to purchase an asset (e.g., a house) from the liquidity pool by providing the required amount of the other asset (e.g., USDC) based on the constant product formula.
Sell Asset: Conversely, users can sell an asset they hold by calling this endpoint, receiving the corresponding amount of the other asset from the liquidity pool.
Get Quote: Before executing a trade, users can call this endpoint to obtain a quote for the amount of assets they would receive or need to provide for a specific trade, based on the current state of the liquidity pool.

By implementing these four core operations as HTTP endpoints, users and liquidity providers can seamlessly interact with the decentralized exchange, facilitating the trading of assets through the automated market maker mechanism

Setting up a Node.js Express Backend in TypeScript

To begin implementing the decentralized exchange (DEX) using automated market makers (AMMs) and liquidity pools, we'll set up a Node.js backend with Express and TypeScript. Here's how you can get started:

Initialize a new Node.js project:

mkdir dex-project
cd dex-project
npm init -

Install required dependencies:

npm install express body-parser
npm install --save-dev typescript @types/node @types/expres

We're installing express for the web server, body-parser to parse request bodies, typescript for TypeScript support, and the corresponding type definitions for Node.js and Express.
Configure TypeScript:
- Create a tsconfig.json file in the project root with the following content:

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "outDir": "dist",
    "strict": true,
    "esModuleInterop": true
  },
  "include": ["src/**/*"]
}

- This configuration sets up TypeScript to compile our code to ES6 JavaScript, with strict type checking and support for ES6 module interoperability.
Create the entry point:
- Create a src directory in the project root.
- Inside the src directory, create an index.ts file with the following content:

import express, { Request, Response } from 'express';
import bodyParser from 'body-parser';

const app = express();
const port = 3000;

app.use(bodyParser.json());

app.get('/', (req: Request, res: Response) => {
  res.send('Hello, DEX!');
});

app.listen(port, () => {
  console.log(`Server is running on port ${port}`);
});

- This code sets up a basic Express server with a root route that responds with "Hello, DEX!".
Build and run the server:
- Open package.json and add the following scripts:

"scripts": {
  "build": "tsc",
  "start": "node dist/index.js"
}

- Run the build script to compile the TypeScript code:

npm run build

- Start the server:

npm start

- You should see the "Server is running on port 3000" message in the console.

Now you have a basic Node.js Express backend set up with TypeScript support. You can access the root route by visiting

http://localhost:3000

in your web browser.

Core Backend Functionality

Now that we have out index.ts file initialized, lets jump in to write the code for handling our backend routes of the DEX.

Importing Dependencies:

import express from "express";

The code starts by importing the express module, which is a popular web application framework for Node.js.
Setting up Express:

const app = express();
app.use(express.json());

An instance of the Express application is created using express(), and the app.use(express.json()) middleware is added to parse incoming JSON request bodies.
Initializing Balances and Constant Product:

let ETH_BALANCE = 200;
let USDC_BALANCE = 700000;
const CONSTANT_PRODUCT = ETH_BALANCE * USDC_BALANCE; // 200 * 700000 = 140000000

The initial balances of ETH and USDC in the liquidity pool are set to 200 and 700000, respectively. The CONSTANT_PRODUCT is calculated by multiplying these two values, which is 140000000. This constant product will be used to determine the prices of assets in the liquidity pool.
Buy Asset Endpoint:

app.post("/buy-asset", (req, res) => {
    const quantity = req.body.quantity; // Quantity of ETH to buy
    const updatedEthQuantity = ETH_BALANCE - quantity;
    const updatedUsdcBalance = CONSTANT_PRODUCT / updatedEthQuantity;
    const paidAmount = USDC_BALANCE - updatedUsdcBalance;

    ETH_BALANCE = updatedEthQuantity;
    USDC_BALANCE = updatedUsdcBalance;

    res.json({
        message: `You paid ${paidAmount} USDC for ${quantity} ETH`
    });
});

The /buy-asset endpoint is defined to handle requests for buying ETH from the liquidity pool.
- The quantity of ETH to buy is extracted from the request body (req.body.quantity).
- The updated ETH quantity (updatedEthQuantity) is calculated by subtracting the requested quantity from the current ETH_BALANCE.
- The updated USDC balance (updatedUsdcBalance) is calculated using the constant product formula: CONSTANT_PRODUCT / updatedEthQuantity.
- The amount of USDC paid (paidAmount) is calculated by subtracting the updatedUsdcBalance from the current USDC_BALANCE.
- The ETH_BALANCE and USDC_BALANCE are updated with the new values.
- A JSON response is sent back with a message indicating the amount of USDC paid and the quantity of ETH received.
Sell Asset Endpoint:

app.post("/sell-asset", (req, res) => {
    const quantity = req.body.quantity; // Quantity of ETH to sell
    const updatedEthQuantity = ETH_BALANCE + quantity;
    const updatedUsdcBalance = CONSTANT_PRODUCT / updatedEthQuantity;
    const gottenUsdc = USDC_BALANCE - updatedUsdcBalance;

    ETH_BALANCE = updatedEthQuantity;
    USDC_BALANCE = updatedUsdcBalance;

    res.json({
        message: `You got ${gottenUsdc} USDC for ${quantity} ETH`
    });
});

The /sell-asset endpoint is defined to handle requests for selling ETH to the liquidity pool.
- The quantity of ETH to sell is extracted from the request body (req.body.quantity).
- The updated ETH quantity (updatedEthQuantity) is calculated by adding the requested quantity to the current ETH_BALANCE.
- The updated USDC balance (updatedUsdcBalance) is calculated using the constant product formula: CONSTANT_PRODUCT / updatedEthQuantity.
- The amount of USDC received (gottenUsdc) is calculated by subtracting the updatedUsdcBalance from the current USDC_BALANCE.
- The ETH_BALANCE and USDC_BALANCE are updated with the new values.
- A JSON response is sent back with a message indicating the amount of USDC received and the quantity of ETH sold.
Starting the Server:

app.listen(3000, () => {
    console.log("Server is running on port 3000");
});

The app.listen(3000, ...) method is called to start the server and listen for incoming requests on port 3000. A callback function is provided to log a message when the server starts.

This implementation follows the constant product formula for automated market makers (AMMs) to determine the prices of assets in the liquidity pool. As assets are bought or sold, the balances of ETH and USDC are updated accordingly, and the prices adjust based on the constant product formula.

Working

Here's how the constant product formula works:

The initial constant product is calculated as ETH_BALANCE * USDC_BALANCE, which is 140000000 in this case.
When a user wants to buy ETH, the quantity is subtracted from the current ETH_BALANCE, and the updated USDC balance is calculated as CONSTANT_PRODUCT / updatedEthQuantity.
When a user wants to sell ETH, the quantity is added to the current ETH_BALANCE, and the updated USDC balance is calculated as CONSTANT_PRODUCT / updatedEthQuantity.

The constant product formula ensures that as one asset is bought or sold, the price of the other asset adjusts accordingly, maintaining the constant product value. This mechanism allows for decentralized trading without the need for traditional order books or market makers.

Testing

As we see in Postman, the dynamic pricing behavior of the automated market maker (AMM) implementation is demonstrated.

When the user repeatedly sold ETH to the liquidity pool, the amount of USDC received decreased with each subsequent sale, reflecting the changing ratio of ETH to USDC in the pool based on the constant product formula.
Conversely, if another user were to start buying ETH, the price would increase due to the reduced supply of ETH in the pool. This real-time adjustment of prices based on supply and demand is a core feature of AMMs, enabling decentralized trading without the need for traditional order books or market makers.

The testing in Postman showcased how the constant product formula automatically rebalances asset prices in the liquidity pool as assets are bought and sold, maintaining an equilibrium through the market-making mechanism.

Further Reference

You can also refer to the Drift Protocol, an open-source decentralized exchange (DEX) built on the Solana blockchain. It combines different mechanisms like an order book, liquidity pools, and potentially other components to facilitate trading and swapping of assets. Despite being a DEX, it still incorporates an order book mechanism, which is more feasible on a high-throughput blockchain like Solana compared to Ethereum due to lower transaction costs.

Announcing the Launch of MERN+DevOps+System Design Cohort !

Tue, 14 Nov 2023 09:04:48 GMT

Exciting news for aspiring developers and tech enthusiasts!

We're thrilled to announce the launch of our new and improved MERN+DevOps+System Design cohort.
Building on the success of our previous cohort, which received overwhelmingly positive feedback, check out the feedback here: FEEDBACKS
we've made significant enhancements to make our course even more accessible and valuable.

Addressing Your Feedback

Your feedback is invaluable to us, and we've taken two major points to heart:

Course Pricing: We understand that affordability is key. That's why we've slashed our prices – the course now starts at just 3199 INR!
Beginner Friendliness: We've heard your requests for a more beginner-friendly approach. As a result, we've divided our cohort into two parts:

0-1 for beginners and
1-100 for more advanced learners.

0-1 Cohort: A Strong Foundation for Beginners

Our 0-1 cohort is specially designed for those just starting their journey in tech. Here's a glimpse of what you'll learn:

Foundation Javascript: From basics to the async nature of JS.
Node.js: Understanding its runtime.
Databases: Both NoSQL and SQL, with deep dives into Mongo and Postgres.
Typescript: From beginner to advanced levels.
Backend Skills: Including communication protocols, Express, ORMs, and more.
Frontend Essentials: Covering React, state management, CSS, Tailwind, and more.
Basic DevOps: Get hands-on with Docker, AWS, Nginx, and newer cloud technologies.
Projects: Practical experience with GSoC projects, building Paytm/Wallet from scratch.

1-100 Cohort: Advanced Skills for Seasoned Learners

For those familiar with our 0-1 syllabus or previous cohort participants, the 1-100 section offers advanced learning

Advanced Backend, System Design
1. Advanced backend communication
2. Message queues and PubSubs
3. Proxies, Load balancers
4. Redis Deep dive
5. Kafka Deep dive
6. Common Design Patterns in JS
7. Advanced DB concepts (Indexing, normalization)
8. Rate limitting
9. Captchas and DDoS protection
10. Sharding, Replication, Resiliency
11. Horizontal and vertical scaling
12. Polling and websockets
13. Grpc
14. Capacity Estimation
15. Load Balancers
16. CAP Theorem
17. Testing Node.js Apps in 2023
18. Real time communication, basics of WebRTC
Advanced Devops
1. Container Orchestration, Docker Swarm
2. Kubernetes
3. CI/CD
4. Monitoring systems basics to advance
5. Promhetheus, Grafana
6. Newrelic as a paid service
7. Serverless Deep dive
8. AWS Constructs (EC2, S3, CDNs, LB, EKS)
Projects
1. Zerodha end to end
2. Zapier end to end
3. Real world open source projects

Pricing and Offers

0-1 Cohort: 3199 INR!

1-100 Cohort: 3699 INR!

Combo Offer: Get both for 4999 INR!

here: https://harkirat.classx.co.in/new-courses

Are there any Prerequisites?

Don't Miss Out!

Our Early Bird + Diwali offer ends on 15th November. Prices might rise after this date, so hurry to secure your spot at these amazing rates. This is your chance to upskill and stay ahead in the tech world. Join us and embark on a journey of learning and growth with our expert-led MERN+DevOps+System Design cohort.

Enroll now and transform your tech skills! 🚀👩‍💻👨‍💻

Leave a comment

How I Earned 35 Lakhs INR in One Month!

Mon, 23 Oct 2023 21:03:55 GMT

Introduction

In today's blog, we will delve into the world of freelancing through the eyes of Harkirat. Harkirat will take us on a journey to answer some of the most pressing questions in the freelancing realm. Can one successfully work for multiple companies simultaneously? What kind of income is possible when dedicating a hundred hours a week to freelancing? And, most intriguingly, what was Harkirat's biggest freelancing month, and how much did he make?

Understanding the Freelancing Landscape:

Before we dive into the details, it's crucial to acknowledge a few disclaimers. Like any video, Harkirat's insights come with a few important notes.
Freelancing can be demanding and isn't for everyone. However, if you're here seeking motivation or keen to understand the earnings of a remote software developer, especially one who's working for multiple companies, then read on.

Harkirat's Pinnacle: July 2022

Let's rewind the clock to July 2022, a significant milestone in Harkirat's freelancing journey. At the time, he was juggling a full-time job, one he's discussed in previous content. His base salary was around $17,000 per month. But, he didn't stop there. He was also actively involved in freelancing projects, making July an exceptionally busy month.

Exploring Roles and Commitments

The responsibilities, the technologies he worked with, and the intricacies of each commitment.

Full-Time Job as Lead Video Engineer:
- Backend and Deep Tech
  - A lot of Typescript and Node.js, little bit of React.js
  - Low Latency WebRTC role.
The Second Part-Time Commitment:
- 5 Hours/Week and $125/Hour
  - The initial commitment was 20 hours/week, for two months And after that it was 5 hours/week, incase anything goes down, they had him on retainer.
The Third Project: Specializing in WebRTC:
- 20 hours/Week and $150/hour
  - Pure WebRTC, Building a Video System from Scratch
The Fourth Company: A Full-Time Endeavor:
- 40 hours/week
  - Pure Fullstack project in MERN stack.
  - Delving into Compliance and Legal Financing
  - This Finance startup company in Europe gave better learning than a giant corporate

Quantifying Earnings:
Adding things up it was: $3000 + $15000 + $7500 + $15000 = $40,500

The Evolution of Harkirat's Freelancing Journey:

Harkirat shares his journey, which began at $30 an hour in March 2020 and gradually progressed to $150 an hour. He highlights how his weekly work hours expanded from 40 hours to a remarkable 100 hours. However, he emphasizes that maintaining such an intense freelancing lifestyle isn't sustainable in the long term. Freelancing can be demanding, and effective management is crucial.

Key Takeaways and Conclusion

In conclusion, Harkirat stresses that freelancing offers an excellent opportunity for skilled software developers to earn a premium for their expertise. Whether you're based in India or elsewhere, your specialized knowledge can be a valuable asset.

He advises that, as a freelancer, one must handle the legal aspects properly, set clear expectations, and always remember that their skills are highly sought after.

hoping that this insight into his freelancing journey serves as a valuable resource for those considering freelancing as a career option.

Leave a comment

How AI will change the 9-5 Job!

Mon, 25 Sep 2023 21:13:19 GMT

Watch now on Youtube

1. Scope of AI in My Routine

My workday primarily revolves around programming, dedicating 8 to 10 hours a day to coding. Additionally, I handle filmmaking tasks and manage this YouTube channel, which involves shooting, editing, and various operational activities.
I've identified two tasks within my daily routine that could be effectively outsourced to AI.

Coding Assistance: While I remain the architect of the applications I develop, there are instances where I can envision how code should be written. Instead of manually typing it, I believe I should be able to explain my intentions to an AI, which can generate the code for me. This is already possible to some extent using AI models like ChatGPT.
Video Editing and Channel Management: Video editing and managing a YouTube channel involve a lot of manual work, from reviewing videos to analyzing performance data. An AI could monitor my channel, recommend thumbnail and title changes, and handle some editing tasks, reducing my involvement in these aspects.

2. Current Limitations of AI

Before we delve into the potential solutions and the future, it's essential to acknowledge the limitations of current AI technologies.

Time Limitations of ChatGPT: While ChatGPT is a powerful tool, it has its limitations. It might not understand newer programming libraries or offer outdated syntax. This issue is expected to be resolved as AI models improve over time.
AI's Text-Centric Nature: Current AI models primarily understand text and lack the ability to comprehend other data types like video, files, or computer interfaces. Integrating these capabilities into AI systems is a challenge.
Static Nature of AI: AI systems typically respond to specific queries but don't proactively seek solutions or identify problems independently. They lack the dynamic problem-solving abilities that humans possess.
Lack of Chaining in AI: Most AI models provide discrete responses to queries and don't naturally chain tasks together. This limits their ability to handle complex, multi-step tasks seamlessly.

3. Solutions !

Refer to the above video to know possible targets and solutions.

4. Companies and Projects to get Started !

If you're interested in this evolving field of AI, here are some companies and projects worth keeping an eye on:

Langchain: Langchain allows you to create agents that can offload tasks to other agents, making it a powerful tool for context-aware automation.
smolAI: This project focuses on generating code for specific websites and can iteratively improve the code based on user feedback. It's a great example of AI-assisted web development.
Private AI Models: Keep an eye on companies developing AI models that respect user privacy by hosting them privately. This addresses concerns about data privacy and AI usage.
In conclusion, the future of work, especially in fields like programming and content creation, is set to be transformed by AI. The limitations of today are being actively addressed, and we can expect more capable and dynamic AI systems in the near future. By staying informed and exploring projects like Langchain and smolAI, you can be at the forefront of this AI-powered revolution. I'm optimistic about the potential benefits this will bring to my workday and to many other industries. Let's keep an eye on these developments and see how they unfold in the coming months and years.
Leave a comment

GSOC 2024 Complete Roadmap-Takeaways!

Wed, 13 Sep 2023 22:04:52 GMT

Watch now on Youtube

Introduction

This journey, which began nearly eight years ago, can be traced back to a single decision I made in college—to apply for Google Summer of Code (GSoC). At the time, I was presented with two high-level paths: algorithms and development. I chose the latter, setting in motion a series of events that would shape my career in software development.

In this blog, I want to take you through a journey as if I were a college student gearing up for the next season. Whether you're interested in GSoC or pursuing a career in open source, the roadmap I'm about to outline can serve as a valuable guide.

1. Choose Your Tech Stack

The first step in your GSoC journey is to select a technology stack to focus on. Four general stacks are popular in GSoC organizations:

JavaScript/TypeScript
Python
Java, and
C++

Each has its unique advantages and potential career implications. Choose the one that aligns with your long-term goals and start learning it.

2. Find and Contribute to Organizations

Identify at least two organizations that align with your chosen tech stack. Building a good reputation within these organizations is key. Start by solving small issues, introducing yourself in their community channels, and making your presence felt.

By the time January rolls around, maintainers should recognize you as a valuable contributor.

3. Be Aggressive with Contributions

As the new year begins, step up your contributions. Take on bigger tasks, and demonstrate your ability to work independently.

While many newcomers flood in during January, your early reputation and contributions can set you apart. Continue actively contributing until the results are announced.

4. Create Polished Proposals

Around February, start working on your GSoC proposals. Aim to submit two to three proposals across different organizations.

While the proposal is essential, remember that your contributions speak volumes. A well-crafted proposal is the final piece of the puzzle, but it should not be the sole focus of your efforts.

A Few Don’ts to Keep in Mind!

Don't be overly aggressive or pushy in your communications with maintainers.
Don't give the impression that you're only interested in GSoC; focus on building your open source profile.
Don't bombard maintainers with questions, especially for local setup issues.
Don't tackle huge issues right away; gradually build up to larger tasks.
Always maintain politeness and clarity in your interactions.

In your GSoC journey, remember that contributions matter most, followed by your reputation with maintainers, and then the quality of your proposal. Luck, timing, and other factors also play a role. Even if you don't make it into GSoC, the knowledge and experience gained through this process can be invaluable for your long-term career in software development.

Your journey might lead to your own "butterfly effect" moment that propels your career to new heights.

Leave a comment

The Latest Tech Stack: Building a Modern Full Stack Application

Wed, 13 Sep 2023 21:45:56 GMT

1. The Back End: Rust, Golang, or Node.js

When it comes to the back end, you have a choice: Rust, Golang, or Node.js. Rust and Golang

all of them offer speed, low-level control, and multi-threading capabilities, making them ideal for performance-critical applications. If you opt for Node.js, consider using Next.js for backend routes.

2. The Front End: Next.js

The front end has seen a shift towards Next.js, specifically Next.js 13. It introduces features like server-side components and client-side components, making it an exciting choice. Embrace TypeScript for strict typing and consider using Tailwind CSS for styling.

3. State Management: Recoil

For state management on the front end, Recoil is gaining popularity. It offers a robust solution for managing application state efficiently.

Follow the video to know about:

Databases
Deployment
Authentication and Monitoring

The Project

To put these concepts into practice, check out the open-source project dub.sh. It's a link-tracking application, similar to Bitly, built with the stack we discussed.

It's an excellent resource to gain hands-on experience with modern full-stack development.

Conclusion:

In the ever-evolving landscape of software development, staying updated with the latest technologies is crucial. The stack we've explored today represents a modern approach to full-stack development, but remember that trends may shift.

Leave a comment

Teachers' Day Offer

Tue, 05 Sep 2023 12:50:14 GMT

1. ALERT!

This is the last call for the Full Stack Web Dev cohort if you've been wanting to join. We're done with 13 weeks and have ~8 more weeks to go. Only join if you're comfortable with React already. Otherwise please wait for the next one.

Use code TEACHERSDAY for 25% discount.

Purchase Now

2. Syallbus of the Cohort

The cohort syllabus has been as follows until now:

Week 1
- JS, Pre-requisites, Async JS
Week 2
- Backend (Express, Node.js, middlewares)
- Auth using JWT
- Databases, MongoDB
Week 3
- Archaic Frontends
- Introduction to reconcilers, building our own reconciler
Week 4
- React, Custom hooks, Basic hooks
Week 5
- Consolidation, axios, mui
- Building TO-DO app
- Context, Recoil, prop drilling
Week 6 (Break)
- peer-to-peer WebRTC
- Building a Google meet Clone
Week 7
- state management using recoil
- intro to TypeScript
- Moving from JS to TS
Week 8
- Generics in TS
- Zod for input validation
- Deploying packages to the npm registry
- Monorepos, Using Turborepo
Week 9
- BLR Meet-up
- Github CI/CD
- Deploying Backends
Week 10
- Deploying Frontend
- Server side Rendering
- Next.js
Week 11
- Building a complete end to end mono repo
- Deploying it on aws using CI/CD
Week 12
- GraphQL
- Open API SPec
Week 13
- more type safety
- TRPC

This has been the syllabus till now, far different and extended from the initial syllabus

The Upcoming syllabus would be as follows:

Week 14
- SQL (Basics)
- SQL Normalization, indexing, and connecting it to GraphQL
Week 15
- Dockerization
- Autoscaling Backend using AWS
Week 16
- Tests
- CI
Open Source Projects ~ 4 Weeks

3. FAQ

Use the coupon code TEACHERSDAY for 25% OF.
Will live classes take place?
- Yes, Live classes will be scheduled every Saturday and Sunday 7 PM IST.
Where will I get the link/invite to the live class ?
- The invite will be sent to your registered email address a few hours prior to the class.
Will I have access to previous lectures if I purchase the course now ?
- Yes, You’ll have access to all the previous classes (in recorded form)
How will I have access to the recorded lectures if I purchase now?
- All the recorded lectures will be available for one year from the date of purchase. (The validity can be extended on request)
Will I have access to Discord community and Teaching Assistants(TAs)?
- Yes, you’ll have access to the cohort discord server and TAs after verifying (the verification process is discussed in the server channel itself)

Purchase Now

Leave a comment

INDEPENDENCE-DAY Offer on MERN-OS Cohort

Tue, 15 Aug 2023 06:49:58 GMT

For the past two months, Harkirat has been teaching a MERN Stack cohort. Incase you want to join the cohort it’s still open and there’s a coupon code at the end for a discount!

1. The Goal of the Cohort

Our cohort embarked on a bold mission: to demystify the intricate web of open-source projects. Picture a React project – simple when built from scratch, but overwhelming in the open-source realm.

Our objective? In a few (4) intense months, condense years of learning into focused two-hour sessions. The goal wasn't instant expertise, but to provide a context-rich dive into key concepts. The MER stack (MongoDB, Express.js, React, Node.js) was our terrain, and we hustled through it.

Sure, mastery takes time – almost a year for some concepts. Yet, we distilled essentials into four hours a week, blending assignments and online resources.

Our aim? Equipping you to decode the open-source enigma and embark on your coding journey. It's not a shortcut, but a guided path to make complex projects conquerable.

2. Why is the cohort extended from “2 months” to ”4+ months”?

the Course thrives on feedback, ensuring each class's effectiveness. The curriculum's pace is a blend of fast and adaptable, shaped by real-time responses. Our focus? Tailoring content based on what the cohort truly needs.

Open-source exploration taught us that a diverse toolkit is vital. A universal stack isn't enough. We dive into buzzwords weekly – GraphQL, TypeScript – to provide context. Our aim is not just mastering the "Month Stack," but also decoding the broader tech landscape of open source.

3+ General Feedback of the Cohort

You can find the feedbacks of the folks enrolled in the cohort on the twitter account mentioned below:

Kirat's Twitter

can get your queries addressed by the folks / moderator in the Discord Server as well :

Discord Server

4. Syllabus of the Cohort (not the initial one)

The cohort syllabus has been as follows until now:

Week 1
- JS, Pre-requisites, Async JS
Week 2
- Backend (Express, Node.js, middlewares)
- Auth using JWT
- Databases, MongoDB
Week 3
- Archaic Frontends
- Introduction to reconcilers, building our own reconciler
Week 4
- React, Custom hooks, Basic hooks
Week 5
- Consolidation, axios, mui
- Building TO-DO app
- Context, Recoil, prop drilling
Week 6 (Break)
- peer-to-peer WebRTC
- Building a Google meet Clone
Week 7
- state management using recoil
- intro to TypeScript
- Moving from JS to TS
Week 8
- Generics in TS
- Zod for input validation
- Deploying packages to the npm registry
- Monorepos, Using Turborepo
Week 9
- BLR Meet-up
- Github CI/CD
- Deploying Backends

This has been the syllabus till now, far different and extended from the initial syllabus

The Upcoming syllabus would be as follows:

Week 10
- Deploying Frontend
- Server side Rendering
- Next.js
Week 11
- Building a complete end to end mono repo
- Deploying it on aws using CI/CD
Week 12
- GraphQL
- Open API SPec
Week 13
- more type safety
- TRPC
Week 14
- SQL (Basics)
- SQL Normalization, indexing, and connecting it to GraphQL
Week 15
- Dockerization
- Autoscaling Backend using AWS
Week 16
- Tests
- CI
Open Source Projects ~ 4 Weeks

DISCOUNT CODE

ends on 15th Aug 23:59:59

Leave a comment

How to Build a Strong Open Source Portfolio: A Reality Check

Fri, 11 Aug 2023 15:32:02 GMT

Watch now on Youtube

INTRODUCTION

Hello everyone, Today's topic revolves around a common concern among developers: how to create a compelling open source portfolio. While the allure of an impressive GitHub contribution graph might be tempting, this discussion aims to provide a reality check on the importance of such portfolios. Is the pursuit of a "green" GitHub graph truly worth it? Or should you focus your energies on a different approach to building a valuable open source portfolio? Let's dive deeper.

1. The Illusion of Quantity

The quest for a vibrant green GitHub contribution graph often stems from the desire to improve job prospects. However, let's put this into perspective. Does the abundance of green squares truly matter? The answer is, not as much as you might think. While it might catch an employer's eye, it's only a superficial indicator of activity

When hiring, recruiters and potential employers prioritize the quality of your contributions over the sheer number. Instead of focusing on how many issues you've resolved, consider what impact your contributions have made. Employers are more interested in the scope of your involvement, the size of the problem you tackled, and your level of initiative.

One substantial contribution often speaks louder than a multitude of minor ones.

2. Contribution Depth over Quantity

While resolving minor issues is beneficial, true value comes from addressing significant challenges. Aiming to alleviate the pain points experienced by developers and the project's maintainers is what sets your contributions apart.

Consider this analogy: if you're solving an easily fixable typo, it might save a few minutes, but it won't leave a lasting impact. On the other hand, if you tackle a long-standing, complex problem that developers have been avoiding, your contribution becomes substantial.

Remember, your goal is to make a tangible difference, to make a task easier for your fellow developers, and to contribute to the project's progress.

3. Learning Framework: A Prerequisite

Now, let's switch gears and discuss the foundation of your contributions: your learning framework. It's crucial to prioritize learning the right things. Don't get bogged down in areas that are seldom used in real-world scenarios. Rather, focus on the technologies and languages that are integral to the industry. Seek guidance from mentors who are actively working in the field and can steer you toward what truly matters.

A real-world example serves as a valuable lesson. A friend's experience in a coding course emphasizes the importance of focusing on essential technologies. Delving deeply into technologies like TypeScript, which are extensively used in companies, is a smarter approach than spending disproportionate time on areas like CSS that have limited practical applications.

Follow the Video to know more about

The REAL open-source Portfolio

Leave a comment

Checkpoints While Learning any Technology

Mon, 07 Aug 2023 18:52:45 GMT

Web3, AI, or Full Stack: Which One to Choose?

INTRODUCTION

With the tech landscape constantly evolving, deciding where to invest your time and effort can be daunting. Each field has its unique appeal and opportunities.
Web3, also known as decentralized web or blockchain technology, is gaining momentum and disrupting various industries. AI, on the other hand, is experiencing a significant boom. Full Stack Development remains a versatile choice, as it can be applied to both web3 and AI companies, and conventional businesses as well.

While there is no one-size-fits-all answer, AI is currently riding a wave of popularity, making it a favourable choice. For those who want to be well-positioned for the future, Web3 might be the way to go, especially with the potential of a "bull run" on the horizon. However, starting with Full Stack Development is recommended as a solid foundation before delving into other technologies.

1. Full Stack Development

Checkpoints !

First Language- JavaScript
React
Moving from JS to TypeScript

Once you go through this, comes the things that differentiate you from an Average Developer

TRPC
GraphQL

Moving beyond this:

React Native (for mobile dev)
CI / CD
DevOps

2. Web3

Checkpoints !

Understanding the Jargon
Learning New Language
EVM Development [web3.js, Smart Contract Engineer]

Moving beyond EVM

creating DAPPs [Decentralised App]
Moving across chains [Cosmos, Polka-dot, Solana]
Learning Rust or C
Moving Assets across Blockchains

These are the steps we’ll be following in the WEB-3 Bootcamp coming on my channel !
My YouTube

3. AI

Disclaimer:
I have not done AI development at all other than when I was applying for my Masters and trying to impress the professors in the US.
I now want to learn AI as a hobby, not a business. One of my friend who is a PhD in Machine Learning guides me for an Hour every 15 days with:
What’s happening in the industry.
How should I learn it.

My understanding till now (of 2 weeks) :

Python (understanding the libraries and writing very basic functions in them)
1. Tensorflow
2. Numpy
3. Pandas
To go through the lectures of
1. Supervised Learning
2. Un-Supervised Learning
3. Deep Learning
4. Neural Networks

Watch the linked video to understand the above in detail

Leave a comment

Navigating through the codebase of a Million $ Company

Fri, 28 Jul 2023 15:58:03 GMT

Watch now on Youtube

INTRODUCTION

We've all been there, faced with a vast open-source project, wondering where to start and how to make meaningful contributions. The goal of this blog post is to demystify the complexity of monolithic stack applications, especially for beginners. By breaking down cal.com's codebase, we hope to provide a clear picture of how different modules interact, making it easier for developers to understand and contribute to the project.

Understanding the Project Structure

cal.com is the project we will be discussing today. It is a well-known open-source project that some of you have already set up and contributed to, while others may feel overwhelmed by its codebase. Today, we'll delve deeper into the cal.com codebase to understand how it is divided into specific modules and sub-modules, which is a common practice in most mon-stack open-source projects.

Made by a Doctor-Turned-Software Developer.

Packages Folder

When you open the cal.com project, you'll notice two main folders: "apps" and "packages." The "packages" folder is where we'll spend most of our time, and it contains a collection of small independent packages that are used by the final apps. Here are some examples of what these packages contain:

UI: This package holds all the React components used in the project, such as buttons, input boxes, and standard styling using libraries like Material-UI or Tailwind CSS.
Store/Recoil: In this package, you'll find hooks and mutations to manage the state of the application. It handles variables specific to each user or view, such as notifications or feed posts.
Config: This package includes global variables like API URLs and secrets, which are stored securely and exposed as variables for use throughout the project.
Common: It contains common types and shared components used by different modules within the project.
Types: This package houses global types used across the entire codebase.
DB/Prisma: It contains high-level functions to interact with the database, abstracting the use of raw SQL queries.

Apps Folder

The "apps" folder houses the final user-facing application. In cal.com's case, the main web application resides in the "web" folder. It contains various other apps, such as Storybook, which showcases design components, and Docs, the public documentation.

1. Storybook

Storybook is a powerful tool used to visualize and test design components without having to navigate the main application. It allows designers and front-end developers to work together effectively by sharing and reusing components.

2. Email

cal.com sends various types of emails to users, and to make them visually appealing, the project uses React to build email templates. However, since email clients don't support client-side JavaScript, server-side rendering is employed to convert the React components into static HTML, CSS, and JavaScript that are sent as emails.

To test email templates in the cal.com project, you can use an API endpoint to preview the rendered email content. This allows developers to ensure the emails look correct and function as expected before deploying them to users.

Follow the linked video to know in detail about:

Emails
Server Side Rendering

Leave a comment

Why Moving from Windows to Linux Might Be a Game Changer for Coders

Sat, 22 Jul 2023 18:32:03 GMT

INTRODUCTION

Today, we delve into an insightful video that explores the benefits of transitioning from Windows to Linux, particularly for coding purposes. The seniors at IIT Roorkee forced me to use Linux in my freshman year. Initially met with resistance due to the familiarity and comfort of the Windows environment, eventually realized the incredible advantages Linux offered for coding, leading to it becoming my primary operating system over the years.

The Power of the Terminal

The terminal or the command line interface, which may seem daunting to those uninitiated in the world of coding. However, the terminal is an incredibly powerful tool that provides developers with direct access to the file system of remote machines. This is particularly important when deploying applications on the internet since the website or app is usually hosted on a server located elsewhere.

By using the terminal, developers can quickly and efficiently make changes to their remote applications. This level of accessibility and control would be quite challenging to achieve through graphical user interfaces (GUIs) provided by operating systems like Windows.

Seamless Collaboration and Efficiency

One of the primary advantages of working in a terminal-based environment is the ease of collaboration. Multiple developers can simultaneously connect to a remote server through secure shell (SSH) sessions and work together seamlessly. In contrast, GUI-based environments struggle to offer this level of concurrent access and collaboration.

Embracing the Learning Curve

Adopting Linux and the terminal comes with a learning curve, especially if you're new to it. However, investing time and effort into learning the terminal's intricacies will undoubtedly pay off in the long run. Additionally, exploring powerful text editors like Vim or Neovim enhances productivity further.

Windows Subsystem for Linux (WSL) and Dual Booting

For those who are hesitant to fully transition to Linux, exploring the Windows Subsystem for Linux (WSL) or dual-booting between Windows and Linux. These approaches provide a gentle introduction to Linux while allowing developers to familiarize themselves with the terminal environment.

Some Assignment

To those who are just starting with Linux and the terminal, working through various assignments provided below is recommended.

Link to the Site

Conclusion

In conclusion, while the transition from Windows to Linux may initially seem intimidating, the benefits it offers for coding and development are undeniable. The terminal's versatility, collaboration capabilities, and extensive customization options make it an essential tool for any serious coder.

So, if you're a coder looking to level up your skills, consider making the switch to Linux and embracing the power of the terminal. The rewards will undoubtedly be worth the effort.

Leave a comment

5 Unique Projects ideas to land a Job

Mon, 17 Jul 2023 11:50:06 GMT

GitHub Link

INTRODUCTION

Challenging and exciting full-stack development projects to enhance your skills: Look no further! In this blog post, let’s explore five unique project ideas that go beyond the basics of full-stack development. Each project focuses on building a clone of a popular website with a special twist, pushing your abilities to the next level. So let's dive right in!

1. StreamYard Clone

StreamYard (streamyard.com) is a powerful website that allows users to stream directly from their browsers to platforms like YouTube. Your task is to create a similar platform where users can effortlessly stream their content. The main challenge lies in establishing a browser-to-RTMP connection. You'll need to build a backend service that can convert the user's input stream and overlays into the RTMP format that YouTube understands.

This can be achieved using WebRTC or WebSocket protocols. The key is to ensure smooth video streaming from the browser to the server and ultimately to YouTube.

2. Google Docs Clone

Google Docs is a widely-used collaborative document editing tool. Your goal is to create a real-time collaborative text editor similar to Google Docs. This project requires the implementation of WebSockets for real-time communication between users. Additionally, you'll need to tackle the challenge of avoiding conflicts when multiple users edit the same document simultaneously. Operational transforms can be utilized to synchronize and merge changes, ensuring a seamless collaborative experience.

3. Google Meet Clone

Google Meet is a popular video conferencing platform that enables users to connect and communicate seamlessly. Your task is to create a clone of Google Meet, focusing on the real-time video and audio communication features. Leveraging WebRTC, you'll facilitate peer-to-peer communication between users in the same room. Participants should be able to see each other's video feeds, hear the audio, and share their screens. While building this project, you'll gain a deeper understanding of WebRTC and its capabilities.

4. Google Drive Clone

Google Drive provides a robust cloud storage solution for users to upload and share files. Your project is to create a clone of Google Drive that allows users to upload files seamlessly. The main challenge lies in securely storing files directly on cloud storage platforms like AWS S3. Utilize pre-signed URLs to upload files directly from the client to the cloud storage service, ensuring the file's security and reducing the load on your server. Focus on creating a reliable and user-friendly file management system.

5. LeetCode Platform

LeetCode is a well-known coding platform that offers a wide range of programming challenges. Your task is to create a simplified version of LeetCode, where users can submit their code solutions for various programming problems. The most challenging aspect of this project is running user-submitted code in a secure and isolated environment. Utilize containerization technologies like Docker to execute the code within a restricted environment. Implement a task queue to manage code submissions and process them in a scalable and efficient manner. Provide feedback to users based on the correctness of their code solutions.

At Last

These five full-stack development projects offer exciting opportunities to enhance your skills and showcase your expertise. You can find the detailed project descriptions and resources in the project repository linked in the description. Choose the project that interests you the most and let me know in the comments which one you'd like me to build. I'll create a one-and-a-half to two-hour video where I'll time-box the development process and aim to complete all the essential functionalities.

If you get stuck somewhere you can take help from Chat-GPT however, I strongly encourage you to take on these projects yourself as well. Building them will provide valuable hands-on experience and help solidify your understanding of full-stack development concepts. Feel free to ask any questions or share your progress with me.

Happy coding!

Leave a comment

Unlocking Leverage: 5 Evergreen and Hard-to-Hire Roles in Software Development

Wed, 12 Jul 2023 16:31:35 GMT

INTRODUCTION

In the world of software development, certain roles are consistently difficult to fill. These positions require specialized skills that are not widely known or taught, giving those who possess them significant leverage during the hiring process. In the video (linked above), we have explored five unconventional roles that are currently in high demand. By acquiring these skills, you can go beyond traditional full-stack development and negotiate from a position of strength.

1. Designer Plus Front-End Developer:

One role that is highly sought after is that of a designer plus front-end developer. Rather than being solely a designer or a front-end developer, this role combines both skill sets. Companies often have separate design and development teams, but individuals who possess good design skills along with the ability to create front-end components are more sought after.

By using tools like Figma to create mockups and designs, and then converting them into React components, these individuals streamline the collaboration between designers and developers. This reduces context switching between the design team and the development team and saves time, making them a valuable asset to any fast-paced development environment.

2. Mobile App Developer with Versatility:

Another highly sought-after role is that of a mobile app developer who can handle a range of platforms. In addition to developing Android and iOS apps, proficiency in frameworks like Flutter and React Native is essential. By having experience in Swift, Java, Kotlin, React Native, and Flutter, along with deploying applications to both the App Store and the Play Store, these developers become versatile assets to any company.

With the increasing demand for mobile apps, this role ensures that you can take ownership of the entire mobile development stack.

3. Full-Stack Developer - The One-Person Army:

Being a one-person army in full-stack development is a valuable skill set. By mastering both front-end and back-end development, you become a highly sought-after candidate. Companies often face situations where there is a surplus of front-end work or a lull in back-end tasks. Having the ability to seamlessly transition between the two saves resources and makes you more appealing to employers.

Even if you primarily focus on either front-end or back-end, having a solid understanding of both areas allows you to take on tasks when needed, making you an invaluable team member.

4. DevOps Engineer with Code Awareness:

In the realm of DevOps, it is crucial to have code awareness. While many DevOps engineers focus solely on infrastructure and deployment, those who understand the application code become highly effective problem solvers. By having knowledge beyond DevOps and being able to grasp the intricacies of application code, these individuals can provide significant value during emergencies or critical situations.

Being the go-to person to fix bugs or address issues when others are unavailable makes them indispensable members of the team.

5. Dev Tooling

A role often overlooked but extremely valuable is that of a developer productivity and test advocate. These individuals focus on optimizing workflows, improving code quality, and making developers' lives easier. By reducing build times, implementing strict code checks, and introducing efficient development practices, they save time and resources for the entire team. Their expertise extends to optimizing infrastructure, making architectural decisions, and even transitioning codebases to more efficient technologies.

Their role is essential in maintaining code cleanliness, eliminating technical debt, and ensuring developer productivity.

Thank you for reading Remote work newsletter. This post is public so feel free to share it.

Leave a comment

The Best Place for Coders

Wed, 05 Jul 2023 10:37:18 GMT

INTRODUCTION

we have discussed the best countries for software developers to work in the video (linked below). Specifically the pros, cons, and unique aspects of working in different countries/cities. I have personally experienced working in these countries and shared insights about salary, taxes, living expenses, learning curve, and overall lifestyle. Please note that these are my personal experiences, and your own experiences may differ.

Bangalore

Pay-scale: 7/10
Learning curve: 8/10
Saving on Expenses: 6/10
Social-Life: 9/10

Nevertheless, Bangalore offers excellent opportunities for founders and entrepreneurs, making it a great place for networking and fundraising.

Remote work (US based)

Pay-scale: 9/10
Learning curve: 9/10
Saving on Expenses: 9/10
Social-Life: 3/10

In addition to earning a competitive salary, remote work enables developers to interact with highly skilled team members and boosts their learning curve.

U.S.A (H1B or B1/B2)

Pay-scale: 8/10
Learning curve: 9/10
Saving on Expenses: 4/10
Social-Life: 8/10

Moreover, building a strong social circle might be more difficult for some expats. Pursuing a Master's degree in the US can provide a pathway to well-paying jobs, but student loans could become a factor to consider.

DEL / HYD

Pay-scale: 7/10
Learning curve: 7/10
Saving on Expenses: 6/10
Social-Life: 7/10

Companies in these cities often prioritize profitability, which can be advantageous for employees who receive significant equity.
Joining early-stage startups could lead to substantial wealth in the long run, provided the company's profits grow steadily.
This approach is different from the valuation-focused startups prevalent in Bangalore, where equity might be worth less during VC bull runs.

Dubai, Hong Kong, Japan

Pay-scale = 8/10
Saving on Taxes = 9/10
Learning curve = 9/10
Saving on Expenses = 7/10
Social-Life = 9/10

Dubai offers a good pay scale and has a high learning curve. The expenses are moderate, and the social life is vibrant, especially for Indians.

Southeast Asia is suggested as a promising region for web3 opportunities, with potential financial growth.

My Preference would be

1. REMOTE WORK
2. South-East Asia
3.Noida [Del / Hyd]
4. U.S.A
5. Bangalore

Watch the video to know about my opinions in detail

Leave a comment

How Much HTML, CSS, & JavaScript Needed for FSD ?

Tue, 04 Jul 2023 07:30:29 GMT

INTRODUCTION

When it comes to becoming a full stack developer, knowing how much HTML, CSS, and JavaScript is enough to get started is a common question. In my experience of teaching a course on this subject, I have observed individuals who were proficient in React but struggled in the initial stages, while others with no prior knowledge excelled because they focused on building a strong foundation. In this blog post, I will provide a roadmap outlining the essential steps to take before diving into full stack development. By dedicating a few days to mastering the fundamentals, you can gain the necessary skills to confidently explore any framework of your choice. So, let's delve into and explore the crucial elements to cover in this initial phase.

1. JavaScript

In full stack development, JavaScript serves as the scripting language connecting the front-end and back-end components. Before proceeding further, it's vital to have a solid understanding of JavaScript. I highly recommend watching the video mentioned below that offers a comprehensive overview of JavaScript, covering topics such as basic syntax, for loops, if-else statements, and more. Taking the time to familiarize yourself with these concepts will make it easier to dive into frameworks like React later on.

By investing a day or two and practicing coding exercises and problem-solving on LeetCode, you can solidify your grasp of JavaScript's foundational elements.

2. HTML

While frameworks like React and Vue abstract the need for extensive HTML and CSS knowledge, it's essential to understand the underlying concepts. Begin by learning basic HTML tags, focusing on elements like divs, spans, typography, headings, input boxes, and buttons. This will allow you to create simple yet functional websites. Once you are comfortable with HTML, connect it with the JavaScript knowledge you have gained by adding functionality through event handling, such as button clicks and key presses.

Example of an Ugly looking website made using HTML

By achieving this milestone, you can create basic websites and even develop a simple game using HTML canvas, incorporating JavaScript's ability to capture and respond to key presses.

3. CSS

Next, turn your attention to CSS and explore basic styling concepts like background colors and font colors. Although modern frameworks often handle CSS abstraction, understanding how HTML tags can be styled using CSS will enable you to comprehend the underlying mechanics. Familiarize yourself with inline CSS and consider creating a structured CSS file to handle styling systematically.

You can now be creating functional as well as visually appealing websites.

At this stage, you will possess a solid foundation in HTML, CSS, and JavaScript, allowing you to build functional websites and apply visual enhancements.

4. Not yet Done !

Now you need to understand Two more things:

The Asynchronous nature of JavaScript
Talking to Backend APIs using JavaScript
DOM Manipulation

These are some very very important concepts to know before progressing with React or Vue. Follow the video below to understand these in detail.

Once your Fundamentals are strong you can use AI for assistance. Using Chat-GPT to write code which in turns write a simple HTML, CSS, JS file.
Learn HTML, CSS, JS first, then React then you are good to delegate your work to chatGPT.

Leave a comment

Remote work newsletter

Building a Music SaaS

Building a Music SaaS

Introduction to the Music SaaS Platform Project

Context and Motivation

Project Structure and Objectives

Technical Details

Future Development

Conclusion

Part 2: Initializing the Application

Introduction

Problem Statement and Inspiration

Modernizing the Idea

Use Cases

Technical Requirements

Conclusion

Part 3: Initializing the Application

Step 1: Initializing the Next.js Project

Customizing the Project Setup

Cleaning Up the Initial Project

Part 4: Adding Authentication Using Next.js

Introduction to Authentication

Setting Up Next.js for Authentication

Initializing Routes

Hands on Coding Implementation

1] Authentication and AppBar Components

Defining Route Handlers

Using Google Authentication Provider

1. Authentication Route: app/api/auth/[...nextauth]/route.ts

Key Components Explained:

2. AppBar Component: app/components/Appbar.tsx

Key Components Explained:

3. Providers Component: app/providers.tsx

Key Components Explained:

4. Layout Component: app/layout.tsx

Key Components Explained:

2] Database Schemas & Management

1. Prisma Schema: prisma/schema.prisma

Key Components Explained:

2. API Route for Streams: app/api/streams/route.ts

Imports and Constants

POST Request Handler

Key Components Explained:

GET Request Handler

Key Components Explained:

3. Database Client Setup: app/lib/db.ts

Key Components Explained:

3] Downvote Upvote Stream Routes

1. Downvote Route: app/api/streams/downvote/route.ts

Key Components Explained:

2. Upvote Route: app/api/streams/upvote/route.ts

Key Components Explained:

Comparison with Stream Management Route (app/api/streams/route.ts)

4] Building Landing Page & Components

Landing Page: app/page.tsx

Key Components Explained:

Appbar Component: app/components/Appbar.tsx

Key Components Explained:

Redirect Component: app/components/Redirect.tsx

Key Components Explained:

StreamView Component: app/components/StreamView.tsx

5] Building Dashboard Page, Utils, Finishing API Routes

Dashboard Page: app/dashboard/page.tsx

Key Components Explained:

API Route for User's Streams: app/api/streams/my/route.ts

Key Components Explained:

Utility Functions: app/lib/utils.ts

Using Regular Expressions for URL Validation

Key Components Explained:

Creator Page: app/creator/[creatorId]/page.tsx

Key Components Explained:

API Route for Next Stream: app/api/streams/next/route.ts

Key Components Explained:

Technical Details

Future Development

Building WazirX End to End

Building a Centralized Exchange: Key Considerations and Architectural Differences

Architecture of a Centralized Exchange

Conclusion

Understanding Users and Market Makers

1. Authentication Route: `app/api/auth/[...nextauth]/route.ts`

2. AppBar Component: `app/components/Appbar.tsx`

3. Providers Component: `app/providers.tsx`

4. Layout Component: `app/layout.tsx`

1. Prisma Schema: `prisma/schema.prisma`

2. API Route for Streams: `app/api/streams/route.ts`

3. Database Client Setup: `app/lib/db.ts`

1. Downvote Route: `app/api/streams/downvote/route.ts`

2. Upvote Route: `app/api/streams/upvote/route.ts`

Comparison with Stream Management Route (`app/api/streams/route.ts`)

Landing Page: `app/page.tsx`

Appbar Component: `app/components/Appbar.tsx`

Redirect Component: `app/components/Redirect.tsx`

StreamView Component: `app/components/StreamView.tsx`

Dashboard Page: `app/dashboard/page.tsx`

API Route for User's Streams: `app/api/streams/my/route.ts`

Utility Functions: `app/lib/utils.ts`

Creator Page: `app/creator/[creatorId]/page.tsx`

API Route for Next Stream: `app/api/streams/next/route.ts`

1. `app/api/auth/[...nextauth]/route.ts`

2. `app/components/Appbar.tsx`

3. `app/layout.tsx`

4. `app/page.tsx`

5. `app/providers.tsx`

1. `app/components/Button.tsx`

2. `app/components/Hero.tsx`

1. `prisma/schema.prisma`

2. `app/db/index.ts`

1. `app/dashboard/page.tsx`

2. `app/components/ProfileCard.tsx`

3. `app/components/TokenList.tsx`

4. `app/lib/auth.ts`

1. `app/components/Swap.tsx`

2. `app/api/swap/route.ts`