Very cool to see usage_rules mentioned in the blog. That tool is such a great idea, and leveraging that for Ash development has made a drastic improvement in LLM development for me. Excited to see that get more adoption across the Elixir ecosystem.
Many nice improvements, but I am a little saddened by the move to magic link logins in the auth generator.
I realise magic link login is in vogue, but it is necessarily going to be a short-lived fad. On the user side, it breaks password managers and is generally a janky and obnoxious user experience.[0] On the dev side, it adds a third-party service dependency by way of an email provider - a needless barrier/expense for beginners and makers of small scale apps, who tend to be the audience for an auth generator in the first place.
Honestly, I'm unsure who the audience for the new auth generator is supposed to be. I'm trying to picture someone who has simple enough needs to be happy with a local users table, but then wants all the complexity of handling login via email; who doesn't want to use an auth library, and doesn't want to write auth code either, but does want the responsibility for maintaining auth.. It seems like a fairly idiosyncratic stance.
I'm a big fan of the move away from implicit layouts though, as well as the simplified core components.
[0] Not to mention the whiff of data harvesting, a perception that is only going to get worse by association. Do you want your product to have the feeling of a shady restaurant booking app that is almost certainly selling those emails?
> it adds a third-party service dependency by way of an email provider
Account verification and password recovery requires email provider, so it's a Rube Goldberg machine, may as well to reduce it magic link logins assuming a long enough "remember me" sessions.
https://hexdocs.pm/usage_rules/readme.html
Is there a struggle when using Ash between the "Phoenix Way" (gen.auth, scopes) and eg AshAuthentication? Ecto vs Ash.Query?
I realise magic link login is in vogue, but it is necessarily going to be a short-lived fad. On the user side, it breaks password managers and is generally a janky and obnoxious user experience.[0] On the dev side, it adds a third-party service dependency by way of an email provider - a needless barrier/expense for beginners and makers of small scale apps, who tend to be the audience for an auth generator in the first place.
Honestly, I'm unsure who the audience for the new auth generator is supposed to be. I'm trying to picture someone who has simple enough needs to be happy with a local users table, but then wants all the complexity of handling login via email; who doesn't want to use an auth library, and doesn't want to write auth code either, but does want the responsibility for maintaining auth.. It seems like a fairly idiosyncratic stance.
I'm a big fan of the move away from implicit layouts though, as well as the simplified core components.
[0] Not to mention the whiff of data harvesting, a perception that is only going to get worse by association. Do you want your product to have the feeling of a shady restaurant booking app that is almost certainly selling those emails?
Account verification and password recovery requires email provider, so it's a Rube Goldberg machine, may as well to reduce it magic link logins assuming a long enough "remember me" sessions.