3 ms·
I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a
by bphogan 11y ago
I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a very websocket-heavy app I'm building.
I switched to Elixir and Phoenix last year and got the core of my app working.
It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)
- prapam2 11y agoBut you woudn't need gems to for recovery emails right?
- pmontra 11y agoThe Devise gem does that for free. I remember me coding it in my first Rails application so many years ago and I'm not keen to go back to it: it feels like wasted time. Phoenix didn't have it one year ago and it's sad to learn that it doesn't have it yet. Somebody will write it sooner or later because it's almost core functionality of a registration and authentication system.
- prapam2 11y agoIts actually pretty simple to implement on your own. I am not big of device. I feel it does too much magic. It should have been just a api layer and not touching views.
- bphogan 11y agoIt's simple to write a password-based auth system. Then you must clear session appropriately. Then you must create the login page. Then the controller for authenticating. And then you need to ensure that the flow works with a test. Then you need the email that actually activates the account, with the activation hash. So now you're setting up a mailer system, which Phoenix does not have by default. Then people will want to recover passwords. So you need to write the logic for that. Oh, and the controllers and views. And routes. And of course, you need to hash the password using some kind of encryption. Excrypt, comeonin, what have you. Choices choices choices. You'll need a plug to act as the bouncer for your routes too, so nobody gets in where they shouldn't. So you'll have to write that. You have to end-to-end test this, of course. And probably, if your business depends on it, get a couple other people to review the security of your system. Simple. And takes a long time. HTTP is pretty simple, but we use frameworks. SQL is pretty simple too, but we use Ecto now. It's simple in its pieces, but I really don't wanna do all that work on every app. I'm lazy.