Why WebSockets Are NOT Scalable | WebSockets Explained

again i'm referring to tens of thousands of concurrent connections together right you know a simple node.js program again this depends on your requirements but a simple node.js program can easily handle like if i had to give a rough estimate 500 to 10k maybe depends on your workload if your websocket connections are idle or not and so on hey everyone welcome back and in this video we'll be taking a look at why websockets are fundamentally unscalable why do people keep on saying that hey websites are not scalable http is more scalable why that is the case let's understand in depth and how you can make websockets scalable with general market solutions let's go if you're new here make sure you leave a like subscribe to the channel and hit the bell icon this is free of cost and helps the channel grow this video is a part of code dam's t-shirt giveaway program for the month if you want to take part and win an amazing go damn t-shirt all you have to do is leave a comment on this video about what you think and that's it you are eligible if your comment gets a heart from code damn you will win a t-shirt for absolutely free now before actually getting into web sockets let's actually get into scale what the scale actually means so there are two kinds of scaling you will see on you know infrastructures the first one is horizontal scaling and the second one is a vertical scaling now vertical scaling is a type of scaling where you keep on adding hardware that means you keep on increasing your ram and your cpu mainly because these are the only two bottlenecks which you will see on server and cpu in some cases more ram in some other cases but in vertical scaling what you do is you're probably running a very strong single ec2 machine or whatever machine and you just keep on pushing its hardware up and up and there is a physical limit on how much you can push hardware right beyond a certain point it has diminishing returns so this is not an optimal solution for web scale services for example you cannot probably run amazon on a single server right or google on a single server or any website which pretty much receives hundreds of thousands of hit per second on a single server right so it's not a viable so then comes the horizontal scaling part this is the interesting part which allows you to distribute compute over a cluster of computers right so you cannot keep on adding hardware but you can keep on adding new computers right until the world runs out of silicon but that's another problem but this means that a collection of computers small computers together can pretty much compete against one very big machine and the good part here is is that you can also multiply these clusters you know by a thousand factor so you pretty much have a lot of small computers which in themselves alone are not so powerful but when combined and when used together they make a lot of scalable systems right so these are the two kinds of scalability aspects the vertical and the horizontal now when we say that web sockets are not scalable we mean web sockets are not horizontally scalable right obviously they are vertically scalable if you have a huge machine you can pretty much add hardware to it you know and your websockets you will have more capacity to hold network connections and cpu and ram and so on but what we want is horizontal scalability why because you know you can pretty much distribute a lot of compute over the whole cluster of nodes and this is helpful because now this can receive any number of traffic technically all right the second step in understanding why web sockets are not scalable is actually take a look at how http works so http fundamentally you have a client then you have a server which connects for a brief time sends a response and that's it you're done the communication is over right if you want to do another request your client sends another request the server responds to another computer um you know your another client request and that's it the connection ends the important point here is that this server and this server are not the same i mean they could be but they don't have to be why because your client the information which your client sends you know whatever the cookie or auth token or whatever it's a complete state in itself that means the protocol in itself can be stateless right this protocol the underlying mechanism which carries this information is stateless because your server automatically can pass the state from the client it doesn't need to be that same server again you know because this could be a completely different server now how does this benefit us take a look at the horizontal scaling let's say i have these six nodes running as each of one of them as powerful as this one and the first connection is taken by this the second is this and it's fine i mean it works right on vertical scaling it might be a problem but on a horizontal scaling you could pretty much assign a lot of these computers to different clients all together right you are combining the compute power and all you had to do was replicate your back end code on each of them right which can be done with a click right it's not a manual process super easy now let's take a look at how a web socket connection works so unlike http when you establish a websocket connection with a server this connection actually stays alive all the time this is a tcp connection this is technically an http connection upgraded to a web socket connection but this connection right here this pipe right here stays connected right this means for example if you want to take an analogy analogy you can have a client which connects a pipe for a split second to a server and then disconnects it and maybe connects it again right then you know disconnects it and then connects it again this is the example of http right therefore http gives you enough time to swap the server with some other server right or maybe add more servers to the punch if there are a lot of requests coming in websockets on the other hand if you're stuck with a server that server is stuck this pipe is not going down if you removed this pipe then the websocket connection would disconnect and websocket is a state full connection that means once established the client has to remember and the server also has to remember now obviously for client it is not a problem because because at a given time you know the user will not be having a lot of websockets connection open but for server a central server which has a lot of clients to serve this is a huge problem right and you can see all of these clients which you see right here they would be connected to a single server or even if you have multiple server that also does not fix a lot of problems even if you have multiple servers you cannot upscale and down scale on demand right you could upscale but you cannot downscale why because you can see that you're stuck with some connections here right so you cannot just remove this instance because that will remove all these connections as well you could do that here because you know you can set this instance in a training mode or something and once all http requests are done you can remove it you can do that here as well but it's a lot slower because a websocket request might take an hour to complete 30 minutes to complete 10 minutes to complete i don't know how much time a client stays active but http requesters are generally in seconds right you click a button something happens the data transfer happens and that gives you this flexibility of swapping the servers up scaling down scaling and so on which you don't get in websocket connections all right so how do you make websockets connections scalable then well you don't as a developer you don't have to worry about going into the infrastructure details and managing the hardware i mean there is no other way than having powerful systems having a lot of powerful systems and let them take the websocket connection and manage them right so that will be there but in order to scale it what you can do is you can separate the logic and the connection establishing area what do i mean by that on amazon for example we'll take a look at amazon because that's what i know on amazon you have a service known as api gateway now this api gateway you can think of as a load balancer which is huge and managed by amazon so you don't have to worry about this guy falling off but what this does is that it can pretty much take in a lot of connections more than you can imagine right a lot of web socket connections and all of these websocket connections are connected here you know so the browser which is seeing it is actually seeing a connected socket connection but on the back end in reality what's happening is that you have multiple serverless functions called lambdas and amazon calls a lambda function on demand right and this lambda can call you know a special function on api gateway to send a message so it calls it calls this function whenever you know this websocket sends a message if it sends m it's called m then it can respond at the same time or maybe sometime later it can you know push into an sqs which calls another lambda which pretty much does the job right so what's the what's the idea why why does the system make it scalable so it makes the system scalable because we have pretty much offloaded the hardest problem to amazon which is how you can just maintain a websocket connection now the client right here sees a pipe established to api gateway but this this communication which is happening at the logic layer is just http so these are http calls made to land us right and we know that http is scalable so amazon just implements its own scalability of http here and with lambdas it's easy so api gateway is again this because it is huge it comes with certain limits for example it cannot be idle for 10 minutes that means your websocket has to send some message at least once every 10 minutes i think that's the lowest payload i mean the highest amount of time you can set and the second constraint which i remember is the websocket connection can only stay alive at max for 10 hours i think four hours not 10 hours correct me if i'm wrong in the comments for four hours you can keep this socket alive this is a heart limit that means after this amazon would forcefully drop this connection right which is fair i mean because they also want to replace the hardware right because this pipe is connected to some server and let's say you know you just keep this connected for 10 days right i mean that's that's bad for amazon because they have to keep a server alive maybe it's just your connection and this has a degrading performance or something or whatever but these servers which amazon owns they have obviously certain limitations compared to a just a full-blown websocket server but this is highly scalable right so you trade in a few things which is a true websocket nature in your code for http based calls but you get a lot of scalability and my scalability again i'm referring to tens of thousands of concurrent connections together right you know a simple node.js program again this depends on your requirements but a simple node.js program can easily handle like if i had to give a rough estimate 500 to 10k maybe depends on your workload if your websocket connections are idle or not and so on but yeah i mean if you're developing a very small application which would not be used by more than a few hundred people then you don't have to worry about the scalability aspect while implementing but it's always nice to know how to do that when you are there right and all of these are managed services api gateway lambdas and you will find equivalence for them in other cloud services as well for google cloud and seo and stuff like that but this is how it works at least in amazon and again some companies actually do this layer of work by themselves as well because of the api gateway limitations but yeah i mean this is this is probably out of scope of this video because i don't know how to set up an api gateway like infrastructure right you would only need to ask amazon or some high heavy high traffic cloud provider on how to implement this but yeah for us for developers that's what we use at least for now so that is all for this video hopefully you got some new insight on websockets and how to make them scalable if you liked it make sure you leave a like and subscribe to the channel thank you so much for watching and i'm gonna see you in the next one really soon you

Channel: codedamn

Views: 5,076

Keywords: web development, codedamn, mehul mohan, full stack development, full stack web development, What are WebSockets, Why WebSockets Are NOT Scalable, WebSockets Explained, http vs websockets, websockets vs http, what are websockets, websocket server, websocket framework, web socket example, websocket example, how is websocket different from http, secure websockets, How is it different from HTTP, webdev, app development, lesson, websockets, webrtc, websockets tutorial, javascript

Id: xtCddOjITvo

Length: 12min 7sec (727 seconds)

Published: Sun Sep 26 2021