An advantage for short polling is that the server can remain stateless. Both long polling and web sockets needs to keep a directory of which server contains the connection to the client, which is used to send data to the client whenever it's ready
I've used short polling with much success. The load on the server is a lot less than with long polling or WebSockets (or server sent events, which you didn't mention). You can have the client check for the mere existence of a particular file on the server, and take no action if it's not found. If you're using shared web hosting and have more than a few clients, short polling is your only practical option. Also, if your users are in a protected network (school, corporation) that wants to inspect packets coming through, you won't be able to establish a websockets (or server sent events) connection. So, short polling isn't a bad as it seems. I know, it sounds horrible sending out Ajax requests every 0.5 seconds, but in the real world, it works pretty good.
Hey Dennis, I totally agree with you that often short polling is the most practical solution (especially for web applications). I do think there is a performance benefit to be had though if one is willing to go through the extra effort. I think at scale is where short polling starts to fall apart. You may find that you're spending a lot of $$$ on resources that are serving empty poll requests.
@@BeABetterDev Where would the extra $$ come in? If someone simply checks for a file and doesn't download anything, how would that incur an extra charge from the web host?
@@workingTchr It depends on your hosting provider. Some providers will rent you a server or a hosting service where you pay a monthly/yearly bill, and that's it. You don't have to bother about bandwidth, storage etcetera. However, other providers will bill you on your usage, and that's the perfect case where saving bandwidth and storage will benefits your wallet. That's when you will start to spend extra money for serving nothing with short polling.
short polling can have benefits. ie if you want to check if a client is online and the client can ping the rest api every 5 mins to check if it is online. While it pings and gets a response, you can put other useful data in that response.
a queue system where you expect to not receive messages every second if the queue is empty you can wait a while and immediately act when data comes in, if there is data it will immediately grab it instead aws SQS allows long polling, but only up to intervals of 20 seconds for example
Let's say a chat application. There is a server and a client. Now, the client wants to know if there are any new messages. Here, we may use long polling. The server will send the client any new message when there are new messages.
In case of long polling, what happens in client side while they are waiting for the message or timeout? Do they still work on different task(Async)? Or do they wait until they get the response from the server(Sync)?
I think a nice complimentary video would involve web hooks or some sort of asynchronous callback. Thanks a lot. Also why is short polling bad? At most it makes one connection to the resource just like the other methods. Is it the overhead of setting up connection?
I think it has to do with the numerous Rest calls that would be made. I currently have a game setup using short polling and I essentially have it waiting 5 seconds and checking Dynamo DB for updates. I’m 100% this needs to be swapped for a Web socket.
@@SpotCallerzWrestling I hope you were able to get set up with web sockets :) I recommend socket.io, which is like three lines of code! Short polling sucks because every time you make a (presumably TCP-style) request, you have to set up all the request headers, which can get very expensive if you're doing it over and over again. To be fair, most browsers today will cache the request response so you don't have to do it over and over again, but web sockets are awesome because after one upgrade handshake, you have a binary data exchange on a single, fully-duplex, TCP connection, which is perfect for a game! Anyways, best wishes ☺️
He mentioned you are wasting (CPU)cycles in the video with short polling. What he means by that there needs to be a thread or process responsible of this requests. Creating the request, sending the request, waiting response and freeing up the resource and you will have a delayed update depending on the interval you have set. In other case you would have a thread that's just waiting for response from the connection and you would be updated almost instantly.
Hi there. It would have to be configured by both the client and server. The client needs to ensure its connection timeout is greater than the server. The server would need to be implemented such that for any request, it will keep the connection open until a message becomes available or the timeout is hit. Hope this helps.
I made one project controlling switches on frontend(react js) and backend server(node js) . multiple users can control switch and all other users should also get get updated status of switch .what should i use in this case polling or web socket or server side event . i used api to post and save data and other client get update the status every 5 seconds from server it works for some time and then i get error net::ERR_INSUFFICIENT_RESOURCES .hope you understand and give me a solution
Nice video. A couple of questions 1. Did you miss SSE (server sent events) which is another variant for server push mechanisms? 2. Is the connection type between client and resource the same for long polling and websockets? I guess websockets communication happens using a different protocol over HTTP. Thanks
Summary: In long polling, the server does not respond to client's request till the data is available and in short polling, the server responds the client regardless of the data availability. WebSockets provide a full two-way communication channel over a single, long-lived connection between a client and a server. Unlike traditional HTTP communication, which follows a request-response model, WebSockets allow both the server and the client to send messages independently at any time.
the only viable way to use a serverless function is it to be exposed to a API gateway w/ websockets. Lambdas are not dependable for waited request, as they will sometimes just die after x amount of time. If low-latency and reliability is key, then just host the websocket/api server yourself. Another issue with lambda is cold starts as well.
I was looking for the time/resource cost associated with setting up the connection. Only with that information, we can say how bad short polling could be.
An advantage for short polling is that the server can remain stateless.
Both long polling and web sockets needs to keep a directory of which server contains the connection to the client, which is used to send data to the client whenever it's ready
Finally someone with an accent I can understand!
Glad you enjoyed!
short and concise, I love this. It makes it clear on suitable implementation based on use cases.
Thanks for the kind words!
I liked the video as soon as you gave the example with Node.js backend. Props to you ;)
Great summary. My analogy for a web socket is a Telnet session.
Thanks Glenn! I was going to bring up telnet as an example but thought it would show my age ;)
@@BeABetterDev ha ha! I feel your pain !!!
great gracious explanation, kudos
Short and clear! Thanks man!
Glad it helped!
A perfect video for understanding concepts.
Thank you. Your presentation is clear and helpful 😄
You're very welcome Myrick!
I've used short polling with much success. The load on the server is a lot less than with long polling or WebSockets (or server sent events, which you didn't mention). You can have the client check for the mere existence of a particular file on the server, and take no action if it's not found. If you're using shared web hosting and have more than a few clients, short polling is your only practical option. Also, if your users are in a protected network (school, corporation) that wants to inspect packets coming through, you won't be able to establish a websockets (or server sent events) connection. So, short polling isn't a bad as it seems. I know, it sounds horrible sending out Ajax requests every 0.5 seconds, but in the real world, it works pretty good.
Hey Dennis, I totally agree with you that often short polling is the most practical solution (especially for web applications). I do think there is a performance benefit to be had though if one is willing to go through the extra effort.
I think at scale is where short polling starts to fall apart. You may find that you're spending a lot of $$$ on resources that are serving empty poll requests.
@@BeABetterDev Where would the extra $$ come in? If someone simply checks for a file and doesn't download anything, how would that incur an extra charge from the web host?
@@workingTchr It depends on your hosting provider. Some providers will rent you a server or a hosting service where you pay a monthly/yearly bill, and that's it. You don't have to bother about bandwidth, storage etcetera. However, other providers will bill you on your usage, and that's the perfect case where saving bandwidth and storage will benefits your wallet. That's when you will start to spend extra money for serving nothing with short polling.
Clear and precise explanation... Thank you!
You're very welcome!
great explanation, your videos are very helpful. Thank you Sir.
You're very welcome Mehmet!
great explanation keep up the good work!!
short polling can have benefits. ie if you want to check if a client is online and the client can ping the rest api every 5 mins to check if it is online. While it pings and gets a response, you can put other useful data in that response.
Good callout!
Right on the point! Thank you for sharing :)
You're so welcome!
Good knowledge under 5 minutes👍
Great job; thanks for the video.
You're very welcome Kevin! Thanks for the kind words.
Webhooks is another possible model that may be good, depending on your requirements.
This was great, thank you. Came here to figure out why OpenAI is using short polling with the assistants api lol
Is a webhook called long polling? Great explanation.
What's a perfect use case for long polling?
Any use case?
Thanks
a queue system where you expect to not receive messages every second
if the queue is empty you can wait a while and immediately act when data comes in, if there is data it will immediately grab it instead
aws SQS allows long polling, but only up to intervals of 20 seconds for example
Let's say a chat application. There is a server and a client. Now, the client wants to know if there are any new messages. Here, we may use long polling. The server will send the client any new message when there are new messages.
Great video thank you
In case of long polling, what happens in client side while they are waiting for the message or timeout? Do they still work on different task(Async)? Or do they wait until they get the response from the server(Sync)?
That's completely dependent upon the language/library you're using to initiate the request. I would definitely try to take the async approach though.
I think a nice complimentary video would involve web hooks or some sort of asynchronous callback. Thanks a lot. Also why is short polling bad? At most it makes one connection to the resource just like the other methods. Is it the overhead of setting up connection?
I think it has to do with the numerous Rest calls that would be made. I currently have a game setup using short polling and I essentially have it waiting 5 seconds and checking Dynamo DB for updates. I’m 100% this needs to be swapped for a Web socket.
@@SpotCallerzWrestling I hope you were able to get set up with web sockets :) I recommend socket.io, which is like three lines of code! Short polling sucks because every time you make a (presumably TCP-style) request, you have to set up all the request headers, which can get very expensive if you're doing it over and over again. To be fair, most browsers today will cache the request response so you don't have to do it over and over again, but web sockets are awesome because after one upgrade handshake, you have a binary data exchange on a single, fully-duplex, TCP connection, which is perfect for a game! Anyways, best wishes ☺️
He mentioned you are wasting (CPU)cycles in the video with short polling. What he means by that there needs to be a thread or process responsible of this requests. Creating the request, sending the request, waiting response and freeing up the resource and you will have a delayed update depending on the interval you have set. In other case you would have a thread that's just waiting for response from the connection and you would be updated almost instantly.
Thank you
You're welcome!
Thank you.
Kafka short pooling right?
Wouldn't short polling be the best choice for every normal CRUD application?
Short polling should be good for things like weather updates and stock market ticker data or score boards
if you want to create huge bills at the end of every month, sure.
Thanks
Thanks for sharing .. Does the timeout has to be handled by client app or server ?
Hi there. It would have to be configured by both the client and server. The client needs to ensure its connection timeout is greater than the server. The server would need to be implemented such that for any request, it will keep the connection open until a message becomes available or the timeout is hit.
Hope this helps.
I made one project controlling switches on frontend(react js) and backend server(node js) . multiple users can control switch and all other users should also get get updated status of switch .what should i use in this case polling or web socket or server side event . i used api to post and save data and other client get update the status every 5 seconds from server it works for some time and then i get error net::ERR_INSUFFICIENT_RESOURCES .hope you understand and give me a solution
Nice video. A couple of questions
1. Did you miss SSE (server sent events) which is another variant for server push mechanisms?
2. Is the connection type between client and resource the same for long polling and websockets? I guess websockets communication happens using a different protocol over HTTP.
Thanks
SSE is not server push it’s just push. Server push comes with http2 which no one is able to use so far
Websockets establish a TCP connection at start same as long polling and both uses http for further data transmissions
@@snghnishant hey man where can I watch more detailed video about this?
@@Giorgi-ho8rj check Hussein Nassar channel
Summary:
In long polling, the server does not respond to client's request till the data is available and in short polling, the server responds the client regardless of the data availability.
WebSockets provide a full two-way communication channel over a single, long-lived connection between a client and a server. Unlike traditional HTTP communication, which follows a request-response model, WebSockets allow both the server and the client to send messages independently at any time.
Web sockets: but how can the server(resource) positively know if the client is still connected?
Ping requests
when a client disconnects, it sends a signal to the server from which server knows that the client has disconnected
How does this tie to Lambda/serverless workflows?
the only viable way to use a serverless function is it to be exposed to a API gateway w/ websockets. Lambdas are not dependable for waited request, as they will sometimes just die after x amount of time. If low-latency and reliability is key, then just host the websocket/api server yourself. Another issue with lambda is cold starts as well.
AWS API Gateway now supports the creation of WebSocket APIs: aws.amazon.com/blogs/compute/announcing-websocket-apis-in-amazon-api-gateway/
I was looking for the time/resource cost associated with setting up the connection. Only with that information, we can say how bad short polling could be.
Any implementation in github?
Pretty sure short polling is not *necessarily* a bad choice if you have a system where the data is guaranteed to change - e.g stock prices.
yes. but I think much better choice would be websocket. unlike short polling, the client doesn't need to open a connection for every request.
Is long polling an example of streams i.e. reactive programming?
nope but polling can create streams of data for server to listen to or react to
nice.
Short polling is very useful when dealing with separate systems and one system is waiting for another to -- say -- boot up, or complete some flow.
Cool
From architecture point of view, all of them are wrong. Messaging or streaming is the correct way how to do this.
You failed to explain the difference between long polling and web sockets.
rezorce
wrrr
long polling is TOO short