When starting off on the path to integrate Rails into an existing environment, one of the key questions is to decide when to use Rails and when to stick with your "legacy" language.
Unless your site consists of a single unified application, you're probably not going to be in a situation where you'd simply port everything over to Rails. And, there are plenty of good arguments against halting development to complete a wholesale port. We also have a number of major projects built in PHP. We're keeping those in PHP for now, at least until the costs outweigh the benefits.
So, we're only creating a Rails project when we're faced with either a brand new project, or if the existing codebase is so creaky and worn out that it just isn't worth continuing. In our case, we had a number of projects that met the latter criteria.
We also had been using PHP heavily on our "static" pages. We used PHP to include common elements, such as navigation and branding, and to show/hide content depending on the user's context. There isn't a clear migration path into Rails for this type of functionality, short of either deploying everything into a content management system, or treating every page as a view. Neither option seemed palatable, so PHP has maintained its place in the front-end of our website.
It should not be surprising that we're using Rails solely in the "application" space. In our case, however, sometimes an "application" ends up being a single-page form. As long as there is significantly complicated stuff happening behind the scenes, it it worth using the power (and server resources) of Rails. So, our Rails apps tend to be things like event calendars, membership signup/management systems, and authentication systems.
For the foreseeable future, our site will remain a mix of PHP and Rails.
(I'll dive into more technical details in the next post.)
Posted by Karl
September 13, 2006 09:58 PM