Recently I've been looking for a solution to implement real-time updating web pages, for example, Twitter-like news feed or real-time chat. I've discovered some ways, as Pusher service, faye, and quite a lot of ruby gems, like private_pub or sync.
The problem is that this solutions don't seem to be a completely right way to follow. Pusher is rather expensive, and in fact I would not prefer to use other servie in my project. Faye seems insecure, and it is quite hard to implement security for it. Private_pub does the right thing, but last commit on github was in 2013 and in fact it is quite outdated.
All in all, ways that I have discovered do not seem to be professional-grade solutions for Rails startups. I have come up to the question whether I should completely switch to NodeJS or other technologies, or I can integrate NodeJS app inside a Rails one?
To sum up, is there such solution for Rails framework, or switch to another technologies is inevitable?
It may not help you right now, but at RailsConf last month DHH announced that Rails 5 will add support for websockets via a new library called ActionCable.
https://www.youtube.com/watch?v=oMlX9i9Icno
MessageBus might be a good fit. It's currently used in Discourse to implement live updates.
I'm also not sure what your security concerns about Faye are exactly. You should have no issues if everything is operating over HTTPS with proper CORS settings.
As for a mixed Node/Rails solution, you could push some list (e.g. post and list of those to be notified) on an update in the Rails app to a Redis instance. A Node app subscribed to Redis could then notify clients to make a request back to the Rails server for the latest updates.
Related
I have been conflicted for a great deal of time in deciding how to update the app I am developing with notifications. In my app, users can post. I want to alert Users of new posts, just like facebook. However, given that Heroku does not support websockets and the like, deciding what to do has been tough. I DO NOT want to use pusher or pubnub as those services have outrageous prices.
In doing research, I learned about socket.io, which uses websockets if supported, then falls back on flash, or long polling to keep a connection to the server. This seems like the obvious choice for notifications b/c it will allow cross platform integration, it will be easy to implement websockets down the road, and its free.
I have been searching for a Rails 3+ Heroku supported socket.io gem, but I have read so many conflicting things that I am in great confusion. What are/is the best gem(s) to implement socket.io for Rails 3+ & Heroku?
We do not support long lived connections on heroku, so unfortunately using socket.io is not supported either. I would suggest that you use AJAX pulling (as Jakub Arnold suggests) to accomplish the same thing.
This may be sort of a newb-ish question. I know you can do this kind of thing in Node.js pretty easily, but I don't know what it's called and haven't had much luck with Google.
Basically, I am trying to build a simple tic-tac-toe server with Ruby on Rails. Players connect to each other, and moves are recorded and results processed live. If it was just having the user send messages to the server, that would be easily done with AJAX. However, I want to have the client wait and listen for the server to point out that the other player has made a move, and then automatically respond to that. I could do this by pinging the server with AJAX constantly, but there must be a better way. I feel like I'm missing some big technology that I haven't found yet just because I'm not entirely sure how to describe it or what it would be called.
Would I want to have the client connect directly to the server and maintain a live connection? If so, how would I do that? If not, what is the better way to do this? How do online games and stock tickers and streaming services provide their content to the client, and what tools does Rails give me to do something similar?
Check eventmachine in ruby
some links
https://github.com/eventmachine/eventmachine/wiki
http://20bits.com/article/an-eventmachine-tutorial
http://rubysource.com/introduction-to-event-machine
There is a faye and private_pub gem which makes things simpler .
There are railcasts available.
http://railscasts.com/episodes/260-messaging-with-faye
http://railscasts.com/episodes/316-private-pub
I recommend trying private_pub which is built on top on faye which uses eventmachine which can solve most of your questions
the pub/sub model helps to the client to subscribe to its channel
, so you can push updated to the channel which will be eventually passed to the client.
Your question and my answers
Q. Would I want to have the client connect directly to the server and maintain a live connection? If so, how would I do that?
A. You can use private_pub or faye to establish long connections and push data
also Check our later for pusher.com they provide services on commercial basis.
Q.How do online games and stock tickers and streaming services provide their content to the client, and what tools does Rails give me to do something similar?
A. AFAIK everyone uses some sort of push technology. pub/sub model. ruby has some gems available for such requirements, faye private_pub some of them..
For a commercial solution, check out Pusher, it does pretty much exactly what you want:
http://pusher.com/
For open source solutions, check out Faye (a pub/sub messaging server):
http://faye.jcoglan.com/
and some awesome railscasts explaining it:
http://railscasts.com/episodes/260-messaging-with-faye
http://railscasts.com/episodes/316-private-pub
I'm building a Rails app where I need a real time commenting system. I'm going to use WebSockets, but I'm new to them and I'm kinda lost. I tried em-websockets and websocket-rails, but neither worked well with what I have to do. I also though of a Node.JS and Socket.io app, but I don't know how to start with that.
What I want to do is send a WebSocket message when a new comment is made on a post, on the create action of my CommentsController. I'll send a message containing the comment content and creator and the post ID.
Thanks in advance! :D
Sorry, but I dont think so. Be careful with WebSockets. It is fundamental concept that provides a very powerful mechanism.
Websockets is good for super, absolutely real-time applications like online games. For commenting system (even realtime) you dont need them, the AJAX is more then enought for this.
You could use a realtime hosted service if you don't want to deal with your own realtime infrastructure, fallbacks for older browsers, scaling complications etc.
I recently wrote a post on Smashing Mag on building a realtime commenting system. It uses PHP and Pusher (who I work for) but the separation between client and server should meant that you could use any backend technology/service. It also demonstrates how to progressively enhance your app.
The most commonly used self-hosted ruby technologies for realtime communication does seem to be Faye, as #Alfred suggested.
Just using websockets as the only available transport is not a good idea, because websockets are not yet supported in every browser. Luckily for example Faye does support multiple transports so that it will work in every browser. I also found this interesting video in the past explaining how you could use Faye in conjunction with RoR from RailsCast.
I'm trying to create a ruby on rails ecommerce application, where potential customers will be able to place an order and the store owner will be able to receive the order in real-time.
The finalized order will be recorded into the database (at the moment SQLite), and the storeowner will have a browser window open, where the new orders will appear just after the order is finalized.
(Application info: I'm using the HOBO rails framework, and planning to host the app in Heroku)
I'm now considering the best technology to implement this, as the application is expected to have a lot of users sending in a lot of orders:
1) Each browser window refreshes the page every X minutes, polling the server continuously for new records (new orders). Of course, this puts a heavy load on the server.
2) As above, but poll the server with some kind of AJAX framework.
3) Use some kind of server push technology, like 'comet' asynchronous messaging. Found Juggernaut, only problem is that it is using Flash and custom ports, and this could be a problem as my app should be accessible behind corporate firewalls and NAT.
4) I'm also checking node.js framework, seems to be efficient for this kind of asynchronous messaging, though it is not supported in Heroku.
Which is the most efficient way to implement this kind of functionality? Is there perhaps another method that I have not thought of?
Thank you for your time and help!
Node.js would probably be a nice fit - it's fast, loves realtime and has great comet support. Only downside is that you are introducing another technology into your solution. It's pretty fun to program in tho and a lot of the libraries have been inspired by rails and sinatra.
I know heroku has been running a node.js beta for a while and people were using it as part of the recent nodeknockout competition. See this blog post. If that's not an option, you could definitely host it elsewhere. If you host it at heroku, you might be able to proxy requests. Otherwise, you could happily run it off a sub domain so you can share cookies.
Also checkout socket.io. It does a great job of choosing the best way to do comet based on the browser's capabilities.
To share data between node and rails, you could share cookies and then store the session data in your database where both applications can get to it. A more involved architecture might involve using Redis to publish messages between them. Or you might be able to get away with passing everything you need in the http requests.
In HTTP, requests can only come from the client. Thus the best options are what you already mentioned (polling and HTTP streaming).
Polling is the easier to implement option; it will use quite a bit of bandwidth though. That's why you should keep the requests and responses as small as possible, so you should definitely use XHR (Ajax) for this.
Your other option is HTTP streaming (Comet); it will require more work on the set up, but you might find it worth the effort. You can give Realtime on Rails a shot. For more information and tips on how to reduce bandwidth usage, see:
http://ajaxpatterns.org/Periodic_Refresh
http://ajaxpatterns.org/HTTP_Streaming
Actually, if you have your storeowner run Chrome (other browsers will follow soon), you can use WebSockets (just for the storeowner's notification though), which allows you to have a constant connection open, and you can send data to the browser without the browser requesting anything.
There are a few websocket libraries for node.js, but i believe you can do it easily yourself using just a regular tcp connection.
Since Rails is not multithreaded (yet), it seems like a threaded web framework would be a better choice for a Facebook application. (reason being is cuz each Rails process can only handle one request at a time, and facebook actions tend to be slow, because there is a lot of network communication between your app and facebook)
Has anyone used Merb to write a Facebook application? Is there a port of Facebooker (the Facebook plugin for Rails) to Merb?
We've used merb_facebooker in one of our projects (Rock the Vote), and it worked out pretty well. Testing Facebook apps is quite annoying, as you don't have control of the middleware, so watch out for your expectations of the FB API and make sure you validate as much of them as possible early in the development stages (not trying out all the things we needed to do with fbML early on brought a few headaches).
Behold, merb_facebooker.
In addition, if you want to use Facebooker directly (like for a desktop app,) just install the gem:
gem install facebooker
Have you looked at Starling? It's the server used by twitter to handle their messages. It's a persistent queue server that allows you to delegate jobs to workers.
You can run passenger on Apache which will start up as many Rails instances as it needs up to a certain limit (I think the default is 30). It will also kill them as required, so if you're not getting as many hits as you were 5 minutes ago, it will release the system resources back to the system.
Learn more about passenger at http://modrails.com