Structuring Rails applications: the Modular Monorepo Monolith

Updated . Posted . Visible to the public. Deprecated.

The experience of Evil Martians discouraged us and we're not pursuing this approach any more. See their engems tool.

Root Insurance runs their application as a monolithic Rails application – but they've modularized it inside its repository. Here is their approach in summary:

Strategy

  • Keep all code in a single repository (monorepo)
  • Have a Rails Engine for each logical component instead of writing a single big Rails Application
  • Build database-independent components as gems
  • Thus: gems/ and engines/ directories instead of app/
  • Define a dependency graph of components. It should have few edges.
  • Gems and Engines can be extracted easier once necessary.

Advantages over a classic Rails monolith

  • By (automatically) only requiring expected/allowed dependencies in tests, components cannot accidentally use (i.e. depend on) code they're not allowed to
  • Onboarding is easier because of the clear separation and dependencies. No need to know the whole application.
  • Faster test runs, because only dependent components need to run.
  • A growing team can still keep up the development pace because developers concentrate on specific components. Merge requests target a specific component.

Advantages over a distributed application setup (multiple repositories, multiple applications)

  • Everything is still deployed at once. No need to orchestrate branch merges and deploys across N repos.

Other resources

  • https://www.airpair.com/ruby-on-rails/posts/ruby-on-rails-the-modular-way
  • https://engineering.gusto.com/building-toward-a-modular-monolith
  • https://railsconf.com/2020/video/vladimir-dementyev-between-monoliths-and-microservices
Dominik Schöler
Last edit
Dominik Schöler
License
Source code in this card is licensed under the MIT License.
Posted by Dominik Schöler to makandra dev (2020-02-13 07:36)