I am wondering how to integrate node.js on a rails app (for learning purpose).
Based on Michael Hartl tutorial (http://railstutorial.org/) I realized a basic twitter clone with rails and want to get user microposts in real-time without the use of comet or juggernaut. (the application is hosted on heroku)
For the moment, I only see example with node.js frameworks (http://howtonode.org/grasshopper-shoutbox) but nothing merged with a ruby on rails app.
I would be very thankful if someone knows a good tutorial or give me some points to start in order to accomplish this.
Thanks!
As Shripad said, I'd consider trying to build your app with Node by itself. Geddy will feel familiar (getting started anyway) if you have experience with Rails. Note: I do not have experience on a real world app with Geddy, but it is the best Rails-like framework I've seen so far. For persistence you can use SQLite, PostgreSQL or CouchDB, just like you would with Rails. I thought about how to communicate between a Rails app and Node without any intermediary. In our work project we're using Redis as an intermediary between Rails and Node. Rails publishes messages to Redis, Node pulls messages from Redis. I could not find a good way or example projects to avoid the middle communication layer on a personal project, so I went with the same setup. The good news is Node Redis modules are written and once you get everything installed, it is easy to test out pushing messages back and forth.
If you are looking at creating real-time apps then go with node.js (high concurrency) alone. You really cannot integrate node.js into a rails app. You can however have a node server setup on another port with an api and websockets configured and then have your rails app communicate with that server. It is PITA to do that kind of setup. You rather build the entire web app in node itself. However, if you want anything rails specific that does not use juggernaut then i would suggest http://www.pusherapp.com.
Its extremely easy to setup server push using Pusher.
It already did. Not really NodeJs but a framework built on top if it. Yada, yada, yada... check this out: https://github.com/1602/express-on-railway
**Run node along side your rails server**
If you want to intergrate your Rails app with Node you could use the node-rails gem
Node Rails will enable you to run a Node server along side your Rails application and have the two share authentication NodeRails assumes you are using Devise for your authentication. Node-Rails uses [redis gem][2] , so you will need to have that installed.
Learn more about using npm packages on Rails.
Related
Iam a novice in rails and trying to write my first React frontend. I have read enough to know that there are different methods to use React with rails. I decided to split frontend and backend, and use rails in API mode. I cannot find good sources explaining what I need on my server to get rails and react going, and why. I read so far about npm, node.js, Heroku and so on, but i lack the knowledge to decide what to pick and i dont understand the interactions yet.
Does someone know a good tutorial, some sources or keywords to point me to a direction?
If you want to use Rails just in API mode with React on frontend then you can separate those apps completely.
I.e. use Rails/Puma server for API and have a separate server (Nginx/Apache/Node.js) to serve the frontend React app and other static assets.
For using react as your client-side application and rails for the server-side you need two different applications. As Rails is MVC I suggest you use just ruby and Sinatra server.
In this situation be careful about the cross-origin errors you have to enable it while using two agents.
Take a look at this.
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.
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.
I have a Rails application that right now is pretty standard: Heroku/PostgreSQL backend, users go directly to my site to update data, there's no mobile app or anything. We're going to start licensing out the tech to other companies, so that different versions of the interface live on company1.mywebsite.com, company2.mywebsite.com, etc, where all of these interfaces share the same database.
I want some advice on how to go about building this. Do I create a separate Rails app for company1, company2, etc (with a lot of redundant code) and then set up each of them with API keys to query my master app, using its RESTful routes?
Any tutorials to point me to would be great as well.
I recommend you the book Service Oriented Design with Ruby and Rails, by Paul Dix. It has a lot of info about the kind of system that you want to build.
To answer your question:
Build an API server. It serves a JSON – for example – RESTful interface.
api.mydomain/client1/users.json
Build a frontend server. It consume the API service – using typhoeus for example – and serves the final pages. It uses a subdomain or domain name for identification of different clients.
client1.mydomain/users
We have a similar "platform".
What we did:
build a master API app (REST + Push)
build a core plugin for rails which has all the shared code
build a separate rails app for each client which has all the client specific code
We are using this setup for 3 years now and I'm pretty happy with it.
I'm very new to web programming (or actually, very old to it, since the last time I messed with the web was HTML 1.1), but now need to deploy a web application quickly. It seems like every time I turn around, there's new acronyms and technologies to learn (JSON, XMLRPC, GWT, Javascript, Rails, etc).
Here's what my app must do:
Given a username and password, authenticate (easy enough, everything does that, apparently).
Allow the user to upload a large glob of data for processing.
Process that data.
Allow the user to download their processed data.
I've already got Java scripts and a database for handling the data. On one machine, I can run a series of command-line programs to process an incoming datablock and put the results back into a mysql database. That is already present and working.
I want to construct a web front-end to this task, using these existing and tested methods. I'm currently leaning to this approach:
Have two machines, a database machine and a web server. That approach allows for later scalability, if necessary, but also requires that I can't assume that the programs that I use to access the data and manipulate it are locally stored.
Use a Ruby DRb application to create a server and a client. The client would pass data to the server which would in turn call these applications.
Use some other Ruby interface to interact with the DRb for the web frontend.
Here's my problem: it looks like most Ruby applications for the web automatically try to build some kind of local database. All the Rails tutorials I've found start with making your own database and interacting with that, which is exactly what I don't want to do.
Is Rails the right technology for me, or using Ruby DRb? Is there some other technology I should be exploring?
If Rails or Ruby is the Right Thing here, what should I be looking at? I already have the Programming Ruby book, and have used that for some of the backend stuff as well as getting basic DRb stuff working.
Sounds like Rails might be a bit heavyweight for your situation. Perhaps Sinatra might be a better fit? It's an ultra-lightweight framework: a hello world app might look something like:
require 'sinatra'
get '/' do
"Hello World!"
end
Rails is fine. You can have development and test databases on your local machine and the production database on a remote machine. It doesn't have to be the web server. Get a copy of Agile Web Development with Rails. It'll teach you all you need to know.