Product Description

What does it take to develop an enterprise application with Rails? Enterprise Rails introduces several time-tested software engineering principles to prepare you for the challenge of building a high-performance, scalable website with global reach. You'll learn how to design a solid architecture that ties the many parts of an enterprise website together, including the database, your servers and clients, and other services as well.

Many Rails developers think that planning for scale is unnecessary. But there's nothing worse than an application that fails because it can't handle sudden success. Throughout this book, you'll work on an example enterprise project to learn first-hand what's involved in architecting serious web applications.

With this book, you will:

• Tour an ideal enterprise systems layout: how Rails fits in, and which elements don't rely on Rails
  
• Learn to structure a Rails 2.0 application for complex websites
  
• Discover how plugins can support reusable code and improve application clarity
  
• Build a solid data model--a fortress--that protects your data from corruption
  
• Base an ActiveRecord model on a database view, and build support for multiple table inheritance
  
• Explore service-oriented architecture and web services with XML-RPC and REST
  
• See how caching can be a dependable way to improve performance

Building for scale requires more work up front, but you'll have a flexible website that can be extended easily when your needs change. Enterprise Rails teaches you how to architect scalable Rails applications from the ground up.

Product Details

• Amazon Sales Rank: #149576 in Books
• Published on: 2008-10-01
• Original language: English
• Number of items: 1
• Binding: Paperback
• 325 pages

Review
Enterprise Rails is indispensable for anyone planning to build enterprise web services. It's one thing to get your service off the ground with a framework like Rails, but quite another to construct a system that will hold up at enterprise scale. The secret is to make good architectural choices from the beginning. Chak shows you how to make those choices. Ignore his advice at your peril. --Hal Abelson, Prof. of Computer Science and Engineering, MIT

About the Author
Dan Chak's varied education in real-world web architecture gives him a unique perspective on the challenges of building rock-solid web applications. Dan has worked at Amazon.com, the world's biggest online retail store, where seemingly small technology problems become big ones due to enormous scale. Dan also directed software development at CourseAdvisor Inc., a Ruby on Rails startup company. A nearly instant success, CourseAdvisor was acquired by the Washington Post Company in October 2007. You can hear his thoughts on his blog at http://blog.chak.org.

Customer Reviews

Not Your Typical Rails Book
Dan Chak is obviously one smart guy, and I agree with the other reviewers in that this book provides a lot of information not found in any other Rails books.

I have neither the advantage nor experience of working on a large, complex site like Amazon (where Dan worked), so for all I know maybe all of his ideas border on necessity for a site of that complexity. But there does seem to be a lot of straying from the normal philosophies espoused in virtually every other Rails book.

For example, he eschews migrations and instead does all schema manipulation via SQL DDL statements. And choosing PostgreSQL over MySQL means that on more than one occasion MySQL users are left trying to figure out how to accomplish what he has just covered.

None of which is bad; heck, Rails is Latin for "opinionated", right? But if you're in a fairly small shop working on non-Amazon-size websites (which most of them are), I question how many of these fairly complex strategies will be implemented given the perpetual "behind schedule" state we all seem to be in most of the time, not to mention the pressures of "getting something out the door" as soon as possible.

Regarding this issue, I think he himself put it best during his discussion of REST vs. XML-RPC vs. SOAP: "... we must remind ourselves that in the enterprise practicality is at least as important as purity." (Ada, anyone?)

While we all know that "pay me now or pay me later" and "an ounce of prevention is worth a pound of cure" are absolute truths, the real world often dictates we ditch these proverbs.

Regardless, I think this book is a must-read for serious Rails developers. Dan raises a heckuva lot of good points that you won't find anywhere else.

Superb intro to enterprise web applications; a little light on Rails
Dan Chak has written a really excellent introduction to enterprise web application architecture, and a worthy candidate for your technical bookshelf.

Calling it "Enterprise Rails" is a bit misleading, though. Rails only makes fleeting appearances. There's a great introduction to Rails plugin writing, which rightfully urges developers to move any decorator code to plugin modules. He talks a little about segmenting class files along Physical, Logical and Service boundaries, the point of which I have yet to understand completely. And there's a chapter on pushing Rails' application-layer polymorphism down to the data layer, which is good advice, but more on that later.

The bulk of Enterprise Rails is devoted to building a solid data layer. Again, good advice. The Rails team decided that referential integrity and validation belongs in the application layer, which Chak contends is dangerous (and I believe him). However, this is where things start to get a little hairy - enforcing referential integrity and validation in the data layer requires an early and continued adherence to SQL, and Chak makes it clear that any old SQL won't do: it's PostgreSQL or nothing.

This makes fully half of the book a dissertation on SQL domain description language from the Postgre perspective, domain data, third normal form and other data layer topics. I have greatly enjoyed the introduction to Postgres DDL, but it wasn't exactly what I expected from a Rails book.

The last few chapters are mostly about Service Oriented Architecture (which I suspect is why most people buy this book) and caching. Chak shows why he's an expert in enterprise software architecture here. But again, he takes a decidedly anti-Rails approach, emphasizing ActionWebService and XML-RPC. This is not without reason - nearly every language has an XML-RPC library. But ActionWebService, as Chak notes, isn't part of core Rails any longer.

REST is quickly reviewed, then mostly dismissed. There's a cursory example of a RESTful service. ActiveResource, Rails' useful core module for REST-oriented SOA, is never mentioned.

Pretty much every time Rails comes up in Enterprise Rails (which, as we've seen, isn't often), it's an opportunity for Chak to take it down a peg. Well, Rails deserves it. But I think that slapping the word "Rails" on the book cover is has more to do with marketing than anything else. This is really a tale about data modeling for the enterprise, with an emphasis on Postgre, told by an expert.

I'd say that this is required reading for enterprise developers, but don't take the "Rails" part of the title too seriously.

Rails for grown ups
With the possible exception of Obie's, every Rails book I've ever seen reads like it was written to impress marginally literate teenagers more so than provide any semblance of real education, thereby catapulting their authors toward some perverse notion of IRC fame. Nobody dares point out any of the framework's flaws for fear of angering the infallible DHH and being ostracized from the internet clique his ego has built up over the years, so instead of practical information we have a giant sludgy pool of homogenized evangelism to wade through as we figure the ugly bits out for ourselves.

This title is different in that it openly rails on Rails' shortcomings, and suggests some tried-and-true tactics for working around them in real applications that do something besides update videogame scores and try to recreate YouTube. There aren't any lame attempts at being clever or terrible drawings by "Why," either, which is always a plus.

Unfortunately, it seems like it was rushed out the door as I found dozens of pretty bad typos in my first reading. It also predates Rack, Metal and Engines, but still, it's the first Rails book I've come across that hasn't annoyed the tar out of me with simpering sycophantry and I'd highly recommend it to anyone who has real work to do.