Random thought: when you set up AshAuthentication, was it before we added the igniter installers for it? The new installers generate the actions directly into your app which makes it much easier to understand what Ash is doing, and also to see what kinds of things you might want to test.
I’m an early adopter of Ash.
The primary customer facing parts of our application stacks are all on the Phoenix Framework. Before our adoption of the Phoenix Framework, we were on React. The switch made our productivity 3x. Our productivity were further increased by another factor of 2 with the adoption of Ash.
There were 2 things which made me push for the use of Ash in all our projects.
- the ethos of “model your domain…”
While I’m an accomplished software engineer, my main way of thinking/solutioning is at the data engineering level, aka data domains. Ash made me feel home by allowing me to get back into my familiar mode of approaching solutions from the data engineering angle. - Policies
I have previously implemented data policies using Postgresql’s “CREATE POLICY”. Geesh, the nightmare of maintaining policies at the database layer. It’s my second hate after stored procedures.
Platforms like Supabase made policies easier. But not by much.
Ash’s implementation of Policies is gold!
I’ll also like a word about testing.
I don’t test against Ash framework. (Or any 3rd party frameworks)
I just assume they work.
Rather, I write tests to ensure that the data path (input and output) are what I expect them to be. That means again, I test the data engineering path.
(Of course, the rest of my tests are on UI / UX liveview testing)
20 Likes
What I did
I built a spaced repetition spelling app for my daughter in Ash. She is about to graduate from her dyslexia & dysgraphia course, due in part to optimizing her practice time.
Learning Curve
For all the boring bits, CRUD a user, Auth a user, CRUD flashcards that belong to the user, my blocker was the learning curve. But I chose to learn a new thing so that I can better build software in the future. I guess if you don’t like learning this is a bad thing… But then you are going to hate building software.
Using Elixir & Testing
For the spaced repetition bit, this was my secret sauce, the most complex part of my business logic. I chose one of the many options for supplying a custom Module to the Ash resource. And then I wrote a normal Elixir module with good old tests.
5 Likes
Thanks for sharing your experience here. Must have been hard to do.
I do think Ash, and things like it, are where we are all heading. Ash has good abstractions, and good trapdoors to let you access what is underneath. There are many reasons for this. One of the main ones is that coding agents are going to need better structure. Ash simply consolidates the important bits to make it easier for people to understand and build. The same is true of machines.
8 Likes
I have been a professional Elixir developer since 2022 and I have participated in diverse projects. In my opinion using Ash would have been a huge blessing if those projects use it, not only for defining the models but for calling external apis as well.
Is expected that not every project would match the way of Ash, specially those older ones with weird database structures due to business requirements. But if those project would be made today I would totally recommend Ash, at least as a wrapper for legacy APIs.
Production projects made by many people will surely be wild if there is little conventions in place. Ash can ease creating a standard and a common ground for projects that will be maintained for years and used in heavy load environments.
4 Likes
If you end up migrating off it, please share your experience with that, what was difficult, how much effort etc.
2 Likes
Thanks for sharing your thoughts on Ash Framework.
I had some of those ones as I have been trying to learn it in the last few months and I was looking forward for the book “I just bought it recently” plus the utilization of macros although at the end I need to admit it is similar to learning the syntax of anything.
More effort is required on the learning resources and how Ash internals work “Too late as Zach mentioned above to have it in this book”.
I believe the concept of Ash is where programming is heading now and it could be a strong baseline for more like AI code generators as it comes in line with its principle of " Model your domain, derive the rest" so it is not far from writing maybe AI prompt where you supply your data model in simple English instead of current DSL syntax and get the code ready .
3 Likes
I would like to point out that is VERY far from eachother.
The whole point of a dsl is that you can always reproduce and understand what goes on. There is no magic, there is only condensation and enforced patterns.
An LLM by its very nature has unstable output.
I am not sure if you are misunderstanding LLMs, Ash or both with that comment 
Ash main feature is to simply remove a whole class of code you don’t have ownership of any more. An LLM will bring tons more of code under your ownership and it will all be slightly different.
4 Likes
To expand on some sentiments above regarding the learning curve and having to reference docs, here is a bunch of text that is a bit ranty:
Aside from Ash’s tag line, Zach often mentions that any significantly large project is going to end up inventing some version—though far more likely versionS—of a part of Ash. In the 15 short years I’ve been writing code professionally this couldn’t resonate more, so much so that I would go as far to say that I think it’s irresponsible not to use Ash on any serious project that’s going to one day have people coming off of and onto it. This may sound a little hyperbolic, and it is, but I stand by it (just my opinion, of course).
The key thing here is that if you don’t use Ash, you are going to be faced with learning some well-meaning (hopefully) soul’s bespoke framework that was maybe documented, but the docs are probably out of date, and the code’s been mangled by other folks who didn’t understand it, and all those people probably don’t even work there anymore. I’ve hit this is in every company I have worked for, even the smaller ones. I’ve worked on one enterprise application where there were multiple custom frameworks solving a single problem. Yes, people got sick of the old outdated version and just gave up on it, but it was so ingrained that they left it and just started the process all over again for new stuff (ah Reports and LegacyReports, how I do not miss you, although probably a bad example as I don’t think Ash has reporting yet). In a way, you can’t really blame them.
In any event, I hate this. The worst part is that many developers just accept that this as the way it is. If things are “just regular functions” they can at least hack it to pieces to achieve their immediate goal without having to worry about how it affects the next person. Many people who do this do it because it’s more fun than working on CRUD. Then when cracks start to show in their design, they don’t care because most people don’t spend more than 2-4 years at a single job so they’re gone and now it’s someone else’s problem. I realize not everyone is like this, but it’s a real thing I’ve witnessed real people say (sometimes they are even boastful about it—gross).
And of course I’m describing worst case here. Even when these things are done well, the cracks always start to form. Ash is developed by people whose only job is to make sure this stuff works and is flexible. I absolutely understand the initial pain of seeing something that looks alien but that pain is far less than what I feel when I find out I have to learn multiple in-house mini-frameworks solving different problems. All that to say, I would much rather put some time in up front learning a common, third party language than ever have to deal with a homegrown framework again.
And to be clear, I am someone who has made their fair share of these custom frameworks.
27 Likes
how do I like a post twice
6 Likes
by liking your proxy post 
But yea, what @sodapopcan said resonates.
I’d much rather put some time up front learning a common language than ever have to deal with a homegrown framework again.
Where a homegrown framework is also a language that is by definition uncommon. But the main point being they don’t care. Or rather, the main point of Ash is the the commonality, the “third party”
noun: commonality; plural noun: commonalities; noun: the commonality
the state of sharing features or attributes.
this sounds like a pun lol
But yea, I think it boils down to foresight, which is hard in software development. It’s generally difficult to have foresight, there’s a saying hindsight is always 20/20. it’s just that in software development this problem is multiplied by a greater factor.
It’s actually not that hard, in essence, but… It’s a difficult optimization problem in any case.
It’s definitely less difficult with Ash I guess you could say.
That’s why I’m drawn to it. 
The commonality aspect gives you this comfort to lean on, but I think this is embedded beyond Ash, all the way to the BEAM, through Elixir. This is why Ash feels like a lotus in some ways 
or lotus within a lotus within a lotus. I mean in the sense that the declarative end goal is like the change of medium, but it’s the same plant; it’s like just elixir, well utilized.
This thread ended up a third party thoughts on Ash. 
4 Likes
