External submodule architecture

[anthonator]

For my own edification I was hoping to get a rundown on why the external submodule was developed the way it was. I've always been confused as to why sorcery opted to create it's own external submodule system rather than integrating with OmniAuth. I know this project was inspired by OmniAuth and I'm curious why that work wasn't leveraged. Whenever I make an attempt to use sorcery's external submodule I always end up scrapping it in favor of OmniAuth.

This isn't meant to be a criticism. I'm genuinely interested in why this decision was made.

[arnvald]

I guess only @NoamB can answer this question :)

[NoamB]

Hi, At the time I watched tenderlove's Railsconf video saying the reason Rails was slow was too much layers of middleware. I then saw Omnioauth's architecture was one that used Rack middleware, 1 layer per provider you wanted active. So, maybe optimising prematurely (which is the root of all evil they say), I tried to take Omniauth's work (for Twitter & Facebook initially) and put it in a way which doesn't inflate the stack.

So yeah, we basically need to duplicate each provider into sorcery for saving a few ms... patches are always considered though ;-)

Why do you end up scrapping it though, is more interesting, pragmatically speaking. What is the problem with the current implementation?

[fschwahn]

Hi, I was feeling similar to @anthonator so here are my thoughts:

• sorcery is all about minimalism, and duplicating this code from omniauth seems like bloat. Personally I'm not convinced that performance gains are worth the duplication. (Of course this depends on how big these gains actually are)
• omniauth seems to be the standard in ruby-land for authentication through external services (e.g. devise also uses it for external auth). That means it is very well tested in production, and also quickly patched in case of security issues. (e.g. omniauth-facebook has received regular security updates in the past, the last one 2 weeks ago)
• A plethora of omniauth-providers exist, which all could be used if sorcery supported omniauth.
• It decouples the development of sorcery from the development of the providers. This is a good idea no matter if sorcery uses omniauth or continues with its own solution.

In fact I'm not currently a user of sorcery, but I was evaluating it, and I really like its approach, but the inclusion of the external module struck me as such an odd choice that I had to look up this issue and look for a reasoning :wink:

[NoamB]

It's definitely a good route to go - integrating Sorcery with Omniauth.

[musaffa]

The only thing that deters me from using sorcery is its lack of support for awesome omniauth gem. +1 for omniauth integration.