Using WebSocket with React and Redux part 1

Vladislav Stepanov
codeburst
Published in
4 min readNov 14, 2018

--

Nice picture that has nothing to do with WebSockets

This is the first part of a trilogy about using WebSocket with React and Redux. In this very first part, we are about to look at four different technologies that can be used to deliver server-side events in real time, and discuss which one is better (SPOILER - WebSocket) and why.

In addition, if for some reason you are still writing your code using jQuery or perhaps using other libraries/frameworks, you still can read this part, because we will not talk about implementation in React yet.

So, let’s begin!

(sorry, I don’t have nice hand-made images or whatsoever, so in this article you will see random images from pixabay in random places, I hope this will make reading more interesting)

Technologies

Here are our four main technologies:

  1. Short-polling
  2. Long-polling
  3. Server-Sent Events
  4. WebSocket

The list created in order form worst to best. Let’s look at each of them in detail.

The bacteria thinks it’s time to buy a new home

Short-polling

This is the worst. This is probably all you need to know. If for some strange reason you still wanted to know more read, the following paragraph.

Short here stands for short periods of time. Every few seconds (or minutes, it varies) the client (in our situation it’s a browser) sends a request to the server to check if there is new data available.

The good side is that every(or almost every) browser supports it, even (please don’t let the kids see it) IE6.

The bad side here is that the network will hate you, users will hate you, servers will hate you, my granny will hate you too.

Long-polling

This one a little bit better. At least, you will not be hated that much by different things and people.

This is still the same polling, so the client will make requests to the server, but, here is very important BUT, it will wait till the server response with new data.

The good side is the same as in the short-polling.

The bad side is that some intermediaries may close connections due to their inner timeouts. Also, it’s still a work of the client to ask the server, which is not actually that good.

Comparison of two types of polling: http://pragmaticnotes.com/2017/11/20/amazon-sqs-long-polling-versus-short-polling/

Intermission

By far we have considered methods for simulating real-time events. Now we are about to look at real server-events. And these are not just some techniques, but APIs that you can easily use in modern browsers.

If your kids are still hiding under the kitchen table, you can tell them that this is fine, IE6 is gone.

Looks like a vegetable

Server-Sent Events

Here we go, the first good thing. For thousands of years of evolution, we have been waiting for this, or maybe not, I don’t know. But this wonderful technology gives us real-life server-sent events.

This technology sends server-side events through a long-living HTTP connection. Also, it is a browser API!

The good side is that it server-side events.

The bad side is that it is only a one-domain connection. In addition, it relays on the same HTTP connection (actually it’s not so bad).

Good article to read: https://www.html5rocks.com/en/tutorials/eventsource/basics/

WebSocket

Ta-dam! WebSocket, you may have heard a lot about this.

This is a full communicational protocol over TCP connection. Plus it is a convenient browser API (similar to SSE’s one).

The good side is that it server-side events!

The bad side is that there is no bad side, so I have nothing to write about! But let’s leave this paragraph here, I’m sure that even the greatest technologies have their drawbacks. (Not supported in old browsers, firewalls may block WS)

Conclusion

This is a very biased article in an inappropriate tone, from the very beginning the reader already knew that WebSocket is better. But this is not always the case, sometimes you need to create something simple and support different clients, so WS is not the only option.

In the following articles, we will look at WS API and some of the tricks we can do.

Until next time and happy coding (or whatever you do)!

PS I don’t know why would anyone read this article to the end, but if you did it, here is the list of good articles about our topic:

SSE vs WebSockets: https://streamdata.io/blog/push-sse-vs-websockets/

Polling vs SSE vs WS: https://codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9

Chapter in a book, also with a comparison, but look at those examples!: https://qiuzhihui.gitbooks.io/r-book/content/system-design/short-polling-v-long-polling-vs-websocket.html

A chicken

--

--