July 31st, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
The real problem with Devise commandeering all these components is that it makes the system extremely rigid. If the business logic changes (and yes, it will change) in a way that affects user sign-in or account creation, the developer is limited to modifying the app within the constraints of Devise. The developers behind Devise may not have anticipated a situation quite like yours, so getting Devise to work with the new process might be extremely difficult. Specifically, it will require clunky overrides and awkward workarounds, because the code itself is of course hidden, packed in the gem. Thus, what can be a blessing (not having to worry about the gritty details involved in making an HTTP POST request) becomes a curse (not having access to the Users Controller to modify the login action).
I have worked with Devise. On the one hand, it does give the Ruby world a standard. Most of the CMSs include instructions on how to work with Devise. Also, you can override any part of it, though that can be a dangerous game where you start hacking the hell out of it to get some specific thing to work. When I’m in a hurry I find myself copying and pasting Devise code to new files in those folders that automatically override the defaults.
At this point, I think I would say, if you are facing a situation where you really need to write a lot of custom code, then write a lot of custom code. But those situations are rare. The vast bulk of programming today involves grabbing some libraries and gluing them together, quickly, for the sake of a client. If you are using Rails, then you are already using a vast blog of someone else’s code, so you should use Devise too. But if you really are writing everything from scratch, then indeed, writing a simple auth library is pretty simple.Source