[hamxiaoz]

I have a simple rails app now I want to add realtime to it, it seems I have those options:

a. rails + node.js + reddis

b. 'rewrite' the rails app in meteor.js

c. rails + firebase

Any suggestions? Anyone uses meteor.js from a rails background?

[1qaz2wsx3edc]

1. Rails + SSE (server sent events) - http://tenderlovemaking.com/2012/07/30/is-it-live.html

2. Rails + Pusher

Those are the best solutions, at hand that would work well with Rails.

I wouldn't advise smashing a Rails app and a Meteor app together unless you have a solid case to do so (like migrating).

Rails, aside, I'm happy to here oplog has landed. 1.0 feels imminent, the tension is growing, even here in Toronto. Stop waiting sheeple, Meteor is great as is, and it's only getting better.

[RaphiePS]

I guess it all depends on how "deeply" realtime your app needs to be.

For example, if you just want to add chat between users I think you'd be well-served by Firebase for the chat. If you want to roll-your-own, there are a million Node.js chat tutorials.

However, if you'll be making important changes to "real" data, as in anything you're persisting with ActiveRecord, b is your best bet.

[iguana]

meteor.js is really cool, but it is not ready for production, so it depends on how important your app is. Scaling it beyond a single server is actually not that simple.

Another factor to look at is how extensive the realtime functionality will be. If you just want to make a realtime dashboard for your app, using ajax with a partial to redraw a div every second (or do nothing if the ajax returns no change) is really simple compared to having to add the complexity of another service in a different language (remember that node.js will run on a different port and as a separate process from rails).

If your app is highly dependent on realtime, and you're not planning on launching to a wide audience in 6 months, sure, rewrite in meteor.

[debergalis]

Sure it is -- people are using Meteor in production already, and on multiple servers. Oplog tailing is the big story there.

[ericb]

What about tubesock with Rails 4? https://github.com/ngauthier/tubesock

[ninthfrank07]

Try using https://github.com/chrismccord/sync (real-time Rails partials with Pusher or Faye).

Or rewriting the app in Meteor is also a good option. I used to be a Rails developer but I am currently making the switch to Meteor.

[jkarneges]

If you already have a database and just need to send stuff to the page, you can set up Faye or Pushpin alongside your app without having to rewrite anything.

If you like SaaS realtime, in addition to Firebase there's also PubNub and Fanout.io.

[prezjordan]

Try option C first and see how that works out for you. Seems like the least amount of work.

[camus2]

ruby has Event Machine , Celluloid ,... you dont need meteor or nodejs for realtime apps, really,they are as good as any javascript server solution.

[imslavko]

Can Event Machine or Celluloid give me reactive updates from my database made by a different process or service (like some background task with message queue)? Or are you bringing those as alternatives to EventEmitter of node.js?

[imslavko]

My point is: neither Event Reactor nor Actor model implementation are sufficient to make your database realtime (push updates to the application server). And the amount of work that was put into MongoDB actually doing it correctly and reliably is very undervalued in this thread.

That's why there are so few "real-time" solutions built around databases (NoSQL or SQL): Meteor, Firebase, GoInstant.

Always keeping everything in memory and updating clients as soon as the server have gotten a write is a different story with different complexity and different scaling limits. (but it can be done more efficiently utilizing RAM servers like Redis; Redis has built-in notification interface).

[Argorak]

They are a low-level Event Reactor and Actor implementation, respectively. Sure, you can built that, if your database supports it.