Make each provider a separate gem (call for feedback)

[mbleigh]

Hello out there OmniAuth land, I am considering a pretty major revision in how OmniAuth works for version 1.0 and I wanted to write up a little about it and call for some feedback before I start going down this path. When it started, OmniAuth connected to about 12 providers, most of which I wrote myself. Since then thanks to all you amazing people it has grown to what, 50+ now? While that is absolutely amazing to see, it has become a little...um...daunting to maintain the individual strategies these days. It's hard to justify a patch release of OmniAuth just for a fix in a single gem, and it's generally becoming a more and more difficult situation to maintain. So here's my proposal: the omniauth gem becomes what oa-core is now, and every single other provider becomes a separate gem. No exceptions.

How the New System Would Work

The ominauth gem would simply be a convenient set of helpers to build Rack authentication middlewares. Everything else, and I mean everything else, would simply be an OmniAuth-compatible extension.

I would continue to maintain some gems, off the top of my head these would be:

• omniauth
• oa-oauth
• oa-oauth2
• oa-identity
• oa-openid
• oa-twitter

So instead of having everything in one kitchen sink, you would have to specify each of the gems you wanted to use. Let's say I want Facebook, Twitter, and Google (via OpenID), my Gemfile would look like:

gem 'oa-twitter'
gem 'oa-facebook'
gem 'oa-openid'

From a code perspective nothing would really change. It would still auto-detect providers by class name, still provide all the same strategy hooks, it'd just be separating out the code.

Versioning

One problem that's likely to come up in a massive split like this is: how will the versioning work? Once we hit 1.0 OmniAuth will be using strict semantic versioning, meaning that ANY breaking change to the public API will bump up the major version, any added API functionality will bump up the minor version, and bugfixes will bump the patch version. OmniAuth extensions do not have to follow the same versioning as the master gem, but they DO need to properly declare a dependency, namely:

gem.add_dependency 'omniauth', '~> 1.0'

This declaration means that the gem needs a version of OmniAuth with 1.0-compatible API. It will accept OmniAuth up 1.x but nothing higher. In this way gems can always be sure to function properly with OmniAuth and any dependency problems can be easily resolved.

Reasoning

Why would I want to do this? Maintainability, as I said above, but also because it's been hard-nigh-impossible to get OmniAuth to a decent state of testability because there are simply too many things to retroactively write tests. 1.0.0 will include only well-tested code and any gems that I continue to maintain will also have the same strict testing regimen. By moving to this method of doing things, I can ensure that the core OmniAuth experience remains as solid and bug-free as possible.

Another reason is to give new strategies faster-to-market timing. You can just build and release a gem all on your own without the need for an accepted pull request or anything else but your own elbow grease. I'm hoping this will cause the community and available strategies to grow even more. There will be an official wiki page maintained that will point to all of the supported strategies so that it's easy to find what is and isn't supported.

So what do you think? Is this the right move for the future of OmniAuth? I'm generally OK doing my own thing but this is going to be a massive undertaking and I'd like to know that the community is behind it before I start writing code for it.

[jm]

From a user standpoint, no, but if it'd make it easier to crank out newer features/strategies for you then I say go for it. I'll be using it either way. :)

[tsmango]

Yes, I say go for it. I think this is a smart decision. If a provider's API changes, it doesn't make sense for OmniAuth itself to be updated. And like you said, it lowers the barrier for releasing a gem to support a new provider.

[jc00ke]

I think OA is well suited to being broken up by providers. If you think about it it's kinda crazy that I have to pull down all those providers when I might only need a few. That being said, it might be reasonable to have a meta-gem so I can just say gem 'oa-all' in my Gemfile instead of listing them all out should I want them all. That would make the Gemfile way too messy for most.

[srbiv]

I think this is a good idea. I was a little surprised when I found out all the strategies were a part of omniauth. I was even more surprised with how quickly you guys have been pulling the new strategies in ;) Keep up the good work!

[mbleigh]

All right honestly I was mostly just posting this ticket to write down my own thoughts and by the end I had convinced myself. Ladies and gentleman, the future of OmniAuth is lots of independent gems. If only implementing that were as easy as declaring it...

[rurounijones]

I am definitely in favour of this one because it makes things easier for people needing to use :git versions of things in the Gemfile and those who only want 1 or 2 strategies.

The only concern I have is that by splitting them out and letting anyone create an oa-* gem you lose the quality control aspect you have now.

Maybe having some sort of page somewhere with "These strategies have the official approval of the omniauth core team" listing. Requirements for that blessing would be good source code, tests and (especially) the developer being signed up to some sort of omniauth-developers mailing list so that they know about updates to omniauth that may affect their gem and require them updating it.

Other developers can check if the strategy they want to use is approved or not and then make the relative risk assessments. oa-* gem developers can still quickly get gems out and downloadable and can then do any needed work to get on the list

it is a bit bureaucratic I know but every project I have ever seen that allowed user plugins without some sort of central authority ends up in confusion with "Does this plugin work with core version 1.2? What about Plugin Y, The last update was 3 months ago and it is broken I think but I am not getting responses from the developer and I need it to work with core trunk". Out of date plugins are the bane of my existence in projects that use them.

[sferik]

I am a huge supporter of this move. The current number of authentication strategies is a nightmare to maintain and it's only growing.

I makes a lot more sense for each strategy to be maintained by someone who is actually using it, as opposed to the current, centralized model.

Regarding, @rurounijones's concern, I'm not worried about code quality. If anything, this will lead to higher quality code, since it allows for competition between implementations. This may be a bit more confusing at first, but eventually the best strategy will win out, which should lead to a very healthy OmniAuth ecosystem, similar to the Rails ecosystem.

I would be in favor of having an official wiki page that lists all the omniauth strategies so that they're easy to find. Or perhaps we could use the RubyGems.org API to find all the gems that begin with oa-.

[tanguyantoine]

Can we use "twitter" gem?

[richardkmichael]

I just created an issue in one of my own projects to earmark investigating this, so although I can't comment on the implementation, it's a big +1 from me. :-)

I would just add that I think the component gems should be named: "omniauth-*". This makes all omniauth-related gems quickly scannable when you're reading, e.g. sorts them nicely in gem command output, makes the Gemfile clear, etc.. It also helps to avoid confusion about the "oa" acronym for newcomers - is "oa", "omniauth" or "oauth", etc..

[ballantyne]

+1

[cviedmai]

+1

how long do you think it will to take this into something usable? I say this because I'm about to build something new and I wonder if I should just wait a few days to use the new system or you think it will take months.

thanks !

[mbleigh]

@cviedmai it's probably worth it to use the old system. It's going to be at least a few weeks more than likely.

[jamiew]

This is a great idea

[eric-hu]

I want to second the suggestion @richardkmichael put forward. omniauth-facebook is obviously connected to omniauth whereas oa-facebook is a little ambiguous. For someone unfamiliar with omniauth, it'll be slightly easier to understand a (Rails) project's dependencies when looking at a gemfile.

[sferik]

👍 for more verbose/less ambiguous gem names.

[mbleigh]

I'm on board with that. It's longer but more clear, which sounds pretty Rubyish. :)

Now if only I had time to actually get some progress made on 1.0...

[mbleigh]

This is happening and master no longer has all the strategies piled on. Closing.