In my recent RailsConf talk I said that I would help out with questions regarding component-based Rails applications (#cbra). A few days ago I got one such question via twitter: How to make a unified admin tool for independent engines?. … Read more
I have previously written about how to use IntelliJ to set up multi-project support in RubyMine. I am happy to say that that hack is no longer necessary. Multi-project support was built into RubyMine 6! It makes component-based Ruby and … Read more
If you are using engines to break up your large Rails app, you might end up with a strange case where you cannot login for your capybara tests within individual engines. It sounds weird at first, but the engine your … Read more
If you’re using Rails engines to break up your app and you’re putting your migrations in the engines, then you’re already doing great! Here’s an additional pro-tip when it comes to having migrations within your engines: only allow each migration … Read more
We have been developing gems a lot as part of giving more structure to Rails applications: the idea and some techniques. Doing this often sees a Rails application and one or more gems being developed at the same time. This … Read more
Let’s look at a simple approach to parallelizing a test suite for a Ruby app. Parallelizing your specs can be a good strategy to get a speedup on an existing slow suite. It can also be employed early on a … Read more
If you are using Rails engines to break up a single app into modular pieces, migrations (as they are currently implemented in Rails 3.2.13) become clumsy.
There are three options for migrations within an engine (spoiler: #3 is the best):… Read more
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...
We moved a Rails app into an unbuilt engine of a new blank slate container app to allow new parts of our app to live next to it as engines as well. It has been working great for us!
I have a sample app rails_container_and_engines of the result's structure on github.
Skip to the pitfalls and discoveries section to read about some of the speed bumps we during our transition. Interested in the why and how? Read on!
IntelliJ has a feature called modules: "a functional unit which you can compile, run, test and debug independently."
A module in IntelliJ is a top-level view on a part of a codebase. IntelliJ is for Java, which is why I do not typically use it. I use Rubymine - no similar functionality exists here... but a way around that!