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:

• Ecto schemas
• Postgres datalayer w/ migration generation
• Attribute and schema-based multi-tenancy (including DB migration tooling!)
• CSV datalayer
• ETS datalayer
• Internal Elixir API (w/ pagination, sorting, filtering)
• JSON API (w/ pagination, sorting, filtering)
• GraphQL API (w/ pagination, sorting, filtering)
• Calculated fields (supporting sorting and filtering)
• Aggregate fields (supporting sorting and filtering)
• Dead-simple soft-delete
• Custom validations, can be action-specific
• Can join relationships across different datalayer types (e.g. CSV & postgres – uses dataloader pattern for efficiency)
• Very smart notifications for PubSub, and custom stuff like Emails
• Powerful authorization policies that work w/ Internal, JSON and GraphQL APIs (has an expression language)
• You can set authorization rules on an API like:

  # 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
  

• Phoenix tooling w/ incredibly powerful and simple API for dealing w/ nested forms.
• A (new) authentication extension (customizable) as an alternative to phx.gen.auth
• Many of these features have strong compile-time validations for config
• DSL formatter, customizable so you can pick the order of the DSL sections!
• Elixir LS integration – does lots of smart auto-complete!
• Any extension you want to write on your own

I’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.

I just wanted to jump in here and give a shout out to @zachdaniel

I recently decided to try Ash on a section of an app that I’m working on and ran into a snag with a calculated field on an embedded resource. I joined the Ash Framework Discord and posted my problem to the support forum. Zach replied within a few seconds (and I do mean seconds). After a short discussion he determined it was a bug and had it fixed in the main branch for me to test. Unbelievable!

So yeah, I just wanted to echo what others have said. Zach is very responsive to support questions etc.

Great work Zach! Thank you!

For those looking for some concrete examples, part 2 of the LiveView Mastery collab video does a feature review to show various features of Ash in action. https://youtu.be/pwxShYmJgkk