I want to develop a web file manager based on Rails 4.2 (Ruby 2.1.0) with websockets.
Websocket-rails seems nice, but is dead.
em-websocket lacks documentation (or if you have a link it will be great) and is not fully open source compliant.
What is the best way to use websocket with rails?
Take a look at faye-websocket. Here is a nice railscasts tutorial.
Take a look at the Plezi framework.
The advantage over Faye is that Faye requires you to handle your Redis broadcasting logic yourself, whereas Plezi is a framework, which handles the Redis logic for you and lets you run both your Plezi websockets app and your Rails app on the same port on the same server.
Plezi is also easily scalable when using Redis, as it can run all it's broadcasting and unicasting API through Redis and you don't need to do anything except point it to your Redis server.
As stated in the documentation, You just include your Plezi code in your Rails app as middleware. Easy.
Related
Implementing Web Sockets in my app I've become confused which gem is better. I found plenty of different opportunities, however, some are hard to distinct.
Finally, I've chosen Action Cable (a Rails 5 native part) and Faye (appeared earlier and became very popular).
But now I'm stuck - is Action Cable the same thing as Faye? Which are differences (if there's any)?
From the Faye website: Faye is a publish-subscribe messaging system based on the Bayeux protocol. It provides message servers for Node.js and Ruby, and clients for use on the server and in all major web browsers.
From the ActionCable readme: Action Cable seamlessly integrates WebSockets with the rest of your Rails application. It allows for real-time features to be written in Ruby in the same style and form as the rest of your Rails application, while still being performant and scalable. It's a full-stack offering that provides both a client-side JavaScript framework and a server-side Ruby framework. You have access to your full domain model written with Active Record or your ORM of choice.
Short answer is YES, both are pub/sub messaging system.
Long answer is NO, because faye is a low-level tool and ActionCable uses faye (look here), al least some components.
But you always can get the same results using (maybe) different efforts building an application using faye or ActionCable. The big difference is Faye works as a rack-based component instead of rails-based component.
We have a Rails app that acts HTTP API only. On the client side, Ember.js is currently used. We are not overly impressed by Ember and really like the approach Meteor.js takes. So we'd like to exchange the client side with Meteor.js and communicate with the Rails server via websockets that speak the Data Distribution Protocol (DDP), so we can keep using the models, mailers and controllers in Rails. Implementing server side of DDP should be easy.
However, we're unsure how to make Rails talk websockets. We found Reel, which seems to make it easy to accept websocket requests in a standalone environment. Reel seems great as we'd like to implement the DDP on top of the Celluloid stack anyway. But what about running Reel in the Rails environment? Would we need "rails runner" for that? And we'd like to keep using the existing controllers to dispatch incoming requests (like, to add/change/remove resources). Is that even possible without having the request coming through Rack?
Any input is appreciated.
It's a bit late, but I've implemented DDP in Ruby, you can check it out here:
https://github.com/d-snp/ruby-ddp-server
It includes an implementation of EJSON as well. It's built on top of celluloid-websocket, and can be ran simply as a rack app.
I've made an integration with RethinkDB that can be used as a reference to build your own collections implementation.
https://github.com/d-snp/ruby-ddp-server-rethinkdb
I've also made a sample chat application that can be found here:
https://github.com/d-snp/celluloid-rethinkdb-chat
It's something that I have been longing to do as well, to integrate old "legacy" Rails code. Here is the best way I have found:
Since you would not be using any of Rails router/controller/views, but just the ability to read data and push it to the client, I recommend you use Rails to create JSON apis to the database, and deploy the code, then in Meteor you can consume the data via the http package, this would happen on the server at a regular interval and populate the MongoDB with the normalized data you need, then it would serve the browser client.
I am working on such an application that will keep a normalized version of the data in Mongo, and a relational version of the data in mySql (through Rails) this way I can preserve the legacy Rails functionality that I dont want to rewrite in JS, and get the benefit of Meteor for the one page that I need it most.
If I wanted to translate my node application that uses socket.io into a Ruby on Rails application what are the options for replacing socket.io? (Essentially looking for a socket server for Ruby)
http://socket.io/
Plan to translate the application below:
http://www.tokbox.com/blog/creating-chat-roulette-with-node-js-socket-io-and-opentok/
I'd recommend the Faye Ruby implementation as a solid server-side realtime component. It's not a direct port of socket.io but provides you with the realtime infrastructure and some well define messaging concepts that will help you port most realtime applications.
You can find more options via the realtime web tech guide.
Did you look at the Plezi framework?
You can use it either as a separate framework or to augment Rails/Sinatra by adding websocket functionality.
It runs using the Iodine server and supports native websockets, RESTful routes and HTTP streaming, so it's easy to have a fallback position such as long-pulling, much like socket.io does when web sockets don't work.
It's interesting and easy to develop with and has native support for Redis, so it allows websocket broadcasts between processes and machines... although it's still under development, it's full of potential.
A broadcast/echo WebSocket app can look like this:
require 'plezi'
class Echo
def index
"this is an echo server - use websockets to connect. test with: https://www.websocket.org/echo.html"
end
def on_message data
_echo data
broadcast :_echo, data
end
def _echo data
response << data
end
end
Plezi.route '/', Echo
You can actually put the code in the irb console and the server will start the moment you exit irb using the exit command.
I highly recommend Pubnub, it has many wrappers including ruby.
Documentation is really easy to follow and they have many tutorials.
I have used Pubnub on many rails projects, including raspberry pie projects.
Rails 5 now has ActionCable built in, which means websockets are now standard with Rails!
Is there any Ruby/Rails library for sending PostgreSQL asynchronous notifications via WebSockets?
I need to notify a browser client for updates in a specific database table. I know this can be done with pub/sub APIs, but I'm looking for a Postgres only solution.
I've found a Python tutorial for this, but couldn't find one for Ruby. I need to implement this for production use, so a production-ready library and tutorial would be the best.
I don't know directly about any that does work with websockets, but queue_classic gem uses listen/notify in postgres for a message queueing. It's a good way to start looking how it can be done.
I am new to the web socket framework with Rails and generally I feel I should get my hands to start working with it. I have used Faye for my private message publishing and it works nicely. So I want to ask if there is a nice tutorial out there that can show me how to use web sockets with rails. Thank you.
Node.js + socket.io is probably your easiest option right now. Faye is set up to use Node.js, so you may have already have Node.js running alongside your rails app (depending on how you're using Faye). You'll just want to start using socket.io. The socket.io repo includes some very useful examples - I sugget looking at chat.
You can communicate between your rails app and Node.js server via http. Node.js lets you easily make an http server. You may also want to take a look at request.