Ash Framework – Model your domain, derive the rest

I came to Elixir from PHP/Laravel so I approached Ash with a similar skepticism. I was looking specifically for a set of tools that would allow me to rebuild an ancient and unwieldy ColdFusion SAAS product, as a solo dev, with maximum stability and minimum boilerplate. I landed on Elixir+Ash after about a year of exploring other ecosystems and languages.

If you look under the hood of Ash's macros, they're all just shorthand for creating a particular struct with sensible defaults. It's not actually doing a ton of magic. You can replace them entirely with direct function calls, or probably even manually declare the structs yourself.

If there's magic, it tends to be more in the execution step - like how `Ash.read()` can push authorization logic into the query/db layer. But that's exactly the kind of logic I don't want to have to write myself over and over again.

I have never compared Phoenix's generated auth stuff to Ash's so I can't speak to that. However I can say Ash's generators all use `igniter`, which is part of the Ash project. It allows for package developers to reach into Elixir's AST to make smarter installers/updaters, and is being adopted more broadly throughout the Elixir ecosystem. So in terms of code generation Ash's approach is gaining a lot of traction.

Speaking for myself here, I've really liked working with Ash. The value becomes more apparent the more I use it.

Ash, while magic, is mostly a thin layer over calling functions. Often with a lot of ways to go deep down (let's say, by calling ecto functions yourself).

But I do understand you feeling. E.g. I myself have stayed away from things like AshAuth and Ash Forms for now

We support both Rails and Phoenix at Honeybadger.io (APM/error tracking), and I tend to personally prefer the more declarative/less-magic approach. We're still a Rails monolith primarily but have run Elixir services in production and are fans. We're just getting started on building some observability stuff for Ash, will be interesting to see how it compares.

>> All this is said without having tried Ash, so I could be way off base.

You nailed it. "Magic" is actually a good way to describe it, because much of the developer experience with Ash revolves around figuring out the exact incantation you need to use to make it do what you're trying to do, and the correct intonation and the right amount of reagents.

> born from Rails devs who were tired of Rails magic

One thing I learned is that we're all different. To me, the magic of Rails is absolutely bonkers, unintuitive, and unmanagable. I also can't work without static types anymore. DHH is apparently my arch nemesis in these regards? Yet I can't definitively say it's because he's inherently flawed.

You sound a lot like me when I first approached Ash a year ago, especially the part about being new to Elixir and worrying I'd just reproduce my prior MVC frustrations (Laravel in my case) in Phoenix.

I've been using Ash for about a year now and it's really hit the spot. Wishing you well on your journey!

Appreciate these thoughts. Would you mind sharing what Elixir and Phoenix books you're working through?

This is cool, though you would definitely make changes to make UI look decent, and a lot of changes on top of that to make it something that’s a joy to use. For API though, it should probably just work - but then again, there’s tons of stuff like Django REST Framework which, while also a bit dated, works really well in 95% of cases (and lets you handle the other 5%).

Yet here I am, writing CRUD endpoints by hand in Node.js...

Related thought: "Companies ship their org chart"

(https://en.wikipedia.org/wiki/Conway%27s_law)

I've always felt MDD falls short very quickly, because for non-trivial project you often want to show information related to more than one table, and so you have to fallback to writing the controller code manually anyway.

Always happy to hear about people liking the book!

"Magic" in software can be good or bad. I've tried to explain the apparent "dark magic" at the end of this article.

https://alembic.com.au/blog/essence-of-ash-framework

Would love any feedback as to whether this helps allay your fear and dread!

Spark is the DSL library that takes a DSL definition as Elixir structs and builds the DSL for you which in turn takes the written DSL and converts to a standard and simple data structure. So there are fewer macros than you might expect. Ash extensions just introspect that generated data structure with ordinary Elixir code.

The main macro in Ash core itself is the `expr` macro which enables portable declarative predicates which can be used in data layers like AshPostgres for filtering in SQL queries. If your data layer is simple like ETS or a CSV then it runs as Elixir code.

Ash will be your Django models. Once you have models (ash resources) built; you can use the Ash ecosystem to get things like a graphql or JSON endpoint (or both!) for those resources with just a few lines of code.

FWIW I regret introducing that term into this conversation. I've used it in some cases to try to bring people close to an understanding when we have like...no middle ground. But its nothing close to an ORM.

Echoing my comment from one of the other threads:

We have been using Ash at work for the past nine months. Our experience has been brutal. Learning curve is absurdly steep. Macros everywhere means you have to trawl through documentation to find information about the exact thing you're trying to do, and often cannot. Every time you step out of the well-trodden path you're punished with cryptic errors, for which there's nearly nothing on the web, and AI tools are clueless about. So your only option is to post about it in the Ash discord (which is for some reason not part of the official Elixir discord) and hope that someone responds before you lose your mind.

The only thing it has done for us is that our data layer has started to look somewhat standardized. This may be a reasonable benefit for larger teams that don't have any code quality or architecture discipline. For small teams though, and especially for solo projects, I wouldn't recommend it. Your productivity will suffer.

Only half a data point: I played around with it for a private project. It works but the documentation is far from good enough for production. I was even considering getting the book, but it's not out yet. In my humble opinion, normal documentation should be enough to understand a framework, otherwise you can't expect anyone beyond hobbyist and enthusiast to pick it up. "Break out" is definitively part of the design goals, so I always felt like they put a hatch.

This is one of the earliest projects we did with Ash. It's a really big app and the customer architect was convinced that if we didn't use Ash then they'd ultimately end up building some custom version of what Ash provides.

https://alembic.com.au/case-studies/from-paper-to-precision-...

We use it in production and are really happy with it.

For me, one of the biggest value points of Ash lies in removing the boilerplate without locking you in.

The devs of Ash cleverly use Elixir itself and other big names of the Elixir eco system. By doing that, they have created a framework that helps you moving more quickly as you don't have to write the same code over and over again (i.e. remove boilerplate) while still giving you the flexibility to escape if something out of the box doesn't fit right away (that's because of how Elixir works and how they just re-use the other big names, e.g. Ecto, Absinthe,...).

I've tried to write about all of this here if you are interested in reading more:

https://www.lukasender.at/ash-the-hidden-champion-of-low-cod...

In the end, it's hard to only write and read about this. You can only "feel" how things change when you actually work with it.

The learning curve is a little step at first, though (in my opinion). But the docs got a lot better over time.

All in all, I'm still happy with how things turned out and would use it again for future projects.

I've got an app coming out of beta that runs web accessibility scans, which uses Elixir+Ash. Beta testers loved it, it's been very stable and I barely had to touch it over the beta period.

This app has a lot of complex headless browser flows that rely a lot on Ash.StateMachine, and Ash has only gotten better the deeper I've gotten into it. The app gets more simple and stable the more I integrate with Ash.

The declarative "data-oriented programming" paradigm took some getting used to (I come from PHP) but it makes so much sense and makes it easy to plug Ash resources into any other use case. Deriving a JSON api is an easy example.

In another app I'm using Ash.Reactor to model agentic AI workflows (it's just RAG but with extra steps). Reactor was originally intended as a saga orchestrator that models workflows as a DAG. DAG is the perfect abstraction for this use case and it works ridiculously well.

Hello, I have two projects in prod on ash!

First of all, its not "macro based", as that implies dark magic and sacrificed goats. The spark dsl underlying all this is just structs all the way down in a nested manner. Just like you would see if you look under the covers of a Absinthe Blueprint produced by that dsl.

The dsl is declarative and allows to express a lot of stuff with less code, but I would say that saying its "macro based" is a bit misleading, although "technically correct". You could achieve the same by just having functions returning structs.

I have replaced a biiiiig nestjs app that exposed graphql with an ash app exposing graphql, and the boilerplate ratio for resolvers etc is bordering on 1:999. Like literally, across a 90 table large application I have maybe 600 lines of "specifically graphql related code" (5-10 lines of code to expose select actions as mutations and queries per resource). As opposed to the nestjs codebase that was using an annotation driven approach and had a gazillion lines of glue code for resolvers and data loading.

Also the authorization logic through the policies is so extremely composable and easy to do when combined with matching on resources it is fantastic. Each resource "owns" its own authorization, so there is no song and dance about figuring out acl from the entry point and then downwards a tree. You just let the resolver resolve its way down the graphql tree or just feed a long ass loader path into Ash.load and each resource is responsible to implement its own policies and you don't have to worry about accidentally leaking data because you access the data from a new entry path that was not locked down because you added a new resolver.

I kept reimplementing the same boring boiler plate every damn time I started a new project and that pain is almost 100% gone.

It is a harsh learning curve for sure, because the one downside of Ash is that you have to do it the "ash way" for stuff to compose as beautifully as it does. Once you really get into the groove making "expression calculations" (basically projections that reach into other resources or columns to make some kind of computed data, but is done in the database layer since you expose it as an expression) that you can compose and make depend on eachother etc it becomes so incredibly fast to make new functionality.

You think about one and one thing and let the framework take care of how to compose the loading and usage of what you make. A much simpler model than "making it yourself" in ecto which I have been doing for 10 years prior.

I tried it out at the start of a new project last year. After 3 weeks, I finally threw in the towel and started from scratch in plain phoenix. By day 2 or 3 I'd surpassed what I'd managed to somehow get working, mostly by trial and error, in Ash.

I am 100% on board with the vision, but the learning curve is absolutely brutal, and at least at the time the documentation was simply not anywhere close to where it needed to be. Something this different needs a truly giant "cookbook" to show, you know, how to use the damn thing. That was lacking and there was nothing to learn from online besides the most basic toy applications. Also, it was, at least at the time, slow as hell. All those damn macros.

Plus - elixir is already niche. Ash is a niche within a niche. I need to be able to hire people who can get up to speed in days, not weeks or months. There's a chicken and egg problem with something this ambitious - no-one uses it because no-one uses it. I hope it breaks out of this dilemma but professionally I can't bet the company that it does.

As I said I really like the idea. Anyone who has maintained an OpenAPI app will jump for joy with documentation and tests moving automatically and in lockstep with the core domain logic. But for me, at the time, it was too early, too risky and too obscure. I do wish it well though - I love these kind of moonshots and I look forward to trying it again as soon as I can.

It's not really producing a whole separate language that I've found. There is a lot of functionality so the learning curve has been pretty steep to start. The macros are for pretty specific things but once you split out stuff like permissions, changes, etc you just use normal elixir modules. I can't think of any situation where I'd need to go outside of it and couldn't. It is built on top of all my normal elixir stuff and I've had no issue using them as normally. I'd definitely suggest reading the book first though there is a lot of unknown unknowns with it.

I started using it because I just found it a much nicer way to define my data, auth and interactions with it compared to contexts. It also makes it easier to reuse it and because of the way the data is modeled you get a lot of nice things like the ashphoenix forms which make dealing with them a lot nicer in my opinion.

I'm also likely to be hiring soon so having a well defined way to well..define things seems like it will make it easier with onboarding but I haven't tested this yet.

(Been using elixir for about a decade)

There is a post that Mike wrote that describes the thinking behind Ash's declarative approach

https://alembic.com.au/blog/declarative-programming

I just wrote a post which attempts to explain the big ideas in Ash as I see it. Would love your feedback on whether this helps answer your excellent questions

https://alembic.com.au/blog/essence-of-ash-framework

I'm also very comfortable with Phoenix and Ecto (and LiveView), and initially found Ash a challenge to wrap my head around. After working through the book and really keeping an open-mind on my next project, I've found it a real joy to work with.

Keep in mind that Ash doesn't really replace Phoenix or LiveView (or Ecto), but it's built on top of it. You can still use Phoenix and LiveView the same way you are today, and just rely on Ash to build your context for you and how you interact with your resources. So I'd say it "replaces" Ecto in that sense (though it's all Ecto under the hood).

For me, I'm building a native app with a GraphQL backend and it has been an amazing productivity increase. With Ash, GraphQL on the backend and React and gql.tada (https://gql-tada.0no.co/) on the front-end providing a fully typed experience, I feel even more productive than using LiveView.

As a quick example - I have an existing derived GraphQL endpoint with a query for getting a resource, and I can have basic filters and sorting out of the box from Ash (i.e. filter by status, sort by name, filter by date greater than X, etc.)

Recently, I needed to build a feature to support adding a tag to a resource. I modeled the relationships (join models, etc.), made the necessary additions to my create/update actions and without _any_ changes to my GraphQL setup, I was able to support filtering my resource by tag (or tags) basically for free.

Can I build that in Ecto directly within my Phoenix context? Of course, but I didn't need to - Ash derived that functionality for me, and built that in, with all of the necessary preloading through dataloader and all of that for me, so the queries are optimized.

Ash is a huge mindset shift, and I think it'd be tough to incorporate it into an existing project, but if you're able to start a new project from scratch, I really recommend you give it an honest try. Especially if you think you might need to have additional data channels (i.e. LiveView and GraphQL or Json API).

If you've tried to make a JSON API with Phoenix, it can be pretty cumbersome to generate an OpenAPI spec for the project. It's a very manual and tedious process, even when working with OpenApiSpex (the go-to Elixir library for generating an OpenAPI specs). And if your code implementation changes, then you often have to update your spec to match it.

With Ash, the same data used to model your application is also used to derive the data needed to build the OpenAPI spec. So there's a real value proposition there IMO. It eliminates much of the problems of keeping your spec in line with your code, since they are both modeled in a single location.

Disclaimer: I only learned this by working through the book, so I haven't actually gotten to experience anything off the happy path.

Add an attribute to a model, run `mix ash.codegen`, it creates migrations for you.

Ash can do paging for you.

You don’t need to create a context file with CRUD functions for your Repo.

See the example repository for the Ash book.

https://github.com/sevenseacat/tunez/tree/end-of-chapter-10

Do these help at all?

https://hexdocs.pm/ash/what-is-ash.html

https://youtu.be/vjnPjrCF4rs?si=sGlfZeEpPrfp1J0K

Is installing Rust any different?

https://www.rust-lang.org/tools/install

Glad to hear you got a new project started, but let's address the ick factor.

When you define a relationship like `has_many :representatives`, Ash does’t create `representative_id` on the destination resource, we only validate that it exists and meets some criteria.

No resource ever modifies another resource, so you have to define the id on the other side using `belongs_to` which modifies it's own resource only adding the `respresentative_id` attribute with this

`belongs_to :representative, Representative`

If you need custom field names, you can override them:

`has_many :representatives, MyApp.Representative, destination_attribute: :custom_reference_id`

The docs explain more:

https://hexdocs.pm/ash/relationships.html#belongs-to

https://hexdocs.pm/ash/relationships.html#has-many

It's definitely worth taking another look.

The Ash DSLs get full autocomplete from your LSP and so make sure this is setup. The new Elixir LSP called Expert - https://expert-lsp.org/ is coming soon and aims to make this a much smoother process.

The documentation has been overhauled multiple times and is constantly being improved. If you encounter issues please raise an issue or a PR, knowing where users get confused is important for improving the docs for everyone.

One issue that new users often run into is that Ash is spread over multiple packages for different extensions and Hex didn't support multiple package search, which is being currently improved. So double check you're searching in the right package. Dash can help with this offline if you have it.

Tidewave (https://tidewave.ai/) MCP can help with doc search too if you are using a LLM/AI assisted editor like Cursor, Windsurf or Claude Code, etc. We also have some Ash specific announcements this week along these lines... ;)

>> I guess I'll give it another try.

I wouldn't bother. We have been using Ash at work for the past nine months. I'm not a fan, and dread using parts of the app that are built with Ash. It makes my productivity plummet due to cryptic error messages, really poor documentation, and high levels of obfuscation (by way of countless macros) that hides what is happening under the hood. Based on my conversations with other team members, most of the team feels this way. The only reason we're continuing to use it because it enforces a level of standardization on the codebase.

Check out the docs for the Ash Igniter mix tasks, they will generate skeleton code for you:

https://hexdocs.pm/ash/Mix.Tasks.Ash.Gen.Resource.html will generate a new resource for example (and the Domain if it doesn't already exist).

Check the side bar for other generator mix tasks.

Thanks for the feedback, we'll try and make this DX clearer!