My thoughts on Ash

Thank you for your feedback! I appreciate the kind words I won’t personally “argue” with your takes really insofar as “convincing” people to use Ash coming from me has a pretty clear bias, but ultimately Ash isn’t a fit for every person or every project and that’s All Good™

If you do end up switching your app off of Ash, please do come back with a retrospective, as I imagine that you will have lots of learnings from that process. Best of luck!

They’re all really good points!

The learning curve is definitely the biggest one, IMO. It’s a lot better than it was, and getting better every day, but we still have a long way to go. There’s one book out, another on the way, a series of blog posts and tutorials, and more are coming. I guess that’s more of a ‘watch this space’ (and we can’t clone Zach unfortunately, we’ve tried).

The testing one is interesting because I think people expect more from Ash than you really need. Ash provides some tools for things like data generation and property testing, but the rest is exactly the same as you would test in any other Elixir app (or Phoenix if you’re using Phoenix). Test inputs and outputs to functions, test side effects, test UIs. Nothing really Ash specific there at the moment, but the space is evolving (the generators in particular got a lot of polish when it came to writing the testing chapter in the Ash Framework book.)

To answer the specific questions:

The generated code is now your code, so you own it - you can test as much or as little as you want to be confident that it does what you expect. There is no right or wrong way to write tests. If you want to write a couple of LiveView tests that hit the sign-in page and ensure that a user can log in, and be done with it, that’s fine. If you want to test every single generated action, that’s fine too. If you heavily customize the generated actions, not just tweaking the config for the extension, that might be worth testing.

I mean I wouldn’t do it But then again, I wouldn’t go to the level of testing the actions in a User resource. I’ve written tests for the Tunez app (used in the Ash Framework book) that is probably as granular as I would go for basic authentication. I have apps in production that have more, I have apps in production that have less!

It is a really big mental shift to think about things in “the Ash way”. But honestly, I’ve been using it for long enough that I don’t think I would want to go back to building apps without it (despite all the pain it still sometimes causes). It’s a big investment, and if it’s not one you want to make, that’s okay! Keep it in mind and maybe revisit it and the story will be better in the future

I did some contributions recently but I’m no expert, nor do I have production apps built in ash under my belt.

Keeps you away from Elixir

While working on and with Ash I don’t find it keeps me away from Elixir.
I can see how Ash is Elixir. Don’t let the declarations fool you, it’s functions all the way down.

and I still don’t know if Ash is really for every kind of project

I think ash’s impact and significance correlates with the scale and complexity of a project, bigger the project more it matters. That’s my opinion. Like I said, I have no evidence to back this claim.

That said, your decision sounds valid, as does your criticism.
Maybe you’ll come back to ash after you built some apps without it.
You level up, documentation levels up. We all level up!

By the way, I didn’t express that clearly earlier. What I meant to say is that Ash moves you away from the typical Phoenix generator workflow, like using functions such as Projects.create_project and Projects.list_projects. I understand that I can replicate these functionalities using Ash’s actions and definitions, but it still feels significantly different from the ‘standard’ Phoenix approach that I’m accustomed to

And about this, i forgot to mention but i don’t know how easy to have a team working with ash, talking about learning curve, really curious about it, but thanks for your answer and collaboration.

I’m really interested about this book, can i ask you a question, if i buy the current beta version in book i receive updates later or i’ll need to buy the book again ?

I think a big challenge that Ash (and maybe Elixir to some extent) is that you won’t really appreciate the complexity that it reduces until you’ve built the software for awhile.

For example, if you’re starting out building a simple Task management system, using Ash might seem like total overkill. It’s much easier to keep things in a context file and go from there. The Ash learning curve doesn’t seem worth it at this point, so it’s easier to throw in the towel and stick with traditional context/Ecto statements.

Once the app grows, the idea is that as you need to add more functionality (like, an external Json API), then the advantage of Ash becomes apparent, because you just add an extension and a handful of configuration and you’re done.

I really hope that the learning curve problem is able to be overcome, and I’ve found that the generators (and the Ash book!) have helped a lot with that. I’ve tried Ash a few times in the past and wasn’t able to get over the curve. With the Ash book comes a more guided story/experience, and along with the generators it was finally able to click for me.

100% agreed! I’ve bought the book after Rebecca’s reply and I’m already reading a lot. @sevenseacat and @zachdaniel i have a suggestion that you may have already considered: please include some sections focusing on Ash internals, like a deep dive into Ash, Spark, and other related components. I think this would be very helpful for us to understand the ‘Ash magic’ and even encourage more contributions. Regarding the book itself, it’s a great read! Congratulations again!

Early adopter here (with great help from @sevenseacat, @jimsynz, @zachdaniel & @joshprice). You can go a very long way with a very small team once you get a handle on Ash & how it works. There are always tricky bits - e.g. our initial RBAC & workflow implementations - but these days I’d say we spend the vast majority of our time on UI design & polish as the engine room (business rules, policies, migrations etc) pretty much look after itself.

To the point @mike1o1 made - whether the investment to learn is worth it depends on what you’re building.

Counter to other replies here, I have very little experience with Ash though from what little I do know:

sounds like you just aren’t using code interfaces? These simply write the context functions (in Ash, domain functions) for you, abstracting away the extremely boring and repetitive patterns of params → authz → changeset → manipulate changes → populate virtual fields (on every public function) → etc → return → side effect. The beauty (again speaking as someone who just scratched the surface) is that Ash’s escape hatches aren’t even codified, they’re simply: just write the function for yourself.