Will Rails 3 obstruct plugin innovation?
One of the great things about Rails are the many gems and plugins that help you save time. With its comprehensive public API Rails offers a fertile breeding ground for all kinds of useful abstractions. It's one of the great success stories in plugin architecture, up there with Eclipse, Wordpress and others.
Some of that might change with Rails 3.
You see, a big theme for Rails 3 is framework agnosticism, meaning that you can take the ORM layer, templating engine or another component of Rails and replace it with a framework of your choice.
For the most part, this is awesome. We're already using RSpec, jQuery and Haml in lieu of the default Rails stack and it will be great to integrate those tools without the hacks that used to go with it.
But I'm not sure what will happen to the plugin ecosystem now that a plugin can no longer assume that ActiveRecord is handling the persistence. Where there was once a consistent API to manipulate and hook into the lifecycle of a persistent object, plugins must now perform very careful checks whether an object supports more advanced traits like transactions, observers or dirty attribute tracking.
Take the latest state_machine gem, which comes with adapters for four and a half persistence layers and selectively disables features depending on what ORM is available. While I applaud Aaron Pfeifer for going through the pain of writing all that scary integration glue, a lot of perfectly good code might not get published because the bar for being a good Rails plugin is now so much higher than it used to be.
You can follow any response to this post through the Atom feed.
I guess developers will just have to either do what they did before (have ActiveRecord-only code) and specify that, or write the glue if the users really, really want it.
It really seems like just more opportunity, but I can see where the scariness lies…
What you’ll probably see is what we’ve always seen in past versions of Rails: people will build their plugins on top of ActiveRecord since it’s still the default in the current rails generator.
That’s my opinion anyway.
This is a really interesting perspective of how Rails 3 affects plugin developers. Thanks for writing this up. However, I think part of the issue with this reflection is that many plugins (most commonly, those of the acts_as_* type) have been historically misconstrued as “Rails” plugins. I think the truth is that they were never Rails plugins to begin with… they were ActiveRecord plugins.
Pluings that integrate with the whole stack (mvc) could be viewed the same way. They’re just ActiveRecord plugins with a integration point for Rails.
If you look at the world from this perspective, then Rails 3 hasn’t really changed anything. I think this is the perspective you’ll find in ORMs like DataMapper. Even though Merb apps commonly use DataMapper, plugins that provided additional model support were always just DataMapper plugins, not Merb plugins.
As you mention, some folks like myself aren’t content with just having one slice of the pie. We want it all, but that comes at the price of complexity. I would love to hear if someone has an easier way of maintaining these various integrations. Sometimes a good strategy is to provide a “core” plugin, and then allow each ORM community to maintain its integration with that core. At least then the complexity is distributed.
But to get back to the main point, I don’t think Rails 3 will obstruct plugin innovation. I think it just makes it clearer what was never a Rails plugin to begin with…. if that makes any sense :)
I have to hope that the “scratch your own itch” ethos that has made the open source world what it is today will simply continue. With any luck, the new tradition of free-er forking and patching will help to fill the gaps with glue, as it were.
Don’t worry. The bar will simply get lower: less determined plugin authors will simply assume their favourite components – which is pretty much what they already do. If such a plugin is any good, it will either be patched or plagiarised by someone else to work in a different setup. An intermediate possibility (likely to be very common in practice) is that authors who care but can’t be bothered will provide adapter interfaces but only ship one or two adapters with their plugin themselves (with other people then contributing or separately distributing adapters to their own favourite stuff).
This is what Catalyst-land looks like, anyway.
Overall it’s going to cause some splintering, but not in a bad way.
(I never bought DHH’s marketing on this issue.)
This is a big reason we have Active Model though. Theoretically the library behind it shouldn’t matter all that much; most plugins only need the external API’s that it provides. If you need something more specific, I’d recommend following the pattern of something like CarrierWave and having a file you can require for each ORM’s functionality.
Won’t somebody just write a plugin that sits between your plugin and your rails and figures out what ORM to use?
@All: Thank you for your wonderful comments.
@Jake: There are limits to what you can abstract away. You cannot make all persistence layers behave the same because some have inherently different approaches to O/R mapping.