I feel as though this website does a poor job of telling me what the framework actually does. There's the mostly-fluffy marketing lead text, followed by an overly-complicated configurator to generate a project.
What can I actually do with this? What problems does it solve? Where is it located relative to other solutions in the same space? What is that space?
I've talked about this a few times and this is the shortest answer to this question. The first part of this talk may help explain concisely where Ash fits at a higher level.
Ash Framework was created to solve a fundamental problem in (web) application development for business apps. When you build a new app, you want to focus on the valuable, innovative parts - what's visible above the waterline of the iceberg. However, modern web applications require an enormous amount of "below the waterline" functionality that's essential but not where you want to spend your time.
Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
Authentication is a perfect example - most customers don't even specify login functionality as a feature. Similarly, admin interfaces are considered table stakes for modern applications. The list is extensive: admin UIs, observability, security, and more. All important, but time spent there can feel wasteful when you'd rather be innovating.
Ash's primary goal is to keep you focused on the innovative work above the waterline while minimizing time spent below it. The framework accomplishes this by modelling your domain and deriving everything else.
> Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
So wordpress or prestashop should be enough for 95% of your needs if you're a consultancy.
Absolutely, if your customers want websites or ecommerce shops, then that's totally true.
The context here is that Alembic builds custom business applications where these problems have not typically been solved before. We want to spend most of our development time on the core business problem not rebuilding things like Content management systems or Ecommerce shopfronts.
I've got to be honest. The comment you're replying to is spot on.
The headline, "Model your domain, derive the rest" is fine by itself. But the paragraph underneath is just dismissible drivel; sure, I could click through the links to more detail, but you've not given me a reason to do so... you've not set the hook. Once I did click through the links, I'm either in the documentation, which is way too much, or at YouTube, etc. The opening paragraph doesn't give me enough reason to click through the links, and if I do I'm given what feels like a firehose.
I appreciate that's pretty harsh assessment of your landing page, but that's exactly how it strikes me and I think you need to hear it if your goal is really to capture audience. That landing page should give me the gist of what you do, several short paragraphs outlining the higher level features... I dunno, call them "selling points"... something that can give me cause to care enough to dig into some details. Once I care, then sure... I'll dive into the docs or watch a video.
As for the book ad other comments talk about: it's fine. I would expect that people that know what Ash Framework is also come to the page and having that out front isn't a problem and speaks to the existing community.
Personally, I already know what Ash Framework is, so I know you have some good selling points that could be summarized and that would be of interest to people. You just need to get them out front in as pithy a way as possible.
That's really helpful feedback and there are few comments mentioning exactly this and you're right, we can definitely explain more up front on the landing page so it's more obvious.
...do you think the book is like a money grab or something? We put it big on the site because a bunch of our users were excited about it and found value from it. The book doesn't even remotely pay for itself.
> ...do you think the book is like a money grab or something?
Yes. Regardless of what you intended, IMHO, it comes off as a money grab, and the fact that it glows and "Get the book" is in that high contrast purple doesn't make it better. Maybe it's just me, but I would suggest making it less conspicuous.
edit: and the book image causes a content layout shift when it loads
I appreciate the perspective. Honestly for us it was just something that our whole user base was mega excited about, and so we made a big deal about it. It seemed like a positive that there was a book available (especially given that young-ish frameworks benefit from some level of legitimacy, given that it's a Prag Prog book etc.). I never even considered that it would rub people the wrong way honestly.
I think I'll probably keep it front and center for now, given that the book will be launched out of beta in the near future, but I can see how it might give the wrong idea, and will reconsider its placement going forward
About books: I had a horrible experience in the past with Trailblazer, the Ruby library.
The documentation was horrible, and only had extremely basic examples. The recommendation to any question I saw online was always to buy the book for almost anything. The goal of the bad docs was clearly to encourage people to buy the book. That rubbed me off and it felt like a cash grab.
And of course I'd buy a book and donate for a library I'd want to support, but for Trailblazer's case it's the opposite, I never voluntarily chose to use it and actually would like it to die.
Coming to the site from an aggregator (and needing to be convinced to use Ash, rather than coming there directly and already knowing I want to use ash) I found the book a little weird to be so front and center.
I would have really hoped for a small code snippet or screenshot showing how powerful the framework was. And a book a little further down from that would be nice. But "pay to learn" before "here's a quick snippet on why ash is neat" would have made me more excited for this thing I hadn't heard of before, and who's website I was visiting to learn about.
---
Seeing a book first gave me a different impression -- like one of the old snooty languages/tools from twenty years ago that was really enterprise-only.
I can tell that's not the vibe Ash is aiming for, but it's what I picked up!
(Somehow, I also couldn't find the documentation link on the first two tries. But that's also my eyes being weird and missing the sticky header where it clearly says Documentation!)
This is not a new problem. It is exactly what a web application framework like, e.g. django has been handling for one and a half decades.
What does it do that django doesn't?
A lot of competitors to django have also fallen behind because they either railroad you too much (e.g. by making immutable assumptions about how you want authentication to work which often end up being faulty) or go too far in the other direction and require an excess of boilerplate. This is a very subtle and tricky trade off that most newcomers to the space fail badly at.
But you aren’t required to use Phoenix with an Ash project. Ash will happily work as a standalone CLI, terminal app or some other Elixir web framework that comes out tomorrow.
The forms https://hexdocs.pm/ash_phoenix/AshPhoenix.Form.html seem even more low level than Django forms, and those are notorious for being too low level and annoying to work with. This to me seems to run counter to the tagline. Compare with iommi for Django where you can truly "derive the rest" from the domain model to get forms and tables.
Unlike Django, Ash is not a web framework, it’s an *application* framework.
One way to think of it is that it’s a flexible and extensible domain modelling language that also happens to derive an Elixir application which can be called from Phoenix web UI (or something else like an API, a terminal UI or even an MCP server.
Rails are definitely inspiration for the way Ash DSLs are used to model your business domain, but Ash takes this idea way further.
Ash models nouns and relationships like ActiveRecord does, but it also models Domains (think DDD bounded contexts) and Resources with the verbs or "actions" of your system.
It also lets you configure generated APIs and your data layer (eg Postgres) so it doesn't stop at just how an ORM may typically model your data.
Always cracks me up. In previous life I worked in creative agency and we had a Project Manager called Ruby. Sometimes parties were getting out of hand and she got a nickname Ruby on Rails when she dropped a baggie on the table and made herself two lines (rails) with company credit card.
We've always had trouble with this. The closest thing to Ash I've seen elsewhere is an ORM. It's not an ORM though.
Ash is a declarative application framework. You define your application logic using Ash.Resource, which model things like state, but most importantly actions.
Another analogy is that it's similar to GraphQL, but lowered down to the backend layer. It's a declarative, typed application description and implementation framework, that you can derive a GraphQL from (amongst many other things).
Another way to think of it is a whole ecosystem of packages that standardize the vast majority of things you want to do when building an Elixir backend, instead of trying to kludge together a bunch of different tools. Pagination, sorting, filtering, authentication, authorization, all builtin and designed to work together.
That's certainly more helpful, yeah! My biggest complaint is that that's really not particularly obvious from the home page; I didn't realise the highlighted words in the lead were links, and they're all to a diverse set of locations, which I'm unlikely to check out if I just want a ten-thousand-foot view of the framework.
I'd suggest putting a description similar to your last paragraph on the home page, and including a brief example of what that translates to. Phoenix's website [0] does this beautifully: within the first page of scroll, I immediately know what it does and how it looks, and the following pages of scroll give me the detail I need to evaluate it properly.
I hear what you say. I personally blame the flurry of BS js "frameworks" that have more effort put in their Apple-wannabe front page than in actual practical engineering. I think they've setup a weird standard for framework front page that this one seems to follow.
I don't blame the Ash guys, I blame the people who created the trend and those supported who it. I look at you, JS community.
I've always been a fan of Model Driven Development (MDD), which is by today's standards an ancient paradigm. You define the core data model (resources), properties (attributes), and actions, and auto-generate the UI/API. It was more popular back when OOP first met Web Development. It seems to have fallen to the wayside with manually constructed "fat controllers" being the dominant way to organize web apps today. I have my own framework in MDD style. For a long time I've told people "I can code at the speed of thought." My apps are 80% the data model, 20% the UI, with the middle layer almost entirely generated. Tools like GraphQL, Supabase, and auto-admins kind of go in the same direction.
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...
I ran the install link in the home page and got an empty phoenix project. How am I supposed to understand what to do next? How to add a resource/domain etc. I thought it was a full example. Or at least I'd get a CLI tutorial to create my first resource i.e.
As many people seem confused, it seems that this framework is a declarative framework (think: expressing a solution like you would in SQL or Prolog), in Elixir, that seems to have the goal of separating out core logic from control flows within web apps, APIs and so on.
Over the course of 15+ years of playing with Rails, I've come to the view of CRUD being a poor choice for most real-world applications and MVC being a useful but often-abused concept. That took me down a bit of a rabbit hole of trying to think about DDD within the constraints of an opinionated framework that thinks CRUD and MVC are the thing that makes you go fast. I, on the other hand, want the thing that makes it easy to extend and maintain. I want actual events to be modeled for all sorts of real-World reasons.
I've been learning Elixir recently because it's something new, the actor model appeals from a concurrency perspective to some of the problems I want to solve, and because Phoenix looks like an interesting and elegant web app framework. However, there was a nag in the back of my head that I'd just end up hitting the same frustrations: I was, and am, ready for that and seeing if anything about Elixir + Phoenix makes life easier than Rails made it.
Ash seems to be a good candidate for part of the puzzle. A declarative framework that brings some packages for useful, often-needed parts of the puzzle (like authentication, authorization, and so on), and it seems to encourage a way of thinking about some key DDD concepts. Resources sound like domains or bounded contexts. Declarative style sounds like it might lend itself to event modeling more easily. Calculated values are a nudge towards "view models".
Never tried, I'm early on my journey, but I think the Ash book will be the first thing I pick up after I've finished the Elixir and Phoenix books I'm reading through. Curious to hear stories from people further down this journey, though!
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.
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
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.
I am a total noob, ok programmer but not a very good developer.
I'm coming to Phoenix with a Django background and I really enjoy what I've been messing around with so far, but I haven't done anything serious with it.
When I hear people say "ash is like an orm" then that fills me with dread. I actually come to enjoy how elixir/Phoenix/ecto has done things
If I'm trying to build something ie a news aggregator site (like hackernews ) - how would "make it in ash" help me? If it does things for me, does that mean I lose control of those things? Or they are hidden behind some macro magic that I have to pull apart to get to?
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.
Right and unlike an ORM which only models the "nouns" and "relationships" of your business domain model, Ash also models the verbs.
This allows it to reveal the actions of your system externally via GraphQL or JSON API as well as modelling the data for your relational schema (although data layers are swappable and are not always relational).
Ash models an application's verbs or operations as actions. This allows the production of events via an "Aspect Oriented" way of hooking into the action lifecycle.
Although it doesn't support a command first Event sourcing approach, AshEvents (https://github.com/ash-project/ash_events) does help produce events that could be replayed.
Torkild wrote an article about his latest updates to AshEvents here:
I'd love to hear from someone who's shipped a product into production with Ash. I've been considering using it for a new project but I'm a bit weary of introducing a whole second language. With it being macro based rather than functions, I can't help but think it might be tricky to break out of for areas where its opinionated approach don't fit so well.
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:
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.
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.
With the caveat that I’m still learning elixir+ash and just building a small private project, I’ve bought the beta book and it really helped get my head around the concepts even though it’s not finished. I’d recommend it, it’s even on sale at pragprog this week.
Ash itself is fantastic so far. I haven’t worked with anything so productive before. Loving it.
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 feel as though this website does a poor job of telling me what the framework actually does. There's the mostly-fluffy marketing lead text, followed by an overly-complicated configurator to generate a project.
What can I actually do with this? What problems does it solve? Where is it located relative to other solutions in the same space? What is that space?
I've talked about this a few times and this is the shortest answer to this question. The first part of this talk may help explain concisely where Ash fits at a higher level.
https://youtu.be/10VBTcN8gAo?feature=shared&t=133
Ash Framework was created to solve a fundamental problem in (web) application development for business apps. When you build a new app, you want to focus on the valuable, innovative parts - what's visible above the waterline of the iceberg. However, modern web applications require an enormous amount of "below the waterline" functionality that's essential but not where you want to spend your time.
Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
Authentication is a perfect example - most customers don't even specify login functionality as a feature. Similarly, admin interfaces are considered table stakes for modern applications. The list is extensive: admin UIs, observability, security, and more. All important, but time spent there can feel wasteful when you'd rather be innovating.
Ash's primary goal is to keep you focused on the innovative work above the waterline while minimizing time spent below it. The framework accomplishes this by modelling your domain and deriving everything else.
> Running a consultancy and building various client projects highlights this challenge. Everyone wants to focus on the core, valuable features, but must also deal with relatively boring, commodity problems that have been solved countless times before. This often means reinventing the wheel, which clients understandably see as low-value work.
So wordpress or prestashop should be enough for 95% of your needs if you're a consultancy.
Absolutely, if your customers want websites or ecommerce shops, then that's totally true.
The context here is that Alembic builds custom business applications where these problems have not typically been solved before. We want to spend most of our development time on the core business problem not rebuilding things like Content management systems or Ecommerce shopfronts.
I've got to be honest. The comment you're replying to is spot on.
The headline, "Model your domain, derive the rest" is fine by itself. But the paragraph underneath is just dismissible drivel; sure, I could click through the links to more detail, but you've not given me a reason to do so... you've not set the hook. Once I did click through the links, I'm either in the documentation, which is way too much, or at YouTube, etc. The opening paragraph doesn't give me enough reason to click through the links, and if I do I'm given what feels like a firehose.
I appreciate that's pretty harsh assessment of your landing page, but that's exactly how it strikes me and I think you need to hear it if your goal is really to capture audience. That landing page should give me the gist of what you do, several short paragraphs outlining the higher level features... I dunno, call them "selling points"... something that can give me cause to care enough to dig into some details. Once I care, then sure... I'll dive into the docs or watch a video.
As for the book ad other comments talk about: it's fine. I would expect that people that know what Ash Framework is also come to the page and having that out front isn't a problem and speaks to the existing community.
Personally, I already know what Ash Framework is, so I know you have some good selling points that could be summarized and that would be of interest to people. You just need to get them out front in as pithy a way as possible.
That's really helpful feedback and there are few comments mentioning exactly this and you're right, we can definitely explain more up front on the landing page so it's more obvious.
Thanks!
When I opened your website first thing I saw was "Get the book" and it's a big red flag for me. No, I don't think I will.
...do you think the book is like a money grab or something? We put it big on the site because a bunch of our users were excited about it and found value from it. The book doesn't even remotely pay for itself.
> ...do you think the book is like a money grab or something?
Yes. Regardless of what you intended, IMHO, it comes off as a money grab, and the fact that it glows and "Get the book" is in that high contrast purple doesn't make it better. Maybe it's just me, but I would suggest making it less conspicuous.
edit: and the book image causes a content layout shift when it loads
I appreciate the perspective. Honestly for us it was just something that our whole user base was mega excited about, and so we made a big deal about it. It seemed like a positive that there was a book available (especially given that young-ish frameworks benefit from some level of legitimacy, given that it's a Prag Prog book etc.). I never even considered that it would rub people the wrong way honestly.
I think I'll probably keep it front and center for now, given that the book will be launched out of beta in the near future, but I can see how it might give the wrong idea, and will reconsider its placement going forward
Same.
About books: I had a horrible experience in the past with Trailblazer, the Ruby library.
The documentation was horrible, and only had extremely basic examples. The recommendation to any question I saw online was always to buy the book for almost anything. The goal of the bad docs was clearly to encourage people to buy the book. That rubbed me off and it felt like a cash grab.
And of course I'd buy a book and donate for a library I'd want to support, but for Trailblazer's case it's the opposite, I never voluntarily chose to use it and actually would like it to die.
Coming to the site from an aggregator (and needing to be convinced to use Ash, rather than coming there directly and already knowing I want to use ash) I found the book a little weird to be so front and center.
I would have really hoped for a small code snippet or screenshot showing how powerful the framework was. And a book a little further down from that would be nice. But "pay to learn" before "here's a quick snippet on why ash is neat" would have made me more excited for this thing I hadn't heard of before, and who's website I was visiting to learn about.
---
Seeing a book first gave me a different impression -- like one of the old snooty languages/tools from twenty years ago that was really enterprise-only.
I can tell that's not the vibe Ash is aiming for, but it's what I picked up!
(Somehow, I also couldn't find the documentation link on the first two tries. But that's also my eyes being weird and missing the sticky header where it clearly says Documentation!)
Example: https://vertx.io/
This is not a new problem. It is exactly what a web application framework like, e.g. django has been handling for one and a half decades.
What does it do that django doesn't?
A lot of competitors to django have also fallen behind because they either railroad you too much (e.g. by making immutable assumptions about how you want authentication to work which often end up being faulty) or go too far in the other direction and require an excess of boilerplate. This is a very subtle and tricky trade off that most newcomers to the space fail badly at.
I’d consider Phoenix to be like Flask. Ash fills the gap that brings Phoenix up to feature parity with a batteries included framework like Django.
Ash Admin (Django admin), Ash Resource & Domain (Django models & ORM), Ash JSON (Django Rest Framework), Ash Auth (Django Allauth), Ash Phoenix (Django Forms), Ash policies (Django permissions)
But you aren’t required to use Phoenix with an Ash project. Ash will happily work as a standalone CLI, terminal app or some other Elixir web framework that comes out tomorrow.
The forms https://hexdocs.pm/ash_phoenix/AshPhoenix.Form.html seem even more low level than Django forms, and those are notorious for being too low level and annoying to work with. This to me seems to run counter to the tagline. Compare with iommi for Django where you can truly "derive the rest" from the domain model to get forms and tables.
Thanks. This is exactly what the website should say!
Exactly! That's a great way to think about it in Django terms.
Hi Josh!
Scott from the Gig City conference ;)
Oh hey Scott! :)
They really should put something to that effect on the homepage.
Unlike Django, Ash is not a web framework, it’s an *application* framework.
One way to think of it is that it’s a flexible and extensible domain modelling language that also happens to derive an Elixir application which can be called from Phoenix web UI (or something else like an API, a terminal UI or even an MCP server.
so ruby on rail??
Rails are definitely inspiration for the way Ash DSLs are used to model your business domain, but Ash takes this idea way further.
Ash models nouns and relationships like ActiveRecord does, but it also models Domains (think DDD bounded contexts) and Resources with the verbs or "actions" of your system.
It also lets you configure generated APIs and your data layer (eg Postgres) so it doesn't stop at just how an ORM may typically model your data.
Always cracks me up. In previous life I worked in creative agency and we had a Project Manager called Ruby. Sometimes parties were getting out of hand and she got a nickname Ruby on Rails when she dropped a baggie on the table and made herself two lines (rails) with company credit card.
We've always had trouble with this. The closest thing to Ash I've seen elsewhere is an ORM. It's not an ORM though.
Ash is a declarative application framework. You define your application logic using Ash.Resource, which model things like state, but most importantly actions.
Another analogy is that it's similar to GraphQL, but lowered down to the backend layer. It's a declarative, typed application description and implementation framework, that you can derive a GraphQL from (amongst many other things).
Another way to think of it is a whole ecosystem of packages that standardize the vast majority of things you want to do when building an Elixir backend, instead of trying to kludge together a bunch of different tools. Pagination, sorting, filtering, authentication, authorization, all builtin and designed to work together.
That's certainly more helpful, yeah! My biggest complaint is that that's really not particularly obvious from the home page; I didn't realise the highlighted words in the lead were links, and they're all to a diverse set of locations, which I'm unlikely to check out if I just want a ten-thousand-foot view of the framework.
I'd suggest putting a description similar to your last paragraph on the home page, and including a brief example of what that translates to. Phoenix's website [0] does this beautifully: within the first page of scroll, I immediately know what it does and how it looks, and the following pages of scroll give me the detail I need to evaluate it properly.
[0]: https://www.phoenixframework.org/
I will go in and add another section that expands a bit more on what Ash is after ElixirConf EU is over. Thanks for the feedback!
This repository from the Ash book gives you an example of what it can do.
Model.
https://github.com/sevenseacat/tunez/tree/end-of-chapter-10/...
View.
https://github.com/sevenseacat/tunez/tree/end-of-chapter-10/...
I hear what you say. I personally blame the flurry of BS js "frameworks" that have more effort put in their Apple-wannabe front page than in actual practical engineering. I think they've setup a weird standard for framework front page that this one seems to follow. I don't blame the Ash guys, I blame the people who created the trend and those supported who it. I look at you, JS community.
(Yeah... this is 100% a rant, sorry)
I've always been a fan of Model Driven Development (MDD), which is by today's standards an ancient paradigm. You define the core data model (resources), properties (attributes), and actions, and auto-generate the UI/API. It was more popular back when OOP first met Web Development. It seems to have fallen to the wayside with manually constructed "fat controllers" being the dominant way to organize web apps today. I have my own framework in MDD style. For a long time I've told people "I can code at the speed of thought." My apps are 80% the data model, 20% the UI, with the middle layer almost entirely generated. Tools like GraphQL, Supabase, and auto-admins kind of go in the same direction.
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)
> sh <(curl 'https://ash-hq.org/install/ai_personal_chef
Thanks no thanks.
Is installing Rust any different?
https://www.rust-lang.org/tools/install
I ran the install link in the home page and got an empty phoenix project. How am I supposed to understand what to do next? How to add a resource/domain etc. I thought it was a full example. Or at least I'd get a CLI tutorial to create my first resource i.e.
As many people seem confused, it seems that this framework is a declarative framework (think: expressing a solution like you would in SQL or Prolog), in Elixir, that seems to have the goal of separating out core logic from control flows within web apps, APIs and so on.
Over the course of 15+ years of playing with Rails, I've come to the view of CRUD being a poor choice for most real-world applications and MVC being a useful but often-abused concept. That took me down a bit of a rabbit hole of trying to think about DDD within the constraints of an opinionated framework that thinks CRUD and MVC are the thing that makes you go fast. I, on the other hand, want the thing that makes it easy to extend and maintain. I want actual events to be modeled for all sorts of real-World reasons.
I've been learning Elixir recently because it's something new, the actor model appeals from a concurrency perspective to some of the problems I want to solve, and because Phoenix looks like an interesting and elegant web app framework. However, there was a nag in the back of my head that I'd just end up hitting the same frustrations: I was, and am, ready for that and seeing if anything about Elixir + Phoenix makes life easier than Rails made it.
Ash seems to be a good candidate for part of the puzzle. A declarative framework that brings some packages for useful, often-needed parts of the puzzle (like authentication, authorization, and so on), and it seems to encourage a way of thinking about some key DDD concepts. Resources sound like domains or bounded contexts. Declarative style sounds like it might lend itself to event modeling more easily. Calculated values are a nudge towards "view models".
Never tried, I'm early on my journey, but I think the Ash book will be the first thing I pick up after I've finished the Elixir and Phoenix books I'm reading through. Curious to hear stories from people further down this journey, though!
I have shipped half a dozen projects based on Phoenix, Ecto and Live View. I love them all, and the language itself the most.
What does Ash Framework offer me? What pain points that I don’t think I have does it solve for me? This I still do not understand.
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
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
FWIW, I have the book and I've found it a really good read so far.
Stylewise, It reminded me of reading the original PragProg Rails book back in the day.
It's mostly finished. I just saw it's 40% off this week with the code 2025PERSPECTIVES at https://pragprog.com/titles/ldash/ash-framework/
Always happy to hear about people liking the book!
I am a total noob, ok programmer but not a very good developer.
I'm coming to Phoenix with a Django background and I really enjoy what I've been messing around with so far, but I haven't done anything serious with it.
When I hear people say "ash is like an orm" then that fills me with dread. I actually come to enjoy how elixir/Phoenix/ecto has done things
If I'm trying to build something ie a news aggregator site (like hackernews ) - how would "make it in ash" help me? If it does things for me, does that mean I lose control of those things? Or they are hidden behind some macro magic that I have to pull apart to get to?
"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.
Right and unlike an ORM which only models the "nouns" and "relationships" of your business domain model, Ash also models the verbs.
This allows it to reveal the actions of your system externally via GraphQL or JSON API as well as modelling the data for your relational schema (although data layers are swappable and are not always relational).
1. Does Ash supports CQRS/ES architecture?
Or alternatively can it be combined with a framework like Commanded?
2. How customizable is GraphQL layer? Specifically error handling/idempotency for mutations?
AshGraphQL (https://github.com/ash-project/ash_graphql) errors are relatively customisable
https://hexdocs.pm/ash_graphql/handle-errors.html
Ash models an application's verbs or operations as actions. This allows the production of events via an "Aspect Oriented" way of hooking into the action lifecycle.
Although it doesn't support a command first Event sourcing approach, AshEvents (https://github.com/ash-project/ash_events) does help produce events that could be replayed.
Torkild wrote an article about his latest updates to AshEvents here:
https://alembic.com.au/blog/ash-events-event-sourcing-made-s...
I'd love to hear from someone who's shipped a product into production with Ash. I've been considering using it for a new project but I'm a bit weary of introducing a whole second language. With it being macro based rather than functions, I can't help but think it might be tricky to break out of for areas where its opinionated approach don't fit so well.
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.
weary (tired) -> wary (cautious / afraid)
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.
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.
With the caveat that I’m still learning elixir+ash and just building a small private project, I’ve bought the beta book and it really helped get my head around the concepts even though it’s not finished. I’d recommend it, it’s even on sale at pragprog this week.
Ash itself is fantastic so far. I haven’t worked with anything so productive before. Loving it.
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.