When Rails Engines Are the Wrong Tool
Rails Engines can introduce unnecessary complexity and coupling when used for simple separation of concerns. The article argues that plain Ruby classes, service objects, or gems are often better alternatives for modularizing Rails code.
Background
Rails Engines are a built-in feature of the Ruby on Rails web framework that lets developers package parts of an application as self-contained "mini-applications" (e.g., a blog engine or admin panel) that can be mounted inside a larger Rails app. They are commonly used to share code across projects or to modularize a monolith. However, they come with design trade-offs: engines inherit the parent app's full environment, which can lead to tight coupling, unexpected bugs from shared state, and difficulty testing in isolation. The article argues that in many cases — especially when the goal is clean separation or independent deployability — other patterns like service objects, gems (plain Ruby libraries), or microservices are better choices. The author draws on production experience to outline when engines create more problems than they solve.