Moving to ElixirForum just benefited me. I googled elixir ash registry to understand what it is and if I still need it (I ended up with it from an example somewhere). The top result was this excellent question and answer Ash: when to use Registry, and what are the advantages?

That’s an excellent post @dblack and really shows how the tagline of Ash is realized.

With the new Ash liveview generator, even the index, form and show components will be drafted. The index/lists are also fully streamed with pagination supported in the domain model.

But what was most amazing is the Ash Phoenix integration also ensures every liveview state is truely live with what’s committed in the data layer using pubsub notifications based on successful transaction notifications. This leverages another Ash domain model feature to only send notifications on transaction completion so you avoid half baked state in your views with complex transactions which may fail, including transactions that occur across multiple data layer types (think a mix of ETS, Postgres and some external API).

Then we get into the Ash query engine that plans out and pushes queries down to heterogeneous data layers including joining across these layers and doing so in a smart way to preserve observability constraints defined by access policy using it’s SAT solver to make it efficient. e.g. it wouldn’t make sense to query all items on an external API and then join those IDs against a local Postgres table, return the results and only then restrict to what you’re allowed to do. For one, aggregates and calculations will be wrong also and we want those pushed down to the datalayer where possible. For example, if you have an access policy rule that limits observability to only items you created or have contributor role for the Ash SAT solver will determine an efficient means to answer the question.

Most of the drudgery taken care of for ambitious applications.

Ash is truely is on a another level of thoughtful and purposeful design, @zachdaniel has really done some amazing work the Ash Framework.

One of the things with Ash is that you can just start using it for any of your application resources on a progressive basis and seamlessly coexist with all your existing non ash code.

The Ash approach to surfacing resource actions to what they call an “Api” is akin to a phoneix context, so it’s easy to just target some resource in your application and try it out.

I really do enjoy expressing my domain model and getting so much value for such little effort, at first it feels like cheating and like many others, I can’t imagine doing it the long the way.

Question: Do you test the phoenix framework in your apps, or do you focus on testing for the code you write?

Question: what if you are writing far less code because you are using a DSL that does compile time checks and leverages a framework. Would you write tests to test the framework or focus on the just the code you write leaving more time for UI and end to end testing?

Once it clicks in your head, Ash does save a lot of “busy work” and low value drudgery, leaving more time for more important higher value outcomes. Like all things it does have some rough edges, but what doesn’t in open source? The important thing is that is works and is moving in the right direction with better documentation.

I think one of the understated cool things in Ash is the handling of nested resources via AshPhoenix.Form in liveviews. It eliviates many problems of the impedance mismatch between interactive forms and changesets which you can read all the glory details here. It’s a really good post on what you have to do to make a form with one to many work properly.

I love that LiveView form blog post, but as an Ash user I just had to demo the example using AshPhoenix.Form. Check it out here GitHub - totaltrash/form_example

This is exactly what we were hoping for. That is great to hear!