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.
A bit late but it’s been fantastic so far. I’m using it for a GraphQL backend so I haven’t tried with LiveView yet but I don’t think it’ll differ too much. I know Ash has their own changesets which might be a bit different, but can’t say for sure.
In general Ash has a rough learning curve, but it helps a LOT for what I think Phoenix is missing or isn’t opinionated about which is the context layer. Ash basically builds that for you, and probably better and more secure than you can do yourself.
The way I see it, a LiveView to display data might do something like MyContext.fetch_items(scope: socket.assigns.scope). All Ash does is derive those functions for you. So maybe you have MyDomain.fetch_items(actor: socket.assigns.user)
But then if you want filtering, sorting, etc that’s all there for you, while you’d have to build that yourself with Ecto. But then did you remember to filter your joins to only retrieve the items the user is authorized to see? Sure, you can do that in Ecto, but it’s kinda just built in with Ash policies.
I hope that helps - Ash doesn’t replace anything that Phoenix or LiveView offer (except maybe changesets are slightly different), it very much builds on top of it.
Edit to add, Ash is built on top of Ecto. The escape hatches are there, and easily accessed if needed. Ash.Query is very powerful and I haven’t needed any escape hatches on a small to medium sized project so far.
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