This blog has been archived. Our writing has moved to makandra cards.
The blog of , a Ruby on Rails development team

Our new e-book: Growing Rails Applications in Practice

Find below the opening chapter of our new e-book: Growing Rails Applications in Practice. The complete book will be published this summer. Enjoy!


How we got here

When you started doing Rails some years ago, it all seemed so easy. You saw the blog-in-ten-minutes video. You reproduced the result. ActiveRecord felt great and everything had its place.

Fast forward two years. Your blog is now a full-blown CMS with a hundred models and controllers. Your team has grown to four developers. Every change to the application is a pain. Your code feels like a house of cards.

You turn to the internet for assistance, and many solution seem to be available. You should move away from fat controllers, it says. But do avoid fat models. And use DCI. Or CQRS. Or SOA. As you cycle through patterns, your application is becoming a patchwork of different coding techniques. New team members are having a hard time catching up. And you're beginning to question if all those new techniques actually help, or if you're just adding layers of indirection.

You start missing the early days, when everything had seemed so easy and every new piece of code had its place. You actually liked ActiveRecord before it drowned you in a sea of callbacks. If only there was a way to do things "the Rails way" without having it fall apart as your application grows.

The myth of the infinitely scalable architecture

We'd like to show you one path to write Rails apps that are a joy to understand and change, even as your team and codebase grows. This book describes a complete toolbox that has served us well for all requirements that we have encountered.

But before we do that, we need to let you in on an inconvenient secret: Large applications are large. The optimal implementation of a large application will always be more complex than the optimal representation of a smaller app. We cannot make this go away. What we can do is to organize a codebase in a way that "scales logarithmically". Twice as many models should not mean twice as many problems.

Here is a chart that we made up:

Vanilla Rails vs. structured Rails

In order to walk the green line in the chart above, you don't necessarily need to change the way your application is built. You don't necessarily need to introduce revolutionary architectures to your code. You can probably make it with the tools built into Rails, if you use them in a smarter way.

Compare this to sorting algorithms. When a sorting function is too slow, our first thought is not "install a Hadoop cluster". Instead we simply look for an algorithm that scales better. In a similar fashion this book is not about revolutionary design patterns or magic gems that make all your problems go away. Instead we will show how to use discipline, consistency and organization to make your application grow more gently.

We have three principles that guide our design decisions:

1. Be boring

We have a universally applicable default design that maps any user-faced interaction to CRUD and ActiveModel. By being consistent in your design decisions we can reduce the cognitive overhead required to follow your code. This makes it easier for colleagues and new developers to navigate and change our source.

Read about this principle in the following sections:

  • Why controllers should be boring
  • Using ActiveRecord effectively
  • User-facing models without a database: ActiveModel
  • Taming style sheets

2. Be organized

We organize code in a way that encourages the creation of new classes. By isolating screen-specific concerns from a slim core model we can reduce the side effects that models can have on other parts of your application.

Read about this principle in the following sections:

  • Dealing with fat models
  • Taming style sheets
  • Taming javascripts
  • Organizing large codebases using namespaces
  • Don't let authorization infect your application

3. Be humble

Where we suggest using before/after code comparisons to avoid being sidetracked by the design fad of the day. We will make a case for adopting new technologies and patterns with care, and take full responsibility for those techniques and technologies you do choose to adopt.

  • How to test effectively
  • Hipster Patterns
  • Owning your stack
  • Surviving the upgrade pace of Rails

Are you interested in this book?

We're currently finishing up the final chapters. Growing Rails Applications in Practice will be released this summer. If you're interested in the book, please enter your e-mail address into our notification form. We will let you know as soon as we publish!

Recent posts

Our address:
makandra GmbH
Werner-von-Siemens-Str. 6
86159 Augsburg
Germany
Contact us:
+49 821 58866 180
info@makandra.de
Commercial register court:
Augsburg Municipal Court
Register number:
HRB 24202
Sales tax identification number:
DE243555898
Chief executive officers:
Henning Koch
Thomas Eisenbarth