Apparently, engines are still evil

“Yes, I know you’d like to have an authentication system without doing any work. Yes, I know Rails preaches convention over configuration. This is not a place where it applies. This is, as we say back in the hood, “too much software”. It’s also a nasty hack that breaks every new version of Rails because it hooks into internals that aren’t publicly supported. These are akin to scaffolding. You’ll be happier without them.” original article

Sigh. Unfortunately, this is just another reflection of what seems to be the ‘cool loner building web 2.0 apps’ mindset. Yes, engines are basically scaffolding, but they’re maintainable scaffolding you build yourself for use in your collection applications. The power of engines doesn’t lie in being a ‘one-size-fits-all’ authentication system (engines does not imply some ‘heavy authentication stack’, please!), but in letting you be smarter about what code you don’t want to write again and again.

If you’re writing self-contained, independent applications then the implementation in a particular engine that someone else wrote may very well not the right fit for you. If you have to maintain several mostly-identical applications simultaneously, writing your own engines might save you considerable time and some heartache.

Anyway, there are two points Kevin is making here, which I’ll address below.

Engines are too much software?

There’s no reason why you can’t be sharing a personalised version of auth-du-jour plugin acts_as_authenticated as an engine, with not a single line of code more that you’d be generating if you used it ‘normally’. Where the extra weight would come from, I’ve no idea. For certain styles of development, clearly-defined application aspects like authentication (or reporting, or data management, or whatever) can be much easier to maintain if the code isn’t mixed through your application via a generator (which is, incidentally, what acts_as_authenticated is). YMMV.

The mechanism by which code is packaged barely correlates to how ‘much’ software it is. But if that’s your bag, then engines and plugins are demonstrably ‘lighter’ than generated solutions, since they are pure code and don’t carry any template payload along for the ride.

The quality of the code being shared doesn’t relate to whether or not it’s in a plugin, engine or generator. The login engine, for example, is based on the Salted Hash Login Generator, simply because that was the best example around at that time we needed an example to illustrate what engines could do. Sure, acts_as_authenticated might be a cleaner implementation, but that doesn’t automatically mean that plugins-carrying-generators are always a better way to share code than engines, in particular when you’re sharing code with yourself.

Engines are a nasty hack?

Rails is full of opinions, but the beauty of Ruby means that you don’t always have to agree with them. Certainly, the engines plugin modifies the Rails core in a few subtle ways, but the reason why it ‘breaks’ is simply because Rails itself is changing fairly dramatically. If you need to live on the bleeding edge of Rails, then you’re suffering at the whim of the most recent maintainabnle, and you’re going to have to live with their opinions as they change. If you can hold back and update to official releases in a timely fashion (i.e. within 24 hours), then you’re highly unlikely to have problems using the engines plugin. We’ve got a good community of developers supplying feedback and testing on our behalf too.

The ’authentication debate’ isn’t limited to engines, but spans all the mechanisms Rails has for sharing code. Whether developers are opting to use plugins, generators or engines to just ‘drop in’ authentication, the real issue here remains - developers need to understand any code they bring into their application from an external source. Of all the mechanisms available, I’d agree that engines makes it easiest for bad developers to ignore what’s going on in the code, but the blame lies with those developers, not with the mechanism.

Sigh (again)

This debate is really tired, so here is my plea. If this is what it takes for folks to understand the difference between a particular engine and the engines mechanism, then I’m happy to say it: please don’t use the Login Engine. I renounce it! It’s only as good as the original Salted Hash Login Generator, and yes, times have moved on. Just don’t confuse a particular authentication system with a technique for sharing code amongst your applications, m’kay?

Developers are lazy, and want stuff for free. Please, do look at example authentication systems. Tear them apart. Add bits, remove bits. Then write your own. If you’re going to need to use it a few times, maybe making it an engine so you can reuse it is a good idea. That’s up to you to decide for yourself.