I haven’t tried Ash but reading the docs it looks similar to Lucky Framework for Crystal.
A lot of macros and remembering the right incantation instead of working with primitives. What happens if I have to go off the beaten path? That’s my main concern with trying to use Lucky and something like Ash.
Has anyone used it in prod for anything? What’s the day to daylike? Where can you cut yourself?
I am in the process of writing a new version of Schulferien Deutschland Webpage (a page with school vacations of some 40,000 German schools) with Ash. I like the whole idea of the clean DSL. It feels like a one stop shop to me. I only have to take care of one thing and get a lot of things for free (e.g. the RESTful JSON and the graphql API).
I hope so save a lot of time in future projects by using Ash. Right now I am not there yet. It is a bumpy ride. @zachdaniel is very responsive on Discord but I have trouble with some documentation.
Bottom line: I think Ash has the potential to become a game changer. Faster and more secure development.
If you don’t want to use ash_authentication then your best bet is to use mix phx.gen.auth and then adapt it to work with your resources. Alternatively, you can just use mix phx.gen.auth with ecto schemas and use the produced user as the “actor”.
I use it for a proprietary ERP we’re developing in house (LiveView and GraphQL API), and for numerous personal LiveView projects, some of which will eventually be open-sourced.
I’ve been using it for a few years, closely following the development. It is indeed a massive project, can be intimidating at first, but it’s not necessary to understand the full capability of the project to start leveraging it, and it’s certainly worthwhile!
Right off the bat, I have to say that the Discord community on the Ash server is very active, several devs that use it in prod keep an eye on things and jump in w/ help in addition to Zach. There’s lots of help if you get stuck or aren’t sure how to do something in Ash.
Very hard to do an elevator pitch, but here’s an attempt:
Instead of working with tooling (like Ecto, Absinthe) directly, you define resources with a DSL.
A resource is both a definition for a struct of data, as well as a place to configure all extensions for that data (APIs, auth policies, DB config, etc.). A short list of polished, official extensions/features you get (opt-in) out of the box:
# This prevents the footgun of forgetting to authorize an API call.
# To bypass authz, you will have to explicitly set authorize?: false in the call.
# Other options are available to fit your requirements.
authorization do
authorize :by_default
require_actor? true
end
phx.gen.authI’d compare it to Tailwind in a way: It has patterns and tooling that can be easily used to create bespoke apps. It creates a tremendous amount of consistency across your app and API, and allows you add features later that don’t break your API. For example, if you start out without using authorization, pagination, filtering or sorting, then add it later, no problem! Those arguments are additional opts to pass, so you don’t break anything by enabling it later.
It’s hard to get a feel from examples in the docs, but it really does NOT nail you down to a formulaic CRUD pattern. You can have any number of actions. There are basic action types (:create, :read, :update, :destroy), but no limit on how many of each type, and they can have different args and/or accepted attributes. There are also tons of escape hatches that give you multiple levels of intervention if the OOTB options aren’t cutting it for your needs. For example, in API actions, you have access to before_action and after_action hooks to manipulate the changeset before it hits the DB, or you can do a fully manual action and handle persistence on your own. Another example, in calculated fields, you can use an expression syntax and even use SQL fragments:
calculations do
calculate :name_full,
:ci_string,
expr(
fragment(
"concat_ws(' ', ?, ?, ?, ?, ?)",
name_title,
name_first,
name_middle,
name_last,
name_suffix
)
)
end
As an example of how far you can go, I’ve been using my own extension that adds a user_interface section to the DSL which allows you to define how forms/tables/cards should be generated for LiveView (e.g. custom classes, how to group fields in forms, etc) and some smart components that can derive the forms based on what resource you pass it. I hope to open source this somewhat soon, BTW. 
This really just scratches the surface. There’s a ton to learn about Ash, but you can start very simple and build your knowledge/usage over time.
As an addendum to drive home the point that this is not like other frameworks w/ lock in, before settling on Ash, I tried and rejected:
Ash it far, far less restrictive than all of those options. (Which is of course not to cast shade on them – they’re pretty cool too, especially Postgraphile!) With each of those, I ended up feeling boxed in, not to mention they required the SPA route. With Ash, I’ve been able to develop for LiveView without feeling too boxed in, then later added in a GraphQL API very easily (just adding one section to the DSL and setting up the Absinthe entry point/routes) later for 3rd party use
I’m thinking of writing a commenting system with LiveView or LiveState with Ash for fun and for my blog (mainly for fun. There are already very good options available in this space like isso)
We started using Ash right around the time the 2.0 Release hit. To be honest, I was quite sceptic at first. After using NestJS in Node for the backend before, I did not want to have a Framework that would make it hard to do things differently than the Framework creator had envisioned.
But Ash allowed us to get started really fast, just declaring our Resources and exposing them, using AshGraphql. The Support I received in Discord was immensely helpful and often made my day at work.
After Starting with writing your own actions/changes/calculations to keep the code clean, you can go further into extensions and data layers later on, giving you a lot of potential to extract out common functionality and separate those by concern. The way Ash works, it was always possible to jump in at some point in the process and do additional work or just do some custom work with ash still handling stuff like argument validation for you.
So far, Ash has helped us greatly with reducing boring work, while not feeling restrictive in how you can do things.
10/10 would recommend 
If you’re wanting to see examples of the compile-time validations, you can check the Ash Core source. Right here are a few files named validate_*, those are some of the post-DSL-compile checks, in this folder specifically for relationship configs. E.g. for relationships, it checks that the specified related resource exists, and that it has the attributes expected/specified, etc.
If you want examples of using Ash, Todoish and the AshHQ are the best I can think of off the top of my head.