Comments on: Is the Enterprise world Rails ready?

By: nick

nick — Sat, 26 Apr 2008 01:43:53 +0000

The real criticism I can hold against the Rails core team is their failure to provide solutions for large rails applications (in complexity). Enterprise apps tend to be large with lots of special cases and crazy requirements, and Rails doesn’t have anything to help with this problem. It’s still better (in my opinion) than anything else out there, but it needs some help.

Ever try coding an application with 50 controllers and 75 models? Then you’ll know what I’m talking about.

We just need some sort of conventions to deal with it. So its still easy to create a todo list, but also easy to package pieces of functionality up into self contained entities.

But since the Rails core team and 37 signals targets simplistic, stripped down web applications (which I like!), they have no use for these types of features in the framework.

In fact, the Rails core is downright hostile to Engines, a Rails framework extension that seriously tried to deal with the problem. They also added components in, screwed up the implementation, then told us all that no one should ever need components anyways and just use spaghetti code consisting of before_filters everywhere and partials.

If Rails core cared about the issue enough, they would have integrated Engines or built their own alternative in order to allow Rails applications to be packaged up as components and working. There’s a reason the Django community is taking off, its because they solved this problem. Django apps are extremely scalable in functionality because you can partition pieces off into components that encapsulate large chunks of functionality and work well together.

But the state things are in now, Rails Engines is unusable, Rails is difficult for large apps, and people would rather blame the enterprises for not adopting the attitude that all web apps should be variations on todo lists and blogs.

By: Lasse Durucz

Lasse Durucz — Thu, 24 Apr 2008 09:27:13 +0000

The question whether the enterprise is ready for Rails is interesting and relevant. My company started out evaluating Rails and did a rather systematical analysis. We concluded that Rails would outperform our existing web development which is java, but we needed to adapt to the existing infrastructure to use it for more than simple standalone webapps.
The biggest challenge was how Rails would integrate with existing (legacy) systems. These are all java (pojo) and oracle, with a lot of stored procedures and prepared statements. The system architecture is layered with frontend (web and java) clients and backend servers all behind firewalls and proxy’s.
Layers: browser | proxy | web clients | backend servers | database
For security reasons there is no way we will put a Rails client directly in front of the database. The rails client has to be connected to a backend server, and most transactions between the client and server must be cryptographically encrypted and signed.
Another requirement is that the business logic must be available between the backend servers through transaction handlers.
We examined 3 different solutions in a pragmatic way, all with the mindset of keeping as much good Rails stuff as possible. These include migrations, Rspec and CI, MVC and AR.
1) Jruby backend and REST client. Declined, because jruby on the backend side is not trivial to intergrate with the existing java servers. REST client doesn’t support relationship like has_many.
2) DRB (jruby) backend and Rails client. Declined, because DRB backend and java ingeneration does not work properly. RPC creates lot of traffic between client and server.
3) Rails (jruby) client and java server. This works fine, with a twist!
To elaborate a bit on 3. To be able to use as much as possible of Rails we created a “java adapter”. Most of Rails is “in memory” operations and all the good stuff in MVC and html-helpers is nice. But the beauty lies in AR. Ultimately AR is persisting data with normal CRUD operations. Our “java adapter” hooks in on these operations, and connects to a java (socket) server which “knows” what to do base upon naming conventions. The persistence is all prepared statements in the java server, and the server handlers are available in pure java to all the other backend servers. We can use our secure transaction framework for encryption and signing as well.
To be able to use the full Rails stack during development, the developers have the usual mysql local database and uses migrations. These are handed over to the DBA which performs the art of database refactoring. We developed utilities that create code for the java server handlers. This is done by parsing the SQL created by AR in combination with the CRUD operation.
The first application based upon this “framework”, a rich UI RBAC client, is going live in June.
So my conclusion must be that “our enterprise” is ready and so is Rails !

By: Maximilian Schulz

Maximilian Schulz — Mon, 21 Apr 2008 14:51:18 +0000

