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.
