The little engine that could

Part I: motivation (leaving the station)

A few months ago, we started the process of moving the Prevent registration flow into a Rails engine.

An engine allows you to slice off a “vertical” chunk of your application — in our case, the logic and presentation related to user signup. The code still lives in the main codebase, but it communicates with the main app like a separate app would. It can’t reach into the main code in sneaky ways; you can see more clearly where communication between the two pieces happens. You can test the engine separately from the main app.

From the start, we thought of this as an experiment. Try it, evaluate it, refactor it. Deciding when and how to break up a big app can be weighty, so I’d like to discuss several factors that motivated us.

Coming soon: posts about the code, the process, the highs and lows. Gripping stuff.

Why split up the app?

• The tests were taking a while to run. Enough to disrupt the flow of development. We already attack this problem in creative ways. As the code leaves, so can the tests, as long as we integration test appropriately (more on that later).
• Coupling in the app led to bugs and difficulty refactoring. As with the test duration, the app “felt” too big.
• We expect significant increases in both usage and complexity of the app over the next year. If it weren’t going to be heavily used and actively developed, we’d leave the darn thing alone ☺
• SOA, where appropriate. We like manageably sized apps with clear responsibilities and consistent communication. We do have other services, but those were built outside of our main app from the start. This is our first attempt to splinter the big ‘un itself.

Why the registration flow?

• The seam was easy to conceptualize. It was simple to visualize which parts of the app would fall into the engine. The interface was straightforward — a small set of data would be sent to the main app and used to create an account.
• The code we’d break off seemed roughly the right amount. That is, enough to make a difference, but hopefully not so much that we’d throw up our hands and decide that a monster app wasn’t so bad after all.
• Source-agnostic account creation in the main app. We will eventually populate account data from multiple sources, i.e. doctor referrals or EHR integrations, not just the one application flow.

Why use a Rails engine?

• Splitting our app “vertically” addresses the effect of coupling and complexity on feature velocity. We don’t immediately face the problems “horizontal” splits solve, such as allowing developer specialization or targeting performance bottlenecks.
• Rails engines enable incremental experimentation. We could have jumped straight to registration as a separate app, but the scale of flipping that switch on a live app was daunting. Change should be as incremental as possible — get that sh*t into master.

Also, it sounded like fun!

Next up: getting the ball rolling. You like code snippets? I’ll getcha some code snippets.