Is it true that with passenger (mod_rails), the deployment of Rails is fairly simple? But how about how practical it is, considering it in the competitive software field? Is it true that if deploying Python or PHP framework based website, it can cost just a fraction of a Rails deployment? I am sure there will be a time when Rails deployment is very comparable to other frameworks, but I'd like to get some idea in the highly competitive software field, how competitive Rails is, compared to Python or PHP based frameworks, supporting similar concurrent user requests.
Naturally using something like PHP will require less setup, because apache/{insert_web_server_here} doesn't have to hook into a middleware just to run the application. All it needs is to load php module and it's off and running.
However, I wouldn't let that scare you away from deploying Rails applications. Passenger really makes it easy, as it literally walks you step by step via the command line, and tells you what to put in certain Apache config files etc.
Another advantage of using Passenger is that it uses REE(Ruby Enterprise Edition) in that it is significantly faster than MRI due to their enhanced garbage collection solution etc.
Related
Up to now I've always used PHP with or without a framework but a month ago I decided to start something new: Ruby and Rails, I found them quite easy and similar to PHP and some PHP frameworks in how they works but using a simpler syntax and many other advantages.
Some days ago I started reading about Node.js, Node.js vs Rails, "why node.js is better"...
I'm a bit confused but my objective is to learn something modern that will not become obsolete in a few months so:
What are the main differences between Rails/Ruby and Node.js and a framework based on it like Express.js (except that one is written in JS and the other in Ruby)?
What are the main advantages/disadvantages of using Node.js and framework based on it instead of a Ruby based solution like Rails?
Thanks!
There aren't enough differences between Node.js and Rails for it to practically matter.
A lot of what Node.js can do can be pulled off in Rails with things like EventMachine and Pusher. So unless you are really familiar with Rails' limitations, and know you'll be pushing the boundaries, you'd be hard pressed to make something a seasoned Rails developer couldn't do.
Having built apps in Node and Express I can say that they alone aren't enough to make a sexy application. They can seem just as old and stale if you don't have an outstanding frontend UI to facilitate the backend possibilities. Instead of comparing backend servers, I think the real future of doing amazing things is in front-end JavaScript frameworks like Backbone.js that use Express/Rails/Node.js on the backend.
I have chosen to go in the direction of Backbone.js with Rails as my backend API server. Because it's so easy to rapidly create a very nice RESTful backend server in Rails. Rails also makes working with CoffeeScript and precompiling/organizing Backbone code a breeze. There are already decent Backbone.js gems out there for Rails.
The Rails core is also able to acknowledge and embrace the fact that frontend JS MVCs are logically a good next step, and they have been working to strengthen the bond between the two. For those same reasons they have also worked to make Rails an even better API server so that it can work with frontend JS easier. Node.js and Express aren't putting as much effort to coordinate with frontend JavaScript MVCs as the Rails community is.
Being good with a JavaScript frontend MVC and Rails as a backend makes you also great for both worlds in terms of getting a job. You will easily be able to hop onto a Node.js project and add value to that team with your superior frontend experience, and you can also roll with the punches on a Ruby on Rails team and add value to them as well.
As official Node.js website explains it:
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
On the other hand Ruby on Rails official website says:
Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration.
Given this I guess that it is more appropriate to compare Ruby and Node.js, but even this is not quite right given that Ruby is programming language and Node.js is NOT. You could probably compare JavaScript with Ruby but I guess that is not what you meant to ask with this question :)
So, for me, key point in understanding what Node.js truly tries to accomplish is well described on Node.js about page. Key Node.js idea (for me) is described in this sentences:
Node is similar in design to and influenced by systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further—it presents the event loop as a language construct instead of as a library. In other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a blocking call like EventMachine::run(). In Node there is no such start-the-event-loop call. Node simply enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. This behavior is like browser javascript—the event loop is hidden from the user.
What this should enable you, is that you should be able to easily write highly concurrent programs without even thinking about concurrency using JavaScript syntax and callback functions as basic concurrent runnable units.
Your fear that either Rails or Node.js will be gone in a week is unfounded. Rails has a large community and will be around for a very long time even though currently (early 2012) it's getting a bit of hate thrown its way. Node.js is just getting started and has so much attention I don't think it will have any problems getting to the Rails level some day.
That said I've been evaluating Node.js and Rails as options for a project and the reasons I choose Node.js over Rails are:
"The Rails Way" - In my (admittedly limited) experience with Rails it really seems like you either do it the Rails way or you are going to be in for a world of pain. A big part of the Rails way is to use the ActiveRecord model. The advantage of this is that there are a lot of gems that work with your code happily because they know you'll be using ActiveRecord. The disadvantage is you are mixing your data access & model. I am not a fan of this idea so the Rails way for me still seems a bit.. off.
JavaScript is a key part of client side web development and the idea of using it on the client and server is interesting. I'm not super strong at JavaScript and I can't imagine a better way to get better then to have to use it everywhere.
My project has real time communication needs which while I'm sure can be done in Rails there seems to be quite a bit of positive mention on Nodes ability to handle this with socket.io being the front runner option.
At the end of the day no matter which you choose you will have a great time & learn a ton of new stuff that will change how you write code. If you're not on a big time crunch I'd recommend building a small project management tool in both and see which you prefer.
Either way.. Good Luck!
2 things - performance & productivity.
Performance (more details here)
(source: jslang.info)
Productivity (how fast you can build that app)
Ruby on Rails is specialized and highly productive tool for creating so called Web 1.0 and Web 2.0 applications (99% of internet sites are such apps). In my subjective judgement and experience in this area Rails about 2-4 times more productive than node.js or express.js.
For Web 3.0 apps (realtime things, client-side MVC, etc.) this isn't true, RoR doesn't keep its advantage there.
So choice depends on use case and priorities.
I know a lot more about Node.js than I do about Ruby. That being said, Ruby is much more widely adopted. It is currently a very hot skill to have in the work place. Some may argue with me on this but I think that Node.js is still "under development" and will be for a little bit longer. It has a lot of promise but just hasn't been adopted by many companies and projects yet.
I've been playing around with Rails (version 3) for a few months now and I understand the framework fairly well. However, I have yet to develop a large website which offers lots of database access and user interaction.
I'm fairly skeptical of the following:
The Speed and Scalability of Ruby (I've heard that its up to 10 times slower than most other server-side languages).
The extra background processing that Rails as a framework (multiple levels of abstration).
The lack of enterprise-level web apps that run on Rails (the only ones that I can think of Groupon, Github and Hulu).
The complexity of the environment (nginx > mongrel > rails > ruby > website).
The behind-the-scenes SQL operations (I know that these can be optimized, but I'm sure that I'll miss some).
For these reasons, I'm unsure whether to continue using Rails or to switch to something that is built ontop a more performant language .. say Java Spring.
Please advise :)
There are tons of large sites and infrastructures in production that use Rails. This question has also been asked to death over the years of Rails being actively used for all manner of web apps, large and small.
Short version is that it is not the fastest language around but despite that scales fine if you know what you are doing. And you should have enough money to hire people that know what they are doing if you actually have any problems of scale.
Scaling any webapp is hard, use the language/framework you know. Programmer happiness is king.
You can get good performance with Ruby. Easy:
require 'inline'
inline :C do |builder|
builder.c <<-C_CODE
void run() {
// Write your entire application in C here
}
C_CODE
end
run
Problem solved ;)
Not the speed and scaling discussion again?
In webdevelopment the things that are the slowest is the network communication (receiving the request, getting al your data back), the database (getting all your data from the database), and most of the times it is not about the computation time at all.
While it is true that Ruby and Ruby on Rails seem more focused on programmer happiness, I think that every decent web-application built in .NET or Java has as many levels of abstraction.
The complexity of the environment? I think you mean deploying? There are a lot of options, but the most used options are Passenger (very easy deployment on top of an apache or nginx), or Torquebox.
Torquebox for the moment is the fastest, best scaling solution (based on JBoss Application server), and several big names in the Ruby community are calling Jruby the implementation of choise to deploy your applications. While AFAIK the commonest deploy still is using REE (Ruby Enterprise Edition) and Passenger.
Unless you know you are going to have to do serious mathematical, cpu-intensive operations, I think the question you should ask yourself is: which framework/language will give me the quickest result?
If you are very proficient in Java/Spring, that might be the answer for you. But if your only worry is performance in general, I would say: do not hesitate and go for Ruby on Rails. It is a pure joy to develop in. The ruby community is really awesome if you would encounter any issues: support is just a post away.
And to conclude, I want to add a few very big sites using Rails: LinkedIn is using rails (and jruby), and Twitter still is using Rails for their frontend.
Is there a "best" rails server to use for development (mongral, webrick, etc..)? Or does it not really matter?
Short answer: develop on what you will deploy on.
Long answer: good Rails containers, like Unicorn, Thin, etc, really don't impact your development much but will impact production. And, each has just enough configuration related quirks that interact with your code and choice of gems that just diving in and working in that environment can save a lot of time, even if using continuous integration, but especially if not.
The "best" in my opinion is Passenger in conjunction with your choice of Apache or nginx, whichever you're familiar with. It's perhaps the only game in town when it comes to getting an application running quickly and reliably. The Phusion team has invested a lot of time and effort into building a complete package for a scalable deployment platform.
Mongrel is only designed to be part of your stack and requires a number of supporting pieces to work properly. It also has to be managed with a separate process launcher and that can be frustrating and can cause serious issues if done wrong. Mongrel2 is a better platform but will need some time to be properly assimilated by the Rails community.
Webrick was never intended as a production web server. It is only a toy server for testing. It is painfully slow and can only service one request at a time.
See my answer here Recommendations (and Differences) between different Ruby on Rails Production Web Servers
Background: I have a java library that is accessed by many developers - usually via java. However, a few devs hope to access this via a Ruby API. I am gravitating in the direction of Jruby in order to implement a Java-Ruby API.
Questions:
My main concern is that these developers will not be able to utilize the API in their current, Ruby on Rails development framework; but instead will have to operate within Jruby's rails environment. Is this going to be the case?
Perhaps I'm missing a connection between Jruby and Ruby on Rails. But it seems that you can either work in Rails, or work in Jruby's rails - are these technically two different development environments?
I would really appreciate any light someone could shed on this..
Edit: Forcing developers (actually clients to be more specific) to make large changes to their projects in order to accomodate for this API is not really an option. So, if their Rails apps would have to be converted to Jruby on Rails apps, then perhaps someone could offer yet another alternative for me (other than Jruby)?
First, I should mention that Ruby on Rails is simply Ruby code, and the same code can run in the JRuby environment (on the JVM) or the MRI (written in C) runtime.
However, only JRuby can load Java classes and use a Java API. Asking your clients to switch their deployment environment to JRuby may not be feasible, but if you can set up a service in Java that speaks XML or JSON then they will be able to easily use it from Rails.
You might find the answers to a similar question helpful. Depending on your application it may be possible to seamlessly port your RoR app to run on JRuby subject to the caveats noted in that answer. But you'd want to be sure that the benefits of doing so balanced the effort and potential risks.
Alternatively you might consider making these Java library facilities available to your MRI Rails app as an internal web service (which could be Rails or Sinatra or similar) built on JRuby. That's way you would decouple the elements and de-risk the project. If you subsequently were comfortable with that working you might then consider collapsing them back together, all under JRuby-on-Rails if that made sense.
UPDATE: Adding more detail at questioners request
As I'm not familiar with what your application or Java libraries do this will be somewhat abstract but I trust you can fill in the blanks to suit your needs.
It seems that full porting of your Rails apps to run on Jruby is not feasible. Fine. So one idea would be to expose your Java library as a web service (e.g. RESTful) to your RoR application. Let's call this thing JLS. In this case it would run as a Java or Jruby network service, listening for requests, call into the library and send back responses (general waving of hands here but you get the idea).
Depending on what your developers are more comfortable with you can create JLS in Java running a Servlet container maybe. Or you could develop JLS in Ruby, running on Jruby (binding to your Java library) and use a framework like Rails or Sinatra to implement it.
On the RoR side, assuming you've made JLS RESTful (and I don't know if that's even appropriate in your case), you can use the ActiveResource facility for communicating with JLS.
In summary the RoR app and JLS run in separate memory spaces (maybe even different hosts). Each can be developed somewhat independently (with RESTful interface agreement of course) and your RoR app does not need to be disrupted or put at risk.
This suggested option comes with tons of small print but I hope you get the general idea.
Given that both Ruby on Rails (RoR) and Grails can run on the JVM (Java Virtual Machine), which language and framework enables equally competent and experienced developers to be more productive and roughly by what percentage? (i.e., deliver more business functionaity for the same amount of effort)
I know that Grails is easier for a Java developer to transition to. And I realize that the entire Java Library is available to a Grails developer. My question is regarding developer productivity in an environment where one runs on an JVM on Linux using the standard application servers (WAS, Weblogic, JBOSS, TOMCAT etc.). Note: JRuby will be used to enable RoR to run on the JVM.
I would requests answers from those that have done significant web applications development using both ROR and Grails.
If all you're looking for is a 75% answer: grails
I've done significant development on both platforms, though my major rails experience ended about a year and a half ago (before rails 2.x was released).
I've been heavily involved in grails development since grails 0.5.
The answer really depends quite a bit more on the developers and infrastructure that will be available to work on the project. If you're looking to deploy to a standard java app container (like Tomcat), I think that Grails is the better choice. If you're looking to do something with mongrel/rack/pound/etc. Pick rails.
If there are particular gems/jars that fit your business problem, that would obviously affect your decision.
The choice of Grails for me isn't so much because I think that it's better at solving all kinds of problems, but more because I like the grails developer community better and I like the groovy language a little more.
I've also found grails to be an easier sell to the places I've worked at over ruby/rails. There are many more java shops around here and it's less of a leap for them to make that transition.
This is a personal preference and I could easily see someone else going the other way.
Rails has quite a few things going for it, and I think the test driven development story there is much better (though I'm working on trying to fix that).