If you want to run it yourself on a public-facing server, you'll need to change the connection to Socket.IO on line 2 of /public/js/script.js to point to your server instead of localhost. I also had to edit /views/themes/default/room_list.jade and put the 'each room,key in rooms' bit inside of an 'if rooms' statement because that was throwing an error.
Also worth noting, nothing is filtered (you can send <script> tags for example and they'll run for everyone).
Yes. But every chat application in node.js that has ever been presented in HN faced the same fate of being brought down to a crawling pulp whenever it had more than 100 or so concurrent users.
Which is a bit amusing, as I remember standalone IRC servers handling 40,000+ peak users with relative ease -- and that was back in the late 90s on commodity server hardware.
40k might be pushing it, but 10-15k should be no problem on current hardware.
More importantly IRC servers have a battle hardened scaling solution baked right in, based on the spanning tree protocol.
Anyone looking to write a scalable chat software would be well advised to study the evolution of IRC. Anyone looking to hack a scalable chat solution would be well advised to use a mature IRCd for the backend.
Edit: I hung out on DALnet back when twisted was still linked and when it got taken down the crush of the users, as the article mentions, rendered the network virtuall inaccessible. Goes to show what happens when you rely too much on one link.
This makes me wonder, what is the difference in technologies? I never used IRC to be honest, was it downloadable software or was it web based? (I'm not that young I swear, I'll be 35 next week - I just didn't do chat)
Popular GUI-clients would be Colloquy on Mac, mIRC on windows and XChat on linux. Just download one and see for yourself; Freenode is a popular network for hackers of all kinds, QuakeNet is the network for gamers (and also happens to be the biggest with ~60k users online at any given time).
It's just done well. It has stood the test of time, and seen nearly 30 years of development in multiple, competing irc server products. A lot of rivalry and different views and attitudes to certain strategies.
IRC is amazing. Servers are linked as leaves to hubs, or as hubs, linking to other hubs or leaves. If the network splits (one server goes down, breaking the tree) it can be quickly relinked to secondary or tertiary servers, restoring connectivity. For its time, and even to this day, it is an impressive protocol that is not only fairly easy to implement from a client perspective, but a very scalable chat server architecture.
I've yet to use Node.JS for anything yet even though I want too, it looks like Node.JS is only being used for analytics and chat applications is that all it is capable of or are people not fully using the power of Node? Balloons.io is a beautifully designed chat app, better than that of any other Node chat demo I've seen, nice one.
>it looks like Node.JS is only being used for analytics and chat applications is that all it is capable of or are people not fully using the power of Node?
Node is still immature, so it makes sense to use it in spite of the relative roughness only when it has a distinct advantage over other available technologies. Its ecosystem has also streamlined the building of server-push apps.
You can use node/express in lieu of rails or django, but it doesn't offer anything particularly interesting here. Analytics and chat apps tend to be built on persistent servers that have long-running stateful sessions, which the node ecosystem has focused on making easy... you could use EM or Twisted or Netty, but they aren't as shiny / low barrier to entry.
So, we are seeing people take advantage of the comparable strengths of a new technology that makes certain apps easier to build.
And you know... streams, which allow you to easily makes bridges between software and HTTP requests; so you can make video encoding in real time (while is being uploaded) just using node + ffmpeg; or you could process a text file content at the same time is being uploaded (perhaps a database backup?) or you could quickly set up a proxy that doesn't have to store the files.
How scalable is this? I would think it's easy to put together something that serves, say, 100 users simultaneously. But how well does this scale to 100K users?
It depends on how it's implemented. I used node.js to implement the websocket-based real-time aspects of my startup, Worlize, a graphical avatar-based chat platform where everyone can create their own chat world.
I use a sharded approach where each room is assigned to a random node.js websocket server when the first person enters it, and it's unloaded when the last person leaves. Just spin up more websocket servers to scale.
We have a hybrid platform with the website running on Ruby on Rails (REE 1.8.7, Unicorn, fronted by Nginx), and the real-time interaction handled by Node.js. I can tell you that the RoR servers fall over LONG before the Node.js servers even begin to break a sweat.
The two aren't necessarily the same kind of thing. WebSocket-Node is a low-level WebSocket framework. It supports both text and raw binary WebSocket messages. Socket.IO is not a WebSocket library, but sits one level higher on the stack. It's an abstraction layer that supports many different transports and overlays its own messaging semantics. For example, WebSocket-Node could theoretically provide the WebSocket transport for Socket.IO.
If you want WebSocket specifically, and don't care about falling back to long-polling techniques, or you want something that allows you to use true binary messages, look at a WebSocket library rather than an abstracted communications library like Socket.IO.
Because maybe he is looking to develop a chat system that can scale to 100,000 users? There are many instances where someone is tasked to look at a technology and understand how it scales.
Frankly, it would be helpful for you to tell us how "It wouldn't"
Authentication it sounds like:
"Balloons uses easy-OAuth for authentication with twitter. You can easily change this code to authenticate with Facebook, for example, lets with Facebook."
If you want to run it yourself on a public-facing server, you'll need to change the connection to Socket.IO on line 2 of /public/js/script.js to point to your server instead of localhost. I also had to edit /views/themes/default/room_list.jade and put the 'each room,key in rooms' bit inside of an 'if rooms' statement because that was throwing an error.
Also worth noting, nothing is filtered (you can send <script> tags for example and they'll run for everyone).