Ryan Bigg - Exploding Rails

Thank you for reading Exploding Rails.

If you find any misteaks while reading this book, please email them tome@ryanbigg.com.

If you have a problem to do with your code, then please put the code on GitHub andlink me to it in the email so I can clone it and attempt to reproduce the problem myself. Ifyou dont understand something, then its more likely that Im the idiot andrushed it when I wrote it. Let me know!

This far into the book and theres already one error. You should expect that itis not alone. It has friends and their ways are devious. They are coming afteryour perception of reality. Beware.

In similar fashion to my Toy RobotWalkthrough, this book started out as a blogpost that I was going to put up at ryanbigg.com. I knewthat this post was going to be very long the very first day I started writingit, because it was 5,000 words by the end of the day and I still had a lot tosay on the topic of organising a Rails application in a better way. Its nowabout 15,000 words. So I think it deserves to be a little book on Leanpub,rather than just a blog on my website.

The idea for this blog-post-turned-book came out of the CultureAmp Junior Engineering Program that I am running. Oneof the junior developers that I mentor Seb Pearce came up with the ideaof building an expense tracker application. So I thought, OK, this is going tobe a run-of-the-mill Rails application with a Transaction model and so on.Then he told me that he wanted to build the application in Ruby, withoutRails.

Well then.

So we went about doing that, sticking to plain Ruby code as much as possible.Eventually, we introduced some gems like rom-rb, rom-sql, dry-validationand dry-transaction. I had only really toyed around with these gemspreviously, and had never built anything serious with them, and so whenpairing with Seb it gave us both an opportunity to explore using these gems ina semi-serious application.

And it was bloody brilliant.

The code for validating a transactions attributes lived over here. The codefor talking with the database lived over here. The models of theapplication were slimmed right down to classes that knew only what attributesand business logic Transaction objects should have.

It reminded me a lot of how I felt when I saw Rails for the first time:everything had a neat orderly place. There were clean lines ofresponsibility between each part of the application. The model was no longer aone-stop-shop for validation, persistence and business logic. The modelstopped feeling like that moving box labelled miscellaneous that you dumpall your trinkets into during a move. The model felt like it represented thestructure of data for a particular thing in the application, and that wasbeautiful. The model only had a single responsibility.

(I should also mention that Phoenixapplications are structured somewhat similarly, but since this is a Ruby bookthat is all I will be saying about Elixir, for now.)

Seb and I have just recently gotten to the point of integrating his plain Rubycode with a Ruby web framework, with the intention of providing an API that aReact frontend can read from. After a little bit ofdeliberation over what non-Rails framework he could use, Seb settled onSinatra. Its a fine choice that works well for Sebs application.

Meanwhile, I wanted to play around with rom-rb and dry-rb in a Railsapplication of my own making. My first goal was that I wanted to build a Railsapplication without Active Record. The second goal was that if the logic inthe controller got too messy, I would have to abstract that out to a serviceobject with dry-transaction. Youll see how Ive accomplished both of thosegoals in this guide.

I found out that there was a gem called rom-rails and I startedexperimenting. The notes that I took eventually coalesced into this guide.

This book is best suited for experienced Rails developers. Ill assume a lotof knowledge around things like the normal structure of Rails applications,feature testing, what at least the concept of a service object is, and so on.

If youre new to Ruby, you will probably understand some of the terms Imusing here, but to get the most out of this guide you should have some Railsexperience under your belt.

Ideally, you shouldve encountered places where using vanilla Rails has hurtyou, your friends and possibly even your family members. But thats notnecessary because theres a few examples peppered throughout this guide thatwill give you a good inkling. Rails is good, but it is not without its flaws.

This book is not supposed to be The Bible of How to Integrate ROM into yourRails application. Its merely a short guide covering how one eager developerbuilt the beginnings of a little Rails application using the rom-rb anddry-rb gems.

Id like to thank Tiya Belayneh, Andy Holland, Tim Riley, Chris Flipse, andPiotr Solnica for their feedback on early editions of this book. It has beeninvaluable to have such dedicated readers reviewing this book. I would alsolike to thank Rob Jacoby and Seb Pearce (again) for inspiring me to write thefirst chapter of the book.

Thank you to Francois Beausoleil, Bruno Bonamin, Brian Buchalter, AceDimasuhid, Rob Howard, and Michael Kohl, Rocio Diaz-Meco, Sean Liu and TristanPenman for reporting errata in this book.

Theres probably more errata to report, so if you find any, please emailme@ryanbigg.com with what you find and you too can go on this list ofoutstanding people.