As it is evident that AJAX based chats do not scale, so what would you use for chats? Custom servers? Or any other methods?
Since with Rails each chat connection will take lots of memory, it won't be feasible to even have Rails run for each message. What do you recommend for use here?
I also tried to implement a sample chat app with AJAX (in built Ajax.updater) but it didn't workout. I'm sure there might be some good ajax solution.
But since this is based on server push technology, try Juggernaut (http://juggernaut.rubyforge.org/). I personally haven't tried, but it seems like it's good.
Or else consider web sockets (in HTML5) if possible.
People often use Evented Ruby for handling problems like this https://github.com/eventmachine/eventmachine one of the examples in a talk I went to at railsconf 2010.
For example http://playtype.net/past/2009/3/11/mini_an_eventmachine_clone_of/ is a evented ruby implementation of an irc bot
Unfortunately your post is based on a false premise. AJAX based chat certainly can scale, you just have to do it the right way. Juggernaut 2, for example, uses Node.js to handle many concurrent connections. You're right, you won't be able to handle 10,000 connections on a single server. That's what load balancing is for.
Do you have some data based on quantitative testing (aside from your own qualitative conclusions)?
Why create any kind of custom server for chat? IRC has been around for quite a while and is tried and tested.
The real question here should be about client-side implementations rather than trying to reinvent the wheel server side imo.
Related
I am trying to figure out whether I can build a web application completely on Ruby stack.
I am looking for following architecture:
Frontend <--- Websockets with Pub/Sub ---> Backend
On top of that, I really like Rails approach with "convention over configuration". As result, I am looking for some "opinionated" framework which will handle this scenario.
I know that it's easier to achieve with Javascript stack. As example using Sails.js.
However, it's experiment. So, I am not looking for the most efficient solution.
Has anybody build anything like that? What would be a reasonable set of libraries/frameworks to build something like it?
Since you said it's an experiment, I would recommend you to try out Volt. It uses Opal, which transcribes Ruby to JS and has reactive synchronization which Meteor.js is famous for. Also there are a lot of Railisms and you will find yourself in familiar waters very quickly.
Both technologies are not quite there yet, but there is a lot of hype around them and they will for sure play a big role in Ruby's near future.
As #ndn mentioned, Volt is interesting... But, it seems to me that the part I would adopt would be the Opal core for a front end.
Volt is too opinionated for me.
I would like to add my own pet project to the table, Plezi, which can be both an independent framework and can also run together within a Rails app by using the Iodine server.
I feel that Plezi has a much better balance between 'convention over configuration' and code-freedom. It manages the backend by automatically mapping websocket broadcasts/unicasts to their respective controller and method (broadcast :method, arg1, arg2...) and automatically maps Redis channels to controllers (or global multicasting) for easy scaling.
At the same time, Plezi does nothing for the front end and assume nothing regarding the front end. This is by design, both for better security (doesn't auto-trust incoming network data) and to allow for for the variety of possible clients such as native apps (iOS, android), browsers, scripts etc'... This would be where Opal can come in (or RubyMotion).
I need a way for my web application to send push-notifications to the client side. Realtime is not a strong requirement, near-realtime is okay. I don't need anything fancy, just sending a string to the client every now and then, nothing more. What's really important is that the solution must be very simple and low-profile (performance-wise mainly). Could you give me advice on which framework to use?
Many people would say SignalR hands down, but I'm not sure about the performance part. It is not disqualified, I'll tell about my doubts below, and I'm also interested about any insights you may have about this, but the main question stays what I wrote above.
I read this article recently. What it provides is a long-running request pattern with only a few classes, a little IIS & async magic and nothing more. Even if you have an IIS connection limit of 200, it will barely use up any of those connections. Compared to this, SignalR is as complex and heavy-weight as a nuclear power plant. It comes with half a dozen different DLL's (like OWIN, which I haven't heard about before, and even after a bit of Googling, I can't figure out what it is). The performance wiki page of SignalR starts by suggesting to increase your concurrent request limit to a ridiculous amount. So I'm guessing it's not using the aforementioned "trick". I'm not exactly sure how bad that is, but in the light of that article, it doesn't sound good.
If you really want to push messages to the client, SignalR approach is very good. As far as I know it works with web-sockets. Try to digg this way. Here is some article for the beginning:
http://blogs.msdn.com/b/youssefm/archive/2012/07/17/building-real-time-web-apps-with-asp-net-webapi-and-websockets.aspx.
For mobile apps I would use great library PushSharp. https://github.com/Redth/PushSharp
With help of PushSharp you can send notifications to any mobile app: WindowsPhone, IOS, Android, Blackberry etc.
Please note: sending push notification differs from platform to platform.
Keep in mind approach with pinging server all the time and checking for new messages. It is probably the easiest way.
I use SignalR and toastr.js. SignalR can scale to thousands of connections. There are also native SignalR clients for iOS and Android (check out Signalr-ObjC).
Since noone answered about the resource requirements and my doubts about SignalR, which was the key question here, I'm accepting this as an answer: http://www.codeproject.com/Articles/27107/Scalable-COMET-Combined-with-ASP-NET .
I am going to design a website using ruby on rails. And one of the features i want to implement is the chat functionality. Where users can chat with the other users/members of the website. What i should be using or in other words start learning in order to design something like that ?
Is XMPP the answer. if so, i would be glad if someone could be a bit descriptive on where to go from there and/or suggest some books. thanks !
I said XMPP because i know Facebook uses that and i plan to create something similar
Protocols can become a pretty hairy topic, implementing a well-working protocol yourself can be pretty daunting without prior experience. Especially if it has to do with (near) real-time communication between several parties. If this is supposed to scale to any significant number of visitors, implementing this correctly can be pretty tough.
XMPP is a protocol that is already well established, is shaken down and already has many stable implementations. So when using it, you do not need to worry about designing or implementing the protocol anymore. For that reason, I'd really recommend it. It's also a rather easy to understand protocol, even if you will have to spend some time reading up on the basics in the beginning. Look neigh further than http://xmpp.org for documentation.
Setting up an XMPP server can be done in minutes, depending on your OS and the server you choose. The caveat is that if you want to customize the server at all, you will have to learn about the innards of it as well to some degree, which may or may not take some time.
The bottom line is: choosing XMPP and existing XMPP libraries and servers, you get 90% of the functionality for free and can concentrate on implementing your client. The question is, how much will you have to dig into the details of XMPP and the server, will this take longer than rolling your own protocol and will your own protocol suit your needs in the long term as well as XMPP would?
You always have to think about how much you want to spend on implementing this.
If you go with XMPP you will be able to run a XMPP standard chat server (outside of Rails) and should be able to use a JavaScript Client with a XMPP to HTTP Bridge.
A project a quick Google Search brought up doing this is Strophe.
But I'd argue that you should think long and hard about if XMPP really suits your needs and if you really want to go through all that trouble for a Chat.
Implementing your own is also not straightforward, especially when you are writing all the long-polling and signaling stuff yourself.
But it's not impossible and should give you a simple working solution in a couple of days.
Doing the chat yourself in Rails will require you however to use an alternative Database since Rails can't store data in-memory between requests and persisting chat data in ActiveRecord seems like not a very scalable and good idea.
Using XMPP obviously has the benefit of your users being able to connect to your Chat service using iChat, Jabber or any other XMPP Client..
I have an app written in `RAILS' and i want to add few features to the project but i feel like using django to write those features since i am more comfortable in Python/Django.is there any way i can write the app in django and tel Rails server to handle the request to forward the request once django part user is clicked.
The only idea I have in mind to make this work is for the Django app to provide an API that the Rails app could use. But why would you want to mix the two up? I don't think this is a good idea. Besides using Django only to write certain features is under utilizing it.
If there truly was benefit to introduce an entirely new stack into your environment (personally I question that benefit but you certainly more about your requirements more than I do), I'd go the path of messaging versus a more service driven approach. Going with messaging will better insulate your systems from each other and give you a lot more flexibility which will come in handy as both systems evolve.
I'm trying to write a scalable interactive chat application for an existing high traffic website. It needs to be scalable on day 1, and chat's concurrency and multi-broadcast issues make it a tricky thing to scale.
My initial plan was to write the whole thing in rails and refactor the chat server into erlang later.
Although I am an experienced PHP dev and sysadmin, both node.js and RoR are new and extremely alien technologies to me, so I could use a little help understanding the core concepts and applications in this scenario. With so many new technologies, it is hard to understand them all.
Firstly, I recommend you review http://ajaxim.com/. The software is a pre-packaged version of what you want that relies on Node JS (far easier than rolling your own).
If you still want to write something yourself and have no experience with either technology, I recommend you review some introductory materials:
Node JS and Rails
The two sources are not free but will give you a quick one hour crash course on each technology.
You can also have a look at http://pusherapp.com ! This is if you want to implement a chat app right away.
If on the other hand, you want to implement one all by yourself, Node.js + Socket.io is your best bet. However, if you want chat rooms and stuff, have a look at this:
http://github.com/shripadk/express-juggernaut-demo
This demo app uses Express.JS framework and Juggernaut 2.
I would suggest going for only Node.js if you are building apps that require high concurrency. Its fairly easy to implement a chat room using Node.js compared to other server-side languages (mainly thanks to modules like socket.io). The event-driven architecture of Node.js makes it really easy to implement such stuff. The only catch with Node is that you have to think everything asynchronous! If you are good at Javascript then Node.js should be easy to learn.