I was wondering if any of you had insights about which one is better, and what factors should be taken into consideration when using one of these
相关问题
- Question marks after images and js/css files in ra
- npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fs
- Using :remote => true with hover event
- Eager-loading association count with Arel (Rails 3
- google-drive can't get push notifications
相关文章
- node连接远程oracle报错
- Right way to deploy Rails + Puma + Postgres app to
- How can make folder with Firebase Cloud Functions
- AWS S3 in rails - how to set the s3_signature_vers
- how to call a active record named scope with a str
- How to add a JSON column in MySQL with Rails 5 Mig
- “No explicit conversion of Symbol into String” for
- form_for wrong number of arguments in rails 4
Why are you limiting yourself to Cramp on the ruby side?
You can use Rails also for real-time apps with websocket-rails.
You could also use real-time frameworks such as Plezi or Volt... both Volt and Plezi work better than Cramp, in my opinion (but I'm biased, as I wrote the Plezi framework).
Here is a simple echo websocket server with Plezi:
I can speak more from the other (Node.js) side. I just wrote a gem that integrates with Rails 3 that uses a Node.js back-end for listening to Redis PUBSUB messages and updates the Rails front-end accordingly.
Socket.IO + Node is not hard to integrate with a Rails app (especially if working with jQuery), but depending on your targeted browser base (like IE7), it can be tricky to get working right in all cases, namely because of some weird cases when using Flash Socket as a fallback (usually where WebSockets don't work).
That said, I highly recommend Node.js + Socket.IO. It is super light-weight with a lot of options and flexibility to extend to do almost anything you could want. In my opinion, Rails is a fantastic web framework for building bigger apps that need a computationally heavy front-end. I would not choose to use it for small, event driven applications simply because it uses so much memory for the framework alone. I love Ruby/Rails, but when it comes to needing something for quick and clean event processing/message handling, Node has my vote.
If you need more concrete examples, my project Kthxbye (a Resque-esque clone) communicates with Redis which in turn is listened to by Node.JS which in turn can update a web application.
Plugin: http://github.com/plukevdh/kthxbye (see: http://github.com/plukevdh/kthxbye/blob/master/lib/generators/kthxbye/templates/kthxbye.js)
Node Backend: http://github.com/plukevdh/kthxbye-node (see: http://github.com/plukevdh/kthxbye-node/blob/master/poll.js)
(Apologies for the complete lack of documentation on the node project.)
I played around with cramp and rails 3 a while back. Was trying to build a view with dynamic updates using WebSockets to channel data back and forth between clients and the server. It worked perfectly with Chrome, but Safari 5 and FF implement a more recent version of the websocket protocol and Cramp does not so I couldn't get it to work there.
I agree that using Ruby for the whole stack is nice, but I feat that Cramp right now is lagging slightly behind the curve in some aspects.
I decided to bite the bullet and use node.js (and the SocketIO package) for my stuff.
Good luck!
I'm writing a somewhat non-trivial web app using Rails (3) and Cramp together at the moment. I don't have any experience with Node.js, and I only just started using Cramp as it is, but it looks promising. And in my opinion, being able to use Ruby is a big plus! (I started with Tornado (Python) and couldn't bear the language. Sorry Python fans!)
The downside is that I have found very, very little third-party material on Cramp. I guess that's not surprising considering how new it is, but you're more or less on your own. If you need your hand held, you probably shouldn't use Cramp.
Check out different repos of cramp. WebSockets are moving target, and living on the edge isn't that easy. github.com/maccman/cramp fork works with rescent websockets implementation, while original cramp is not up to date and under refactoring. Also take a look at eventmachine-websockets. Anyway - be prepeared to use thin+eventmachine on serverside. With cramp you should run thin in production mode , cramp is not that good yet.