Documenting the happy path for implementation via Rails engines #361

A note - when I was working on this at Shopify, we didn't make all packages engines. We had lots of packages that just followed the existing file path structure, often because namespacing was already in place and we just dropped in a package.yml file.

We had a special kind of package that we called component; these would generally be pretty large, top level, and represent bounded contexts (from Domain Driven Design). Only these were structured like Rails applications and thus engines.

I do find the notion of nested engines as explored by @pinzonjulian in the linked talk interesting, however we didn't do that back then (might be different now, I am no longer at Shopify). IMO in the interest of simplicity it doesn't really make sense to force rails application structure for all packages, especially nested ones.

This makes sense, in my corner our monolith was all "components" and thus all engines so that's all I saw

@pinzonjulian it was pretty impressive to see you reverse engineer some of what I experienced while I was at Shopify from the outside.

I've been sure to share your talk several times in my new company. As folks work on modularizing their applications, there's a lot they can learn from and lean into, but I think the guidance your talk sets out sets the framework for a delightful experience building sustainable, large Rails application, once you're organically feeling those pain points.

In my opinion, Rails' plugin generator is not the right tool for the job because it was built for a different use case in mind. As I mention in my talk, it generates more than 80 files that are not necessary to get you started. With a couple of folders and a single class inheriting from Rails::Engine you should be good to go.

I go back and forth on this. Because it's documented by Rails I find it easy to opt into this and then delete what you know you need to get rid of. That feels like a more sane path for the majority of folks and it that can then be automated if you're in the process of defining several packages in relatively short succession.

This also assumes the package is a Ruby Gem which as I explored in the talk, it's not necessary. An engine can start as a simple code organisation tool and progress into more complex areas as needed like becoming a gem and managing its own dependencies. Again, not necessary for a simple split.

Your talk does a good job at demonstrating what can be optional here 👍 Even for more complex splits, I can see the benefit more clearly after going through that exercise.

I'm not sure I understand this question. Is this about when to split your monolith into an engine or is it about when should you consider an engine vs a package (i.e. folder with a package.yml in it)?

The latter.

This is objectively probably a tangential question. I am personally pretty weary of some of the advocacy for deconstructing into tiny packages. My only experience in delightful modular Rails apps comes from seeing the majority (if not all) packages as components/.

In many cases the lightweight engine approach you've demoed feels lean enough, while leaning into Rails conventions. So it's hard for me to fully wrap my head around the goldilocks package that fits in between being small enough to define something in a module with a couple of classes vs a lean Rails engine.