Ruby on Rails vs Traditiona PHP

rulian

I'm a web developer in an advertising company, I work with PHP/MySql/Javascript just fine to do what I need to do. We got a new client that insists we use Ruby on Rails, so I start researching it to get familiar.

From what I can tell so far, Rails is basically a very general Pre-Assembled package for web applications, or in a sense, a small short cut to programming, or even a way to develop for people who dont konw how to develop.

From what I gathered, if all it is, is a "framework" for me to work out of, I would rather not spend the time learning a new language, just to save myself from writing my own little snipplets ( or framework ). I feel I can get more powerful applications developing them on my own, rather then a prebuilt base.

Did I get the right impression of ruby on rails, or am I just not getting the point to it? I dont want to dismiss it as the "lay-man's web dev tool", I'm not sure I understand it fully, but so far I just [correction: dont] find it impressive, or even that much useful.

rebelo

This is not really the place to discuss the merits of Rails vs PHP, so expect to see a mod move this thread to a different forum, however, since I work a bit in each environment (I am a full-time PHP developer by day and do a bit of rails play with my professional development time), I can shed a bit of light.

Rails is somewhat a prebuilt base, but most of what it provides you with is good. You get to pick and choose which features of it you want to use in your application. I definitely would not say that "rails is for people who don't know how to develop". It just makes it faster to develop stuff for people who already know what they are doing. For someone who has no concept of separation of data from logic and such, they would probably still be able to make a total mess out of a rails application because it doesn't force you to use all of its helpers (but it does force some rules which are generally good).

The BIG features you get when you develop in rails compared to just putting together your own applications from the ground-up are things like built-in debugging, profiling, database connections, logging, and the list goes on. Of particular note, the debugging and application consoles rails ships with are terrific.

I have found using xdebug (http://xdebug.org/) with the vim-xdebug plugin to be a really nice set of helpers for developing large php applications.

rulian

IC, Thanks for your help, shedding light onto the subject. I have to get back to the client of whether we will develop in the Rails framework or not. Since I'm not familiar with the Ruby language, I'm going to recommend we stick with what we know.

So Rails is basically a collection classes and functions that are basically prebuilt common web app features.

piersk

Question: why hasn't the client gone to a company that already uses ROR? I find it very strange that they've come to you and said "We want you to build this, but we want you to use tools that you've not used before"

Sxooter

RoR is impressive in that it allows you develop web sites really fast, but from a DBA perspective, it's really simple, and not designed for anything complex. It's also slow as molasses. What I can do in milliseconds in php with RoR takes seconds. Fine for some apps, where you have only a few users at a time, or are database bound anyway (reporting apps are a common one I think RoR is suitable for.)

But if you need to handle dozens to hundreds of users at a time, it would require a farm of servers while a single pentium 100 running php would rocket right past it for anything computationally intensive.

Just a note, it bugs the crap out of me when a client says "you must use this spiffy new tech because it's hip and cool". That is NOT the reason to choose a language / framework.

piersk

Sxooter wrote:
Fine for some apps, where you have only a few users at a time, or are database bound anyway (reporting apps are a common one I think RoR is suitable for.)

I know that Twitter uses RoR and they're starting to have major issues with the amount of users they have. (see here for a couple of details about the problems. There's a blog that has an interview with one of the twitter developers and he says that they're having issues with speed cos of the database conections.

One thing I'd like to see is benchmark comparisons between RoR and PHP and RoR and something like the Zend framework.

I think when it comes down to it (and this has probably been mentioned int he PHP framework thread) do you want your site developed quickly or carefully?

Sxooter

They should write a simple harvest the front page once every x seconds and cache it type app in php to sit in front of it. 🙂

csn

Sxooter wrote:
RoR is impressive in that it allows you develop web sites really fast, but from a DBA perspective, it's really simple, and not designed for anything complex. It's also slow as molasses. What I can do in milliseconds in php with RoR takes seconds. Fine for some apps, where you have only a few users at a time, or are database bound anyway (reporting apps are a common one I think RoR is suitable for.)

But if you need to handle dozens to hundreds of users at a time, it would require a farm of servers while a single pentium 100 running php would rocket right past it for anything computationally intensive.

Just a note, it bugs the crap out of me when a client says "you must use this spiffy new tech because it's hip and cool". That is NOT the reason to choose a language / framework.

Gotta disagree with ya Sxooter! ;P I switched over all my heavy apps from PHP to Rails about a year ago. I found that performance was noticeably better and DB performance definitely wasn't slower. I've also found Rails to be up to the task for the most complex queries I've needed to do. It takes some relearning as most of the time you're not using SQL, but it allows that too if need be. There are many sites with respectable loads using Rails. 43 Things, 37 Signals' sites (Backpack, etc.), Twitter, and others.

To the OP--I haven't looked back since switching. Rails is a pleasure to use compared to PHP. I haven't found it lacking at all and it has far more out of the box. One awesome utility is Capistrano which makes deployment a cinch. I'd bet your client wants you to use Rails for their own future maintainability benefit. I look back at my old PHP and it makes me shudder. My old (ish) Rails code is almost instantly easy to figure out. And Rails has a lot of debugging support built-in. In debug mode it's very easy to spot which queries are hitting the CPU. I wholeheartedly recommend Rails. But expect to spend months learning it.

Finally, here are some funny Rails vs. PHP/Java "commercials" styled after Apple's:
http://railsenvy.com

csn

piersk wrote:
I know that Twitter uses RoR and they're starting to have major issues with the amount of users they have. (see here for a couple of details about the problems. There's a blog that has an interview with one of the twitter developers and he says that they're having issues with speed cos of the database conections.

One thing I'd like to see is benchmark comparisons between RoR and PHP and RoR and something like the Zend framework.

I think when it comes down to it (and this has probably been mentioned int he PHP framework thread) do you want your site developed quickly or carefully?

There's more info about the Twitter issue here:
http://www.loudthinking.com

And there are benchmarks out there. I don't remember where. Basically, Ruby is a bit slower than PHP. Pretty much a non-issue.

sneakyimp

What I would like to know is how they handle the return of insert ids between MySQL and PostGRES. In mysql you use [man]mysql_insert_id[/man]

in postgres (and i'm not at all sure about this) but apparently you put in some extra sql and the query function returns values:

$sql = "INSERT INTO distributors (did, dname) VALUES (DEFAULT, 'XYZ Widgets') RETURNING did;";
$result = pg_query($sql);

Weedpacket

sneakyimp wrote:
in postgres (and i'm not at all sure about this) but apparently you put in some extra sql and the query function returns values:

No, you use the PostgreSQL PDO driver's lastInsertId method. Unless you're still doing old-school db queries (because your choice of framework hasn't been upgraded to use PDO yet...) in which case you retrieve the currvalue of the relevant sequence object.

Sxooter

Note that as of 8.2 you can also using the "returning" clause:

 Insert a single row into table distributors, returning the sequence number generated by the DEFAULT clause:

INSERT INTO distributors (did, dname) VALUES (DEFAULT, 'XYZ Widgets')
   RETURNING did;

But I don't know if PDO knows about that.

The last time I tried to use PDO it wasn't reliable for pgsql, but that was a couple of years ago...

Sxooter

csn wrote:
Gotta disagree with ya Sxooter! ;P I switched over all my heavy apps from PHP to Rails about a year ago. I found that performance was noticeably better and DB performance definitely wasn't slower. I've also found Rails to be up to the task for the most complex queries I've needed to do.

My issue(s) with RAILs in general...

It seems that it is designed around the "referential integrity via application" model. Which doesn't scale and isn't reliable. It seems MySQL centric. I actually donated a couple of patches to fix the pgsql personality when I first tried it, and was shocked, shocked I say, at how it seemed to be put together.

Things like using select * from get data from a table, then relying on column order after that.

Has all of that changed? I would hope so.

In terms of performance, the base language might be about as fast as PHP, but the classes that make ROR what it is seem very slow and pokey.

csn

Sxooter wrote:
My issue(s) with RAILs in general...

It seems that it is designed around the "referential integrity via application" model. Which doesn't scale and isn't reliable. It seems MySQL centric. I actually donated a couple of patches to fix the pgsql personality when I first tried it, and was shocked, shocked I say, at how it seemed to be put together.

Things like using select * from get data from a table, then relying on column order after that.

Has all of that changed? I would hope so.

In terms of performance, the base language might be about as fast as PHP, but the classes that make ROR what it is seem very slow and pokey.

Yeah, I understand your concern 😉, and being kind of fond of sprocs at that time, it almost turned me off. But then I read DHH's "Chose a single layer of cleverness" (on loudthinking.com) and it makes sense. Now I actually prefer it. You don't have to switch gears (i.e. languages) to setup RI in your database--just do it in the app. And it's really easy. Only thing is if you muck around with psql (which I KNOW you like to do!) or phppgadmin, you gotta be careful. The alternative is to use Rails' console, which I gotta admit I don't like as much. AFAIK, it scales just fine and is reliable as long as you don't shoot yourself in the foot by mucking with the database directly. I haven't had any problems for which I'm not responsible (by using psql/phppgadmin directly). There was talk a while ago about having Rails figure out RI directly from the database, but I don't know what if anything has come of it.

I can also assure you that, as a devoted PostgreSQL user myself 😉, Rails isn't MySQL-centric. It seems that most of the core team prefers MySQL, but there are many others that know PostgreSQL is better and have done a lot of work ensuring it works fine. Robby on Rails' site has a lot of Rails with PostgreSQL info. I've had a few issues, but they've all been resolved. I think there might still be one outstanding, but I can't remember at the moment. At any rate, my apps have been chugging along in production for over a year without incident.

As for "relying on column order", you can specify column order, but you'll have to use straight SQL. Maybe there's another way--haven't played around with that for a while.

I haven't found Rails' classes to be pokey at all. The only thing that is is initial loadup--which happens mostly when occasionally loading the console during development. One of the core team who works for Google said that issue was being worked on. Rails owes a lot of thanks to Zed Shaw for Mongrel which performs really well as an app/web server. Before that, using mod_ruby, cgi, et al was a real PITA.

Sxooter

Interesting, I went to google, and the link given for Choose a single layer of cleverness is currently dead.

Where I work we have 40 or so developers, each with their own idea of how to model RI and such. We have two devdb folk, and I'm one of them. We're the gate keepers of the RI model, and we make sure that our airline reservation system doesn't just suddenly forget something by use of RI. No matter how well thought out the framework, or how noble the meanings of the developers, they make some really stupid decisions, day in and day out, that we have to rework into a usable data model that is both fast and efficient, AND robust. If we left it up to the developers, we'd have a pile of crap no one could keep running.

Doing RI in the app is inefficient. Maybe you don't work on a system that's designed to handle 100,000 reservations a day. I do. And if we did RI in the app we'd be farked. How can I have 12 app servers handle RI independently? Answer? I can't. So, they'd all have to talk to each other every time they tried to commit. The amount of interaction between them would increase at a severely non-linear rate as the load increased, and the whole thing would collapse from either exhausting the network or the app server CPUs. meanwhile, oracle or postgresql can handle the RI in their sleep.

RI in the app is one of those "seemed like a good idea at the time" things that bites you in the ass with non-scalability at a later date.

An example of a scalability issue and how we solved it. We had a table with locatorcodes, which are 6 character alphanms with A-Z0-9 characters. In the airline industry, the locatorcode is the key to the record. You have to check one out of a table with millions available in it everytime you create a reservation.

Our old way did it app centric. Ask the database for one with the used field set to 0, set the used field to 1, and go on. This took about 0.2 to 0.5 seconds on a loaded system. that may not seem much, but it was a large part of our load. And the time was going up exponentially as more processes were checking them out due to locking issues.

We changed it. We now have a sequence (something real databases like oracl e and postgresql have) and we have an id for each row. You get the next sequence, grab the corresponding row, knowing a sequence never repeats, and mark the row used, which is really kind of a formality we may even drop at some point.

Time to run that stored proc in oracle on a heavily loaded db? 0.0001 seconds.

Those kinds of things are what you have to do in the real world to get the performance needed to run a large transactional system. when I see someone building a large test system with ROR that can handle load even 1/10th that of one relying on the database with stored procs, I will buy the chief architect a beer, in person, along with a pizza.

It's not going to happen with RI in the app. period.

csn

Yeah, see the last post at loudthinking.com--DHH suffered a crash and didn't have the best of backup policies. I googled a bit but couldn't find a copy of the article.

I've never dealt with farms on the scale you do. But I know others who have multiple app servers using RoR and have never heard about issues with scalability related to RI. If you have multiple database servers, isn't it pretty much the same thing? They have to talk to each other too. Frankly, this is unfamiliar territory for me, but others seem to be making it work with Rails.

BTW, Sxooter, can you hook me up with some free flights? Thanks! 😛

csn

Oh yeah, doing RI in the app only makes me nervous too, especially if multiple developers were to be involved. It feels like having a back door open. All it takes is for one of them to have permission, or an absent-minded dba, and fire up psql or phppgadmin...

I've heard of people setting up redundant RI, in the app and the db. Hopefully Rails will one day read RI from the db. But, you know, there ARE other best practices, and if the dev team is denied access to direct db access tools and everybody accesses the database as Rails intends, then no problems.

csn

Sxooter wrote:
Those kinds of things are what you have to do in the real world to get the performance needed to run a large transactional system. when I see someone building a large test system with ROR that can handle load even 1/10th that of one relying on the database with stored procs, I will buy the chief architect a beer, in person, along with a pizza.

It's not going to happen with RI in the app. period.

I'm curious--are you saying that 37 Signals' sites, 43 Things, Twitter, etc. are 1/10 as fast? Based on what? That definitely doesn't seem to be the case. The guy who runs 43 Things has a blog that details its setup. I think they use memcached at those levels.

Sxooter

csn wrote:
I'm curious--are you saying that 37 Signals' sites, 43 Things, Twitter, etc. are 1/10 as fast? Based on what? That definitely doesn't seem to be the case. The guy who runs 43 Things has a blog that details its setup. I think they use memcached at those levels.

Those are not transactional sites. My original post had mention of TPC benchmarks etc... that I managed to edit away, and left it half formed.

When Sabre, or Amazon, or ebay starting doing their RI / transactions in ruby, we'll have something to compare.

Piranha

csn wrote:
Yeah, I understand your concern 😉, and being kind of fond of sprocs at that time, it almost turned me off. But then I read DHH's "Chose a single layer of cleverness" (on loudthinking.com) and it makes sense. Now I actually prefer it. You don't have to switch gears (i.e. languages) to setup RI in your database--just do it in the app. And it's really easy. Only thing is if you muck around with psql (which I KNOW you like to do!) or phppgadmin, you gotta be careful. The alternative is to use Rails' console, which I gotta admit I don't like as much. AFAIK, it scales just fine and is reliable as long as you don't shoot yourself in the foot by mucking with the database directly. I haven't had any problems for which I'm not responsible (by using psql/phppgadmin directly). There was talk a while ago about having Rails figure out RI directly from the database, but I don't know what if anything has come of it.

So basically what you are saying that only ROR should be able to handle the database, or that the database should be set up to only handle ROR? One of the reasons to use a database is to be able to store the data in a way that is not dependent on the programming. By having to develop the database for ROR you disregard this reason for a database.

Note that I haven't looked into ROR or anything that have got to do with it, other than this thread. It might be that I misinterperated what you said, or that it is easy to handle the database outside ROR. I simply don't know. I just think this is wirth considering before starting to use ROR.