Hacker News Reader

Comment by borromakot | Hacker News Reader

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.

View on HN

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!

Yes, this is a good description. The way I explain it is that "Ash is a declarative, composable application framework."

It is the middle layer between DB (Ecto) and Phoenix (with or without LiveView) -- where your actual application lives.

The difference between a Resource and a Model (or ActiveRecord) is Models typically define attributes and relationships vs a Resource defines attributes, relationships, actions (read, write, destroy, custom...), behaviours (i.e. multi-tenancy, jobs) and what I call facets (i.e. JSON api, GraphQL).

When you read the code for a Resource, you grok all of this in a nice, consistent way (we have 100* resources - all are consistent). This is because of the DSL.

When compiled, it all boils down to a Struct that you can easily inspect. That Struct enables all kinds of stuff.

Reply on news.ycombinator.com