I've been reading this on the way to and from work this week and I have to say it's definitely a book that exceeded my initial expectations. My initial thoughts about the books contents were (probably in line with most peoples thoughts of a book called 'Enterprise Rails') were that it would be filled with details on XML and SOAP and SOA and have very little information that is in lines with 'Railisms' that keep the elegance of the Rails framework. I figured there may be some nuggets of information about scalable architecture that would prove useful in the long run, which is why I acquired a copy.
As it turns out, I was wrong on almost every front. The book keeps 'Railisms' very much intact, instead concentrating on the areas that are ignored or under-treated in other rails books. It starts with chapters on code organisation using plugins and modules (and I immediately adopted the module organisation for one of my projects, before it was too late). It then moves on to several chapters targeted entirely at the database. Now, I don't consider myself bad at DB design and implementation. I can produce a data layout fairly easily that conforms to 3NF but I normally stopped there. The author here doesn't. He pushes well beyond this point into Domain Key Normal Form, shows how to easily base ActiveRecord models off views, how to ensure referential integrity at the database layer instead of in the application (where it is surprisingly easy to bypass even keeping within the ActiveRecord API) and generally pushing the database back up to a solid, working part of your application. In direct contrast, most rails books consider the database as of secondary concern and usually completely abstracted away by the use of ActiveRecord and migrations. The author acknowledges this viewpoint but points out that it is driven very much by applications that haven't reached the complexity of a 'simple' enterprise application and moreover it is supported in many ways by MySQL, which lacks the features of commercial quality databases and leads developers to think that these features are unimportant. The author makes the valid point that by the time these features become important (because your application has become hugely popular and is dying under the load) it is often too late to implement them in a complete fashion. So the chosen route is to engineer in all the constraints from the start and to choose PostgreSQL as the database, which is an open-source offering that DOES offer most of the features of a commercial offering.
That encompasses the first half of the book (the book is just over 300 pages long), and it is a testament to the quality of the author that he has fitted so much data into this space while not skimping on the quality of explanations or code samples. After just under a week of reading I have gone through the database and just started on his sections on SOA... and so far, it's as good quality as the database sections! Rather than the rather hazy descriptions regarding services you frequently get before someone launches into complicated SOAP envelopes and overwhelming a reader with XML, instead we get a picture of SOA as an architecture that does to monolithic web applications what OO design did to procedural coding.
Unfortunately, that is as far as I've read so far but based entirely on the first 2/3s of the book, I would say that this book is a must for any serious rails developer. It is well written, sensible, it keeps all the lovely rails conventions us developers love but fills in the gaps where Rails doesn't quite cover the ground completely. You may think you don't need the advice and code from this book, and you may be right. But if you plan on creating the Next Big Thing (tm) and building a site that WILL scale, then this book is a definite read.
Posts
