On the project I’m currently working on we have a main portal that provides a user registration system and a generic billing mechanism. It also has several sub applications which need to know some information about the user and be able to publish billing events. With a fairly easy to articulate boundary, we thought it might make sense to be deliberate in how we organized our code – we came up with three main solutions:
- One big app, just use namespaces
- Create the portal and expose API endpoints over HTTP to get user data and set billing data.
- Create the portal, and have each sub application contained in a Rails Mountable Engine.
Our Boulder office had been making some noise about Rails Mountable Engines for some time, gave a presentation in the SF office, and I had experience working with engines both in the dark times of engines in Rails 2.x and the markedly improved days of Rails 3.x, and even better still in 3.1+. We had need to scale one sub-component of one of the applications independently, but not entire apps as the primary usage of the system would be low-volume. We set off down the engines path…
It worked pretty well. Two months in to the project we had a retrospective specifically about how engines were working. We agreed that we had felt some pain, but overall they drove out interesting decoupling and that the cost to pull them out could potentially outweigh the little pain we might encounter in the future.
Then our team size doubled. We had multiple epics that had high priority and deadlines associated with them. We also needed to ramp up four new people which led me to reassess our choice of engines once again, not to mention that we eventually will be handing over the code to developers who haven’t seen much Rails.
The conclusion I came to was that engines had to go. Here’s the list of why:
- Asset pipeline already feels magical, with engines you have to think even harder about what you’re doing and what to include in your application.js or application.scss.
- Testing. Writing an RSpec request spec didn’t make sense in the engines where certain styles were expected, or a specific layout – we found ourselves stubbing out a whole lot, or putting more and more into a gem that contained shared code between the portal and the engines.
- Running Tests – We had to have multiple instances of RubyMine open to get the correct load paths for the engine and the portal, constantly trying to remember “Is this in the shared gem, or in the engine?” or “Oh wait, this is specific to the engine, but it is a request spec so we need to go back to the portal to re-run that” was not unsolvable, but felt like a tax on our choice every time I fumbled.
- Migrations everywhere – You write the migration in the engine, then it has to be copied to the dummy app for testing, and also back up to the main app for running request specs, now you have three copies of the same migration, all with different timestamps. Not fun when you realize you also needed to change that string column to a text column.
- Everything still had to be namespaced anyway for the engines so we had the folder explosion we were trying to avoid from the One Big App solution.
- Confidence – It got to the point where I found myself asking “Is this broken because I wrote it wrong, or because there’s something I misunderstood about engines?”. I could never be sure of why something had gone wrong.
- Documentation – Rails Mountable Engines documentation is a small subset of the knowledge available on StackOverflow for example. If we want to make the ramp up and handoff as smooth as possible, we want to do the most vanilla thing possible so that things are intuitive or at least Googleable.
None of this was impossible, or even difficult to solve. It’s just that it wasn’t intuitive, not what a well seasoned Rails developer was expecting out of the box. It would have been a waste of our client’s time to bring a whole new team up to speed on all that we had learned about engines, rather than having one big application.
This is especially true since the only semi-real-payoff was that it made us isolate our sub-application code from the portal code. I say “semi-real” because the boundary was artificial – the reality was that the sub applications needed to know about the user and his account, and anything we built out for billing was really a dependency of each of the apps. This was different from a great engine like rails_admin that really is a drop in and has no domain-specific dependencies. Here we had nothing but domain-specific dependencies and now, by removing engines, our code and our domain are back where they belong: together.
Engines really are great and there’s lots of situations where they can be really powerful. Boulder Pivot, Stephan Hagemann, had these additional tips that I wanted to share with you.
Regarding RubyMine and running specs: there is a simple way to make RubyMine run all specs in all engines. It will make all engines modules with their own “RubMine root”, which fixes spec runs. https://blog.pivotal.io/users/shagemann/blog/articles/intellij-modules-in-rubymine-
Regarding migration duplication: You can have an engine or app that requires others run their migrations. Check out the migrations run by the main app in this sample app: https://github.com/shageman/the_next_big_thing
Regarding testing: If an engine is relying on some layout or style to be around, it should depend on it and include it (potentially by way of another engine).
About the Author