In this blog post, we’ll learn how WebSockets are different from the usual way we talk to websites, which is called HTTP. We use HTTP for normal web stuff, but WebSockets are like a superpower for making websites do things in real-time. We’ll break down what makes them special, where you’d want to use each, and how they make websites more exciting.
Traditional Way HTTP
First and most importantly, it is a one-way communication. Let me explain. Suppose you want to get a webpage from a server so that you can load it. You have to send a GET request to the server, and the server will reply with either the webpage or an error if something goes wrong. After that, the request-response cycle ends, which means the connection is closed. Now, if you want to get new data from the server, you have to make a new request. Remember, you’re the one always starting the request, and the server simply responds and then ends the connection. This method is typically used to exchange web pages and data important to display web pages like Posts etc… .
Cons Of HTTP
The HTTP protocol was working well for its purpose, but it faced issues when real-time communication became important. Let’s take an example: Imagine I have a chat app, and when I open the app, I retrieve all the messages sent to me by my friend, Bob. Everything seems fine so far. However, here’s the problem, as we discussed earlier with HTTP. The client (that’s me) initiates the request, so how would I receive Bob’s new messages without constantly asking the server? More importantly, how would I know if Bob sent me a message? It’s possible that I’m getting new messages every few minutes, or sometimes, I might not get messages for hours. This is where we can use something called ‘Polling’ (I’ll explain it in an upcoming blog). But polling isn’t very efficient because you’re asking the server for updates at fixed intervals, and you don’t even know if there’s new data waiting for you. So, how can we solve this problem?
WebSockets To The Rescue
So, how do WebSockets solve the real-time communication issue? WebSockets provide a two-way street for communication. This means that, like the HTTP protocol, The client can start conversations. However, WebSockets have a superpower: the server can send data to the client without the client asking for it. What’s even more remarkable is that once data is sent successfully, the connection doesn’t close. It stays open until either the client or the server decides to disconnect.
Let’s revisit our previous example. Initially, I retrieved all the messages from the server, just like before. But now, when Bob sends me a message, I get it instantly in real time because the connection with the server doesn’t close (as we explained earlier). Moreover, if the server receives any message from Bob meant for me, it sends it to me without me having to request it. Pretty amazing, right?
So When To Choose What?
In summary, choosing between HTTP and WebSockets depends on the nature of your web application and its communication needs. If you’re building a traditional web application that mainly deals with fetching web pages and resources, HTTP remains a reliable choice. However, when real-time communication is a requirement, such as in chat applications, live updates, or online gaming, WebSockets shines.
Conclusion
I hope you will find this blog helpful. We’ll see you in the next blog with some new content. Until then, goodbye! If you have any queries, you can reach me on LinkedIn, and you can also follow my YouTube channel. I might not be consistent on YouTube, but you will still find helpful content.