Polling/Long Polling navbar notifications

Chris I have been using your implementation of navbar notifications and I really like the way it's constructed.
I can implement Facebook style notifications and I am pretty happy about it.
However I have a couple of questions for you:

1 - I was reading about polling and long polling techniques for example this article
http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery.
And as far as I can understand you are using simple polling and not long polling. Is that right? And why not using the other techniques.

2 - Also, I always find rails incredibly fast but with the notifications I feel that the load generated (in my app, a request every 5 sec) slows down the response time.

3 - And finally the console is full of requests every few seconds and that makes it difficult for debug. Even Better error is kind of acting funny where the shell included doesn't respond well and throw "Session expired" error at times. Is there a way to improve that?

I may well have done something wrong and experience some weird things.

Maybe in a future episode you could implement pub/sub or Websocket notifications.

That's it, just curious about your thoughts on the matter.

Thanks again for you work.

That's correct, I'm using regular interval polling rather than long polling. Long polling is used more as a replacement for something like WebSockets so that you can get realtime communication happening rather than periodically checking for updates.

If you're using long polling, that's a request that will sit open each time, potentially clogging up resources server side because what you're really trying to do there is keep a persistent connection going. ActionCable is a better solution for something like that instead.

Regarding #2, if you're doing regular interval polling, there will be no slowdown. Generating a request once every 5 seconds, when your app can handle say 30 requests per second means that you have consumed 1 request out of the 150 requests (30 requests/sec * 5 sec) which puts very little extra load on the server. Obviously if you've got tons and tons of users, you'll have to scale up accordingly. The notification requests returning JSON are also lighter weight than your average request by a lot because they're not generating a full HTML template. Caching can also speed that up meaning you can squeeze more than 30 requests per second out if some are regular HTML requests and others are the lightweight notification requests.

There will be a lot more requests happening, that's true. Better errors won't be affected by that, but what you're likely seeing is that better_errors really only works best with Webrick, not Puma. The trouble is that when you get into the multi-process and multi-threaded webservers, keeping track of the stack after the request gets very hard and Puma doesn't really allow you to use better_errors like it's intended because of that.

Twitter does simple polling on an interval every few seconds just like what I showed in the episode. If you open up your Webkit console and click on the network tab, you'll see periodic requests to /timeline and /toast_poll every handful of seconds. This is how they send notifications out, so it's definitely a solution that scales nicely for large sites.

The trouble with websocket connections is you can run out of resources quickly because one user is fully consuming a connection to the server. With polling you only use a connection to the server for a few milliseconds and close it afterwards freeing up the resource for someone else. Websockets are persistent so once that user opened the connection, nobody else can use that resource which makes for much harder scaling.

Chris, Thank you for taking the time to explain in details each points mentioned.
I now understand better why you've used regular interval polling.

So many little nuances to everything, it can be really tough to explain and understand it all!