Thank you Antonio…

By: Jeff Self

Jeff Self — Mon, 21 Apr 2008 13:12:23 +0000

I don’t believe Rails is or will ever be a good fit in the “enterprise”. Why? The enterprise is where existing data lives. While Rails is fantastic for writing standalone web apps, it sucks when trying to use legacy data. Rails strengths are its weaknesses in the enterprise. This is why I can’t understand how big business latched onto Rails so quickly. Rails also won’t fit it in well at my company. Besides the fact it doesn’t work well with legacy data, it also doesn’t work with our development process. DBA’s have control over the databases. They create them. Rails migrations would never fly here.

I believe Django has a better chance at working in the enterprise. Unfortunately, we don’t have a DB2 driver yet for Django (thats for another discussion that I brought up last month on the django-developers site) but I think Django works much better with existing data than Rails does. Django does have one glaring weakness however. It only supports a single database at a time. This needs to be addressed.

I’m currently using ColdFusion at work and it definitely works good in my company. Our data is in DB2 that sits on IBM mainframe. I can connect to as many databases as I want. I just wish Django had this capability as I find it much more productive than ColdFusion.

So it really comes down to use the right tool for the job. Is Rails enterprise ready? Not in my company. But thats not a criticism. Its not a fault with Rails, its just that Rails wasn’t designed for my environment. And thats fine. If I need a standalone web app, I won’t hesitate to consider Rails.

By: szeryf

szeryf — Mon, 21 Apr 2008 09:32:05 +0000

There’s another way you didn’t mention: quit your boring, frustrating job at Big Enterprise Co. and start working at New Exciting Startup company 🙂

By: Antonio Cangiano

Antonio Cangiano — Mon, 21 Apr 2008 09:03:06 +0000

Here you go, Stefan: http://www.scribemedia.org/2006/06/30/dave-thomas

By: Stefan Tilkov

Stefan Tilkov — Mon, 21 Apr 2008 08:47:53 +0000

I wanted to take a look at the Dave Thomas keynote to see how many of his concerns have been addressed in the meantime, but couldn’t find it online. Anybody have a link?

By: This Week in Ruby (April 21, 2008) | Zen and the Art of Programming

This Week in Ruby (April 21, 2008) | Zen and the Art of Programming — Mon, 21 Apr 2008 08:20:42 +0000

[…] the more philosophical side, I published an article called Is the Enterprise world Rails ready? in which I discuss Rails’ origins and their consequences on Rails’ applicability within […]

By: Antonio Cangiano

Antonio Cangiano — Mon, 21 Apr 2008 07:12:06 +0000

@chromatic, I see where you’re coming from but I assure you that there isn’t any intention of distorting history. In fact, I believe we are saying the same thing (more or less). Yes, MVC existed before Rails, yes there were plenty of skilled web developers who were aware of the architectural pattern before 2004/2005. Read my sentence carefully though: “it made the MVC paradigm an accepted and almost expected reality in other web frameworks that come out later”. Most of the web frameworks created after Rails were influenced into adopting the MVC pattern because Rails did so very successfully. The pattern was accepted and well understood before 2005, but that doesn’t mean that it was as common and expected in other frameworks, like it is today. ActiveRecord wasn’t a new pattern either, but Rails made it more popular/mainstream as well. In any case, this is a tiny detail out of a larger article whose main point has nothing to do with MVC. Do you have any comments on Rails and the Enterprise?

@Joe: a modular framework makes life easier in the sense that you can rewrite a single component, and still take advantage of the rest of the framework. You also take advantage of more possible combinations for the ORM, template engine, etcetera. Merb is a promising framework, and I’ve been watching it closely. But it will still require that the crucial components that can be plugged in, are written with enterprise needs in mind.

By: Joe

Joe — Mon, 21 Apr 2008 06:36:36 +0000

Is there a better way?

What about a framework that merely encourages choice of ORM, View Engine, etc, like Merb? That would solve many of the issues mentioned in this article.