What is WebSocket? Why is it used & how is it different from HTTP?

Summary

This engaging tutorial delves into the world of distributed computing and real-time communication systems, with a focus on understanding WebSockets and Redis. Designed for developers seeking to enhance their skills, the video covers the need for persistent connections between clients and servers, enabling real-time updates crucial for applications like chat systems and multiplayer games. Through practical examples and code walkthroughs, viewers will learn how to create WebSocket servers, establish bidirectional communication, and leverage Redis for efficient data distribution across multiple servers. With its clear explanations and hands-on approach, this tutorial empowers developers to build scalable, responsive applications that deliver seamless real-time experiences.

Takeaways

• 👨‍💻 Distributed computing is used by large companies like Swiggy and Zomato to handle high traffic and provide real-time updates.
• 🔌 WebSockets enable full-duplex communication between the client and server, allowing real-time data transfer.
• ⚡ Realtime systems like chat apps, multiplayer games, and trading platforms require WebSockets for seamless updates.
• 📡 WebSockets establish a persistent connection between the client and server, unlike HTTP's request-response model.
• 🌐 While WebSocket is a protocol, libraries like Socket.IO provide additional abstractions and features on top of it.
• 📚 Implementing WebSockets in Node.js involves creating a WebSocket server using the 'ws' library and handling connection and message events.
• 💻 Clients like web browsers, mobile apps, and WebSocket testing tools can connect to and communicate with the WebSocket server.
• 🔀 In distributed systems, multiple WebSocket servers may need to communicate with each other using technologies like Redis to enable real-time data transfer.
• 🧱 Concepts like rooms and message types are crucial for efficient message routing and handling in real-time applications.
• 🚀 Understanding WebSockets and distributed computing principles is essential for building scalable, real-time systems like chat applications and multiplayer games.

Q & A

What is the purpose of using WebSockets?

WebSockets are used for building real-time systems where the server needs to push events or updates to the client in real-time. They provide a full-duplex communication channel over a single, long-lived connection, allowing both the client and server to send data back and forth.

How is a WebSocket connection different from an HTTP connection?

Unlike HTTP, which follows a request-response model and closes the connection after each request, a WebSocket connection is persistent and remains open until explicitly closed. This allows for real-time, bidirectional communication between the client and server without the need for constant polling or refreshing.

What is the significance of the concept of 'rooms' in WebSocket applications?

The concept of 'rooms' is used in WebSocket applications to manage and organize connections based on specific criteria or groups. For example, in a chat application, users in the same room can receive messages from each other in real-time, while users in different rooms are isolated from those messages.

Why is the choice between WebSockets and Socket.IO important?

While Socket.IO is a popular library that abstracts some of the complexities of WebSockets, it introduces its own protocol and requires both the client and server to use the Socket.IO library. Raw WebSockets, on the other hand, are a standard protocol with widespread client support across various platforms and languages, making them a more robust and interoperable choice for production environments.

What is the role of Redis in a distributed chat system?

Redis plays a crucial role in a distributed chat system by enabling communication and data sharing between multiple WebSocket servers. It provides features like pub/sub messaging, queues, and in-memory data storage, allowing WebSocket servers to broadcast messages to other servers and clients efficiently.

How does a WebSocket server handle multiple client connections?

When a client establishes a WebSocket connection with the server, the server creates a separate WebSocket instance for that client. The server can then send and receive messages to/from each client individually, or broadcast messages to multiple clients as needed.

What is the difference between WebSockets and WebRTC?

WebSockets and WebRTC are both used for real-time communication, but they differ in their underlying transport protocols. WebSockets use TCP, which guarantees reliable message delivery, while WebRTC uses UDP, which is faster but may result in some message loss. The choice between the two depends on the specific requirements of the application.

How can you test a WebSocket server before integrating it with a client application?

You can test a WebSocket server using tools like Postman or Postwoman, which provide a graphical interface for establishing WebSocket connections and sending/receiving messages. This allows you to verify the server's functionality before integrating it with a client application.

What are some typical use cases for WebSockets beyond chat applications?

WebSockets can be used in a variety of real-time applications, such as online gaming, collaborative editing tools, stock trading platforms, real-time analytics dashboards, and IoT (Internet of Things) applications.

How does WebSocket communication differ from long polling or Server-Sent Events (SSE)?

While long polling and SSE are techniques that can be used to achieve real-time communication, they still rely on HTTP requests and responses, which can be inefficient and resource-intensive. WebSockets, on the other hand, provide a dedicated, persistent connection that eliminates the need for constant polling or request overhead.

Outlines

00:00

👨‍💻 Introduction to Advanced Concepts in Distributed Computing

The speaker introduces the topic of distributed computing, explaining that they will be learning advanced concepts at a slow pace. The focus is on understanding how Backpack uses distributed computing for part of their codebase, as many big companies employ distributed computing in some form. The speaker highlights that they will learn about system design for a distributed chat system, as Backpack uses chat, and many companies require real-time communication. They will explore concepts like websockets, how backend systems communicate, Redis, and pub/sub.

05:01

🌐 Importance of Websockets for Real-time Systems

The speaker emphasizes the need for websockets in real-time systems, where the server needs to push events to the client. HTTP requests alone are insufficient for such systems, as the server cannot initiate communication. Examples like real-time todo applications, Google Docs, and chat applications are given, where events need to be pushed from the server to reflect changes across clients. Techniques like long polling and server-sent events are discussed as alternatives, but websockets are presented as the optimal solution for real-time, full-duplex communication between client and server.

10:02

🎮 Use Cases for Websockets and WebRTC

The speaker delves into use cases for websockets, such as real-time trading platforms, chat applications, and multiplayer games. The differences between websockets and WebRTC (Web Real-Time Communication) are discussed, with WebRTC being more suitable for scenarios where some data loss is acceptable, such as games. The speaker also touches on the concept of rooms, where clients are grouped, and events are broadcasted within those rooms. The importance of scalability and distributing load across multiple websocket servers is highlighted.

15:02

🔧 Setting up the Development Environment

The speaker provides instructions for cloning the project repository and opening it in Visual Studio Code. They explain the project structure, including the backend and frontend code for the websocket server, as well as TypeScript configuration files. The speaker also mentions an assignment from the previous week that they may cover if time permits.

20:04

📡 Creating a Simple Websocket Server in Node.js

The speaker walks through the process of creating a simple websocket server using Node.js and the Express.js framework. They explain the need for a native HTTP server to create a websocket server and demonstrate how to handle client connections and messages. The code snippets illustrate logging connections, receiving messages from clients, and sending responses back to the clients.

25:06

🚀 Running the Websocket Server

The speaker provides instructions for running the websocket server locally. They explain the steps involved, including compiling the TypeScript code using the TypeScript compiler (tsc) and running the compiled JavaScript file (node index.js). The speaker also mentions the ability to expose other HTTP endpoints alongside the websocket endpoint using Express.js.

30:08

🕸️ Testing the Websocket Server with a Client

The speaker introduces a tool called Postwoman (previously known as postwoman) that allows testing websocket connections, similar to how Postman is used for testing HTTP requests. They demonstrate how to establish a websocket connection to the local server, send messages, and receive responses. The speaker also mentions the need for writing additional logic in a real-world scenario, such as handling different message types and implementing specific functionalities.

Keywords

💡Distributed Computing

Distributed computing refers to the concept of splitting computational tasks across multiple interconnected computers or systems. In the context of the video, distributed computing is mentioned as a key aspect of how large companies like Backpack handle their codebase. The speaker explains that instead of running on a single server or database instance, their systems are distributed across multiple nodes that communicate with each other, enabling scalability and resilience. This is a crucial concept for building real-time applications like chat systems or multiplayer games.

💡Real-time Communication

Real-time communication refers to the ability to transmit and receive data or messages with minimal delay, allowing for near-instantaneous interactions. The video emphasizes the importance of real-time communication in various applications such as chat systems, multiplayer games, and collaborative tools like Google Docs. In these scenarios, users expect updates or events to be reflected immediately across all connected clients, which traditional client-server models cannot efficiently handle. Real-time communication is a driving factor behind the need for technologies like WebSockets.

💡WebSockets

WebSockets is a computer communications protocol that provides a full-duplex communication channel over a single TCP connection. Unlike traditional HTTP requests, which follow a request-response cycle, WebSockets establish a persistent connection between the client and server, allowing for bidirectional, real-time data transfer. This makes WebSockets well-suited for applications that require continuous updates or real-time events, such as chat systems or multiplayer games. The video introduces WebSockets as a solution for building real-time systems and discusses its advantages over techniques like long polling or server-sent events.

💡Redis

Redis is an open-source, in-memory data structure store that can be used as a database, cache, and message broker. In the context of the video, Redis is mentioned as a crucial component for enabling distributed computing in real-time applications like chat systems. Redis provides features like pub/sub (publish/subscribe), which allows different servers or nodes to communicate and share data efficiently. The video suggests that Redis will be explored further to understand how it facilitates communication between different components of a distributed chat system.

💡Client-Server Model

The client-server model is a distributed computing architecture where a client (typically a user's device or application) initiates requests to a server, which processes the requests and sends back responses. The video contrasts this traditional model with real-time systems, where the server needs to push updates or events to clients without waiting for client requests. While the client-server model works well for simple applications, it falls short for real-time scenarios like chat or multiplayer games, where continuous, bidirectional communication is required.

💡Full-duplex Communication

Full-duplex communication refers to the ability to transmit and receive data simultaneously over a single communication channel. In the context of the video, full-duplex communication is highlighted as a key feature of WebSockets, where both the client and server can send and receive data concurrently over a single persistent connection. This bidirectional communication is essential for real-time applications, as it allows the server to push updates to clients without waiting for requests, and clients to send data to the server asynchronously.

💡Persistent Connection

A persistent connection, also known as a long-lived connection, is a communication channel that remains open and active for an extended period of time, unlike traditional request-response connections that are short-lived. The video emphasizes the importance of persistent connections in real-time systems, as they allow the server to continuously push updates or events to clients without the need for constant reconnections or polling. WebSockets establish persistent connections between clients and servers, enabling efficient real-time communication.

💡Long Polling

Long polling is a technique used to emulate real-time communication in traditional client-server models. In long polling, the client sends an HTTP request to the server and keeps the connection open, waiting for the server to respond with new data or updates. If the server doesn't have any updates, the request remains open until new data becomes available or a timeout occurs. The video mentions long polling as an alternative approach to real-time communication but suggests that it is an inefficient and suboptimal solution compared to WebSockets.

💡Server-Sent Events (SSE)

Server-Sent Events (SSE) is a standard that allows servers to push data to clients over a persistent HTTP connection. Unlike WebSockets, which provide full-duplex communication, SSE is a one-way communication channel where the server can send events or updates to the client, but the client cannot initiate communication directly. The video briefly mentions SSE as another approach for real-time communication before WebSockets but suggests that WebSockets are a more optimal solution.

💡Rooms

In the context of real-time communication systems, rooms refer to logical groupings or channels where clients can be segmented based on specific criteria, such as a chat room or a game lobby. The video mentions the concept of rooms in relation to the Socket.IO library, which provides an abstraction for creating and managing rooms, allowing messages or events to be broadcast to specific groups of connected clients. This concept is essential for scalability and organization in real-time applications, where different clients may need to receive different subsets of data or updates.

Highlights

Introduction to distributed computing and its significance in large-scale web applications.

Explanation of distributed computing using the example of Swiggy's website architecture.

Introduction to the system design of a distributed chat system as a practical application of distributed computing.

Overview of real-time communication systems and their importance in modern web applications.

Introduction to websockets as a solution for real-time communication challenges.

Detailed explanation of the difference between HTTP and WebSocket protocols.

Introduction to Redis and Pub/Sub model for enhancing backend communication.

WebSocket as a persistent connection protocol allowing real-time bidirectional communication.

Use case of WebSocket in financial trading platforms for real-time data updates.

Explanation of WebSocket connections and messages through practical demonstration.

Discussion on scalability and distributed architecture of WebSocket servers.

Comparison between WebSocket and other real-time communication technologies.

Introduction to building a simple WebSocket server and client for a chat application.

Overview of the npm libraries available for creating WebSocket servers in Node.js.

Demonstration of establishing a WebSocket connection using a client application.

Transcripts

[Music]

So today we're going to learn some

Advanced uh slightly advanced concepts

but again we're going to take things

slow so don't worry too much about it

we're going to learn a little bit about

distributed computing the reason for

this is K backpack does use this for a

specific part of their code base well

most big companies use distributed C

Computing in like some form or fashion

uh if you go to a swiigy website uh

there isn't like one server that's

running on one backet that's running

there isn't a single database instance

that's running there are a bunch of them

they all talk to each other through some

form or fashion that is what the high

level goal of this week is going to be

system designed of a distributed chat

system why chat system because backpack

uses chat

and as you go deep into an organization

most company I would say most companies

but a lot of companies would have some

part of realtime communication that is

needed what is realtime communication we

will get to but the systems we've built

until now follow the client server model

very heavily if you might remember huh

in our case we have a HTTP server the

client hits the HTTP server gets back a

response this is different from how

realtime systems work how we will see

today but that's what we're going to

spend our time learning more practically

we'll learn about websockets we'll learn

about uh how backend systems can talk to

each other we'll learn about redis and

something called pop sub if we get the

time we'll dive a little deeper into

redis and understand the other things

that reddis provides you red provides

you like a mini database what's called

like an inmemory database it gives you

uh cues it gives you a pub sub it gives

you 10 different things so we'll try to

cover as many things as we can but more

practically we want to be able to look

at the chat system of backpack and

understand the chat back end which is

significantly different from the back

end we've seen until now that's the high

level of this week system design of a

distributed chat system understanding

what a websockets understanding redis

and contributing to the chat part of an

open source codebase which is backpack

this is the repository where we have all

the checkpoints for today we'll take

things slow and slowly uh you know make

our way up just just to do a quick check

before we start how many of you already

know about websockets distributed

computing redis do you already know

this yes or no and then we will

start okay so majorly know which is

great so yeah we'll take things slow and

let's try to tackle these slightly

Advanced backing Concepts this week cool

why websockets very important question

why do you learn websockets and why were

they introduced in the first place to

websockets as the name suggests is like

it is a socket which basically means it

is a connection between a client and a

server the way we have done client

server connections until now is I

apologize for the white screen my bad um

is that you have your

browser and you have an HTTP server

running somewhere these HTTP servers we

have deployed on Local Host as well we

have deployed them on AWS in various

regions as well we have seen okay you

can hit this HTTP server through an HTTP

request which could be either a get

request or a post request so on and so

forth can also send some body in here

this is one way to talk to a backend

server there's one problem here when the

problem is okay the server can never

push you events directly you always have

to ask the server for something when

this this does become a problem when is

this not a problem this is not a problem

for simple websites we have built until

now okay H by we have a Todo application

and we just hit the back end get back

our

toos but what if you want to build a

realtime too application which means

what if our Todo application has a

website it also has a mobile

app and the person adds a to-do in the

mobile app the website should also see

that reflected immediately right this

happens on notion this happens on Google

Docs if you go to Google Docs if you

type in one tab you will see your

changes in another tab if someone types

from from the other side of the world

you see those changes being typed in

real

time so to be able to communicate or

like be able to have events being

triggered in real time from the

server you need a better way to

communicate with the server more

specifically you need a persistent

connection with the server so that the

server can keep sending you events okay

oh someone added a new too or someone

added something at a specific line in

Google Docs if the can push you down

these events you don't have to worry

about sending HTTP requests to get back

the response there is a persistent

connection that persistent connection

always exists and the server can push

you things why is this useful in the

chat system if you are in a chat system

on on whatever is it called messenger SL

faceb you type a message you click on

send what happens is either an HTTP

request or something else communicates

this to an HTTP server okay H by someone

sent a message let's say hi there let's

say your friend has in another part of

the world has the same chat window open

he should receive this specific message

how will he receive it you might say

hirat we can just pull every 1 second

send an HTP request give me the top 50

messages get back the response so after

1 second we will ask for the new list

and the new message will come here I

would say that is true this is what is

called long polling basically means you

send an empty HTTP request k bro any

changes that you have anytime you get a

change you push it back to me so you can

use long polling for this you can also

use another standard that was introduced

called server side events which pretty

much as the name suggests let's you do

what we want which is let the server

side events lets the server push events

onto the client though this these might

feel like Optimal approaches I I'm sure

you understand why they're not okay by

if I'm pulling every 1 second I'm

getting back 50 messages every 1 second

second and what if there was no change

made if there was no change made we

don't really want um to keep asking the

server every 1 second H give me all the

same messages again and again there is a

problem here for this websocket as a

protocol was introduced how is websocket

different from sttp if this is your HTTP

server you send it a request it sends

back a response it is a request response

model and if you actually go through

computer networks a little bit and

understand how this protocol Works under

the hood you will see see there is a

handshake that happens if you might have

read this in computer networks if you go

one level Below in the OSI model how

does http work under the H it works on

the transport layer it's create creates

a TCP connection and after the request

is complete it closes the TCP connection

there is no persistent connection

between you and the server compared to

if you have a websocket server the whole

goal is if this is your browser and this

is your websocket server there is a

persistent connection between the two

which means the browser at any time can

send you request the server can also

send you something not a request but

like some data whatever the server wants

to push down that is the difference

between a websocket server and an HTTP

server they are both different protocols

SL standards there's some sort of

interview question here somewhere is

websocket HTTP and the answer to this is

okay it is not HTTP but the first

request that you send out when you want

to create a websocket connection if this

is your browser if you want to create a

websocket connection from your browser

to any open server

the first request that goes out from

your browser is actually an HTTP request

only and under the hood then it gets

what's called

upgraded to a websocket connection and

then you have a persistent connection to

the back end but this is like a lot of

theoretical jargon so let's see this in

action and understand what are the use

cases and how and where websites are

creating these websocket connections

HTTP is great but does not cover a few

use cases the most important use case it

doesn't cover is the server sending

events or server side events what if you

want to build a realtime system what is

a realtime system the binance usdt if

you go to Zera if you go to binance if I

go to

this specific page this is like the

current price of uh binance the current

chart which sort of keeps updating as

you can see this number is updating very

quickly this list is updating very

quickly this number which is the current

price is updating very quickly what do

you think is happening do you think

binance every second is sending out HTTP

requests the answer is no it has has

created a single websocket connection to

a binance server and the binance server

is pushing down events yellow this thing

has changed yellow the price has changed

yellow the chart has changed so all

those events binance is pushing down to

the client how can we confirm how did we

confirm that an HTTP request is made we

used to refresh this and we used to seea

an HTTP request goes out the response

comes back similarly you can also track

um websocket events between a client and

a server oh sorry the websocket

connection so so you will usually see

this one okay if you the webside

connection is made between the browser

and WSS which stands for websocket

secure col binance do sorry stream.

binance.com Stream So This is the end

point where they've hosted their

websocket server and when I send the

request I don't just get a single

response if I click on messages you will

see I am getting a lot of messages in

real time H by the depth has changed

what is the depth this thing right here

yeah you know the price has changed the

chart has changed all these are coming

back as messages from the binance server

to me which is how this page is being

updated there's a single web socket

connection there aren't a thousand HTTP

requests that are going out every second

to update this page this is very common

in realtime systems what is a realtime

system where after you've opened a

website you're getting a bunch of

changes from the back end a chat

application is a basic example of it if

you have seen multiplayer games whatever

multiplayer Flappy word or if you play

Minecraft with your friend or even if

that famous fortnite game that people

play all of them require the server to

give you back the location of other

opponents who hit a gun you know you get

that gun going right next to your ear or

whatever so all of these things come

back as events from the server it is

never you keep asking the server bro

what is the current state what is the

current state they're all pushed down by

the backend server how sometimes through

websockets there are other ways to do it

web RTC is also like a decent use case

here okay you can actually create a web

TC connection and web TC also lets you

do data there's a significant difference

like there slight differences between

websockets and uh you know web RTC is

like an interview question when should

you use web sockets when should you use

web RTC under the hood they are both

trying to achieve the same thing if from

your browser you create a connection to

a websocket server it can send you back

let's say we considering fortnite here

so it will send you back the an array of

let's say oh this person moved here this

this person moved here this person

pressed a gun

Flaka you can do the same thing with uh

a web RTC server but like the high level

difference the biggest difference is

webc uses UDP and websocket uses TCP

which means here you will definitely get

back all the events here some events

might get missed so depending on the use

case for example in games a lot of times

you don't worry you need you don't need

every movement update of the end user

you need some movement updates even if

one movement update gets missed it's

fine so whenever you're getting back at

like 30

FPS and you don't really care if one

gets missed it's fine you use web RTC if

it is something like chat huh by if a

chat event gets missed that really

that's really bad I I should see every

chat message that everyone else is

sending me then you use websockets or

tcps this is a basically an interview

question that me or may not get asked

when should you use websockets versus

web RTC this is the answer you need all

the data definitely web sockets if not

web

RTC HTTP is not enough for something

like this or even something like this

what is this this is chat in WhatsApp

chat in telegram or even chat in

backpack backpack has a chatting section

if some of you might have opened it it

may or may not work for you because

you're not we're not running all the

services locally at the moment but if

you go into backpack the fourth tab here

is like a

chat this chat requires it to be

scalable real time and the goal through

today and tomorrow is going to be how

this chat is built and how you can

understand the whole thing and start

make changes inside it and the way this

was built was like super scalable so

we'll try to understand how it is super

scalable and what are the systems we

need to understand to able to make like

a production worthy realtime system not

necessarily chat you can extend this to

other use cases as well HTTP is not

enough when you need to uh need

real-time updates from the back end you

could either use server side events just

that there's a technology that was

introduced before websockets which tried

to solve this problem but like didn't

really catch enough heat then there is

long pulling can you still use HTTP but

every 1 second you send a request k bro

anything you have and if the server

doesn't have anything the request sort

of stays hung if the server does get

anything it returns back some data with

it that's called long polling it's like

a very ugly way to do this and then

finally websockets which is like

persistent connection between client and

server unlike HTTP who's like a

transient connection send request get

back response connection closes that's

HTTP what is web socket persistent

connection always open until you

explicitly close it an though all the

data keeps rolling in that's what

websockets let you do and what is the

ideal solution here to build a real time

system it is

websockets question is what are

websockets websocket is like the

official um definition websocket is a

communication protocol that provides a

full duplex communic that provides full

duplex communication channels over a

single long lived connection hopefully

that is

self-explanatory what does full duplex

mean it means client can send events

server can send events they can do their

like send whatever they want over a

single long lived connection so you

don't have to create multiple

connections you don't have they're not

shortlived like an HTTP request they're

completely open until you close the tab

or you know you you your Wi-Fi shuts

down or you explicitly have to close it

you move away from the trading page

let's say then you don't need the

websocket connection anymore but while

you're on that trading page while you're

on that chat system you do need a

persistent connection so the server can

keep telling you how data is sort of

being transmitted the good question to

ask at this point is I understand this

part okay this is the web connection how

what happens on the server how does the

server know huh there is an event I need

to push to herat or you know uh that a

game movement has happened how do you is

there a single server single websocket

server and then okay let's say there is

a fortnite like game so is there if this

is person one's browser this is person

2's browser is there a single websocket

server where this guy has connection

this guy has a connection this pushes a

data here and this pushes it down to the

other person and vice versa is this how

chat is happening are there multiple

backend servers if there are multiple

backend servers do they need to

communicate with each other what if

there is a fortnite game that three

people are playing P1 P2 P3 first person

sends his data here and has a persistent

connection to this one second person has

a persistent connection to the second

websocket server third person let's say

has persistent con to the third

websocket server if I send my data here

how will it reach P3 does websocket

server one need to send it to websocket

server 3 which will then forward it to

P3 or is there another architecture that

is used here to make this a distrib

system it is much easier to do if you

just assume H there is a single

websocket server all people are

connected to the same websocket server

to data goes here this guy does a for

Loop it already has the connections to

everyone else sends data to all five

this is easy what is hard this single

webset server can't really support more

than you know X number of users so how

do you distribute it how do you create a

SW of websocket servers that different

users can connect to different websocket

servers yet they can receive events

that's where redis comes in into the

picture and that's the second part of

what we'll discuss to most probably this

the red disc part we will discuss

tomorrow today we'll just try to

understand how you can create a

websocket server create a simple chat

application using it what is the concept

of rooms that sort of you need to be

able to understand who you have to

forward this message to and we'll also

if we get time uh try to do an

assignment from last week that I gave

but I don't think a lot of you have done

it cool web sockets and node is

websockets a a noj specific concept no

it's a protocol HTTP servers can be

written in goang can be written in Rust

websocket servers can be written in

goang goang nodejs Rust whatever

language you want we are going to write

them in note

J there are a bunch of HTTP servers out

there Express isn't the only one there

is one called Kaa slca there's another

one that weate used when we were

creating the open API spec file I think

that was using Express under the hood

but you get the idea there are bunch of

HTTP servers in nodejs similarly there

are a bunch of npm libraries that let

you create websocket servers it really

depends on which one you want to use and

a popular one some of you might have

heard of might be

socket.io now socket. iio is not exactly

websockets it is some abstraction on top

of websockets it is mostly good in most

cases it gives you a lot of things out

of the box spefically like this concept

of room creation y if you know you have

multiple people P1 who's in game Lobby

L1 P2 who in game Lobby L2 and P3 who's

in game Lobby L1 as well if you use

socket.io this specific um npm Library

it lets you create rooms very easily

what is a room this one and this one are

in room L1 this person is in room L2

that way anytime an event comes to room

L1 this guy can in a single sort of line

of code forward it to everyone who's in

L1 which is like this guy and this guy

and then there's another person who's L1

send it to this guy so soet I abstracts

a lot of this for you it is a good

library to usually start with but it

isn't used in production for multiple

reasons because if you use a socket.io

web backend server your client also

needs to talk socket.io and socket.io is

not the exactly the websocket protocol

it's very close you can actually somehow

tweak the server so that you can create

a a normal websocket connection to a

socket.io server but your

Android your iOS these

or let's say you have to write like a

goang application that connects to your

websocket server they don't really

understand socket.io they only

understand websocket they only have

clients that are in websocket socket.

dio became very popular so someone wrote

a C++ socket.io client you know and

Android socket. client but usually it's

not widely used websocket the protocol

is very widely used so if given a choice

if an interviewer asks would you use

socket.io for this raw websockets the

answer is raw websockets why because

it's a uh protocol that's you know Pro

proven and and out there and everyone

has clients for someone has written

websocket client implementation on

Androids someone has written websocket

client implementation in iOS so on and

so forth okay we are going to use one of

these libraries to create it today uh

are present natively on the front end so

just like fetch is natively present on

the front end your browser understands

Fetch and uses it to send out uh HTTP

requests your browser also understands

websocket and you know it's a browser

API that's available to you to create a

connection to the websocket server fetch

is used to send a request to an HTTP

server this is used to create a this is

the client side code for it this is in

the server side code server side code is

different similar to express client side

code or this websocket object is similar

to this

fetch let's look at the code now um the

code for this week as I said is at 100x

devs SL

uh week

19 BP repo oh no sorry my bad week 19 WS

so please please try to clone this

locally I'll give you guys 2 minutes and

try to open it in vs code I have it open

on webstorm um I'm going to keep it open

on webst if you guys don't mind because

Visual Studio code has backpack right

now and I want to remove backpack from

it so it's very simple code so hopefully

the editor does not anow you guys so two

more minutes please open it in vs code

and I'm going to wait for 2

minutes

open chat if anyone has any questions

but would urge you to start to clone the

project

locally are there no servers that can do

peer-to-peer connections like web RTC

for messages are there no servers what

do you mean by servers do you mean any

protocols so generally peerto peer is

never done like if if you thinking of

doing peerto peer beat using web RTC or

any other protocol it will not scale for

a thousand Reasons so no one does peer

to-peer even web RTC is sort of tweaked

to go through a server eventually in

scalable systems like Zoom difference

between websockets and web hooks doesn't

web hooks also keep sending messages so

they're like very different things web

Hook is

a websocket your

server your client you sort of own this

code you have a connection to your um

web socket server web

hooks um when you use an external

service for example some of you might

have heard of Razor pay which lets you

do um payments to Razer pay usually HTTP

server Razer pay HTTP server will send a

request to your HTTP

server and this is called a web hook why

is it used if a payment of yours fails

so razor pay is the person who has

connect connection with banks you know

SBI HDFC so on and so forth when people

come to my website for example to buy a

course they actually hit razor pays Endo

okay H bro uh whatever I'm paying 1,000

rupees which under the hood sort of hits

a bank API eventually the bank needs to

tell Razer pay ha this transaction is

done and then Razer pay needs to tell my

backend server H whatever Su paid X

rupees so this Razer pay server talking

to my HTTP server when you talk across

companies that's what's called a web

hook okay you go to razor pay dashboard

and say bro hit this web backend server

request uh endpoint of mine which is

called a web hook you are sending a hook

to my back end so I can in my database

put K some has bought the course and

someone gets access to this course so

whenever SBI needs to talk to Razer pay

razor pay needs to talk to me they hit

my web hook that protocol that they

using is still HTTP

so this is still an HTTP server request

only it's happening from one company

compy to another that's what is a web

hook what is a web socket it is a real

time like a different protocol

completely different from um HTTP cool

that's the high level difference

hopefully you guys have cloned it there

are five parts let's look at it the

first and two sort of go together it's

the backend code for a websocket server

and the front end code for a websocket

server if you go to package.json you

will see I have Express you don't really

need Express to create websocket servers

you can create it without it but I have

used Express there's like a way to

create uh web soet servers using Express

that way you can expose one endpoint for

example SL WS endpoint on uh to be a

websocket server and then whatever you

can have a/ health endpoint slash user

slash whatever uh create as another

endpoint that only one endpoint is um

web so endpoint and others are standard

HTP and points you can also not use

express if you want to create a pure

websocket server and then there are the

types of both Express and

WS standard TS config um only difference

is um the root D is/ SRC and the out D

is/ everything else is like standard

that you get and if you look at

index.ts let's look at the things that

I've imported I've done import Express

from Express import HTTP from HTTP now

this is this is like the native HTTP

module that node provides you um I don't

think we need this either but the way

I've created this code is that

um after you do a const app equal to

express and have the port we do a server

equal to app. create server app I don't

think you really need this uh I guess we

need

it yeah so I think the reason for this

is web socket server expects a native

HTTP server here

that if I go here look at the

options uh let's

see

yeah there you go the server argument

that it expects is a native HTTP server

so we can't just say yellow Express this

doesn't accept Express here which is why

I had to create a native HTTP server

what my native HTTP server this is just

the module that node just provides you I

think H inside the box like out of the

box as you can see this HTTP module

isn't really part of my package.json

so this like node just provides you out

of the box we use this to create an HTTP

server by using simply http create

server I think you you don't really need

Express I think you can create it

without Express as well and you know

there's a different way to create routes

here like http.get or whatever so you

can do that as well I don't think you

need as I said you don't really need

Express I have created it this way

because this is how backpack has done it

I'm just basically copy paste it it and

try to break it down if you want to

build it yourself you actually don't

need a lot of these things you can

simply this is enough to create I think

a websocket

server lastly I've said WSS doon

connection oh uh I said initialized

websocket server this has all the logic

similar to all I have to do if I have to

create an HTTP server is const app equal

to express or basically this line right

here this under the hood creates an HTTP

server has all the logic for it

similarly this Whoever has written this

library has written all the logic to

upgrade the request create the

persistent connection so on and so forth

we use this Library out of the box the

only sort of syntax you need to know is

websocket server so WSS stands for the

websocket server Doon connection anytime

a person connects to you the control

reaches here someone connected that's

what I've logged here and then ws. on

message anytime someone sends you a

message you can whatever put a log here

put something in the database do

whatever you want with this information

for example in the real world someone

would send you either a chat message or

someone would send you their movement if

they're playing uh Minecraft okay this

is where I moved you receive that data

here from here you have to run your l

you can do whatever you want with this

data we don't do anything we just send

back from the server okay hello you sent

this so just to show duplex

communication just to show client can

send you some data server can respond

back with some data this is like five

lines of code that you have to write

this is enough to write your server side

logic is this what you will write in the

real world no in the real world if you

user send you a message you will have to

basically look at who all are you

connected to forward the message to a

few of those users so you won't ws. send

you will actually do a you know for

iterate over all the users you have all

the web soet connections you have and

send it to them we will see that when we

reach this part for now fairly simple

websocket server on connection which

means anytime someone has created a

websocket connection control will reach

here what do we do here we log we don't

have to log we can remove this but we

just log to see H actually connections

are being made and anytime that user now

sends message that user can send you

message once twice 10 times 100 times

the control will reach here and then I

don't don't have to do anything here but

what am I doing I'm just responding back

bro yellow I am going to respond back

with hello you sent this I could also

some be something like okay set

interval ws. send hello from

server every 1 second I could I don't

really need a trigger I can simply be

like every 1 second now I'm going to

send you some data okay so ws. send can

be called anywhere now as long as you

have access to this WS which is the

socket connection for that specific

user once the control reaches here this

WS variable is the socket connection to

that user if another user sends a

request a new control will reach here

again a new WS variable will be

available from which you can send back

data I think fairly straightforward

stuff here let me know if not we'll do a

poll

soon but hopefully this backend server

logic is straightforward if not we'll do

a poll let me know going try to marinate

it ignore whatever you're seeing here

this is just my

ID being my ID so it's actually just

async WS comma Rec these are just types

that my IDE shows similar to this

listener that's a type that my IDE shows

don't worry about that if that's what's

confusing you and let's try to run this

back in server now the way to do that as

always is oh by the end in the end we do

server. listen Port which is similar to

how we used to do it in like an express

application we used to do an app. listen

rather than doing an app. listen the

server that we we have created we do a

server. listen Port why is this schol

did we use express so that we can do

like other things like app.get SL Health

expose

like a health check in point so on and

so

forth cool you don't have to add it just

showing you eventually if you hit this

end point when your server starts you

can also get back like health checks and

put other logic here the way to run it

go into 1-s simple- ws- server and run

TSC

sp-b this will what will it do convert

your typescript code into JavaScript

code if this doesn't work for you npx

tscp should work once you've done it

node dis

index.js should start this on Port 3000

I was already running something here but

if I remove that node dis index.js

should start your websocket server we

haven't yet written any client side

logic we will write that very soon but

this is a similar to an HTTP server that

has started

trade

forward shall we proceed let me do a

poll real

quick I think it's

straightforward hopefully because it's

like very similar to http servers so

like nothing too fancy here just one

more extra thing you get you send and

receive separately okay very good so

now this is in the past when we created

HTTP servers we were able to hit them

via Postman a mobile app or uh a browser

anywhere right similarly websockets also

you can hit from anywhere you want if I

go to my browser and search for

postwoman this was someone who created

like aun funny project called postwoman

which was a open source version of

Postman uh and this has like a realtime

part I think Postman also has this like

now Postman also lets you create a

websocket connection but think of this

application which is hops scotch.io now

used to be called postwoman in back in

the day it let gives you a section

called real time which lets you create a

websocket connection similar to how we

used to go to postman and send HTTP

requests this is just another client and

if I click on if I put if you put the

right address here which is ws/ loal

3000 if I open inspect click on the

network

Tab and click on connect here you will

see a websocket connection has been

created there are no messages that have

been exchanged right now but the

connection has been made if I send a

message here let's

say the way to do that is it sort of

lets you put any random body here and

send you will see I send a I sent a

message I also received the message

hello you sent this from the backend

server I can also confirm this here so

what is this this is just another client

uh for hitting a websocket server

eventually you want to own this

application this will be your own chat

application your own game but at least

this shows you how can you now it's a

generic websocket server that You' have

created anyone can talk to it using

websocket clients we specifically need

to talk to it using a website so either

a react application next CH application

so we will write a simple client in

JavaScript that's able to talk to it but

like anyone can talk to it it's an open

server that understands the web soet

protocol as long as someone has written

a websocket client they can talk to it

they can send messages they can receive

messages what we haven't yet written any

logic here in the real world you'll be

like message types if message. type

equal to

chat then only you forward chat messages

if it is a message the server does not

understand it does nothing we have to do

all of that right now but just the

communication bit has been hooked up now

let's look at the client that I have

written this is a simple index

[Music]

or