Ash Framework was created to solve a fundamental problem in application development. When you build a new app, you want to focus on the valuable, innovative parts - what's visible above the waterline of the software development 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.
At Alembic we build business application for our customers and we build many projects that highlights this challenge. All our customers want to focus on the innovative, 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.
Surely you don't have to spend time building logins, you've done this before right? -- a typical software client customer
Authentication is a perfect example - most clients 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 modeling your domain and deriving everything else.
What is Ash?
After three years of refining its message, we've settled on the following ways to explain what Ash is and what it can do. Ash can be described as:
A declarative application framework (it's not a web framework)
Resource-based, focusing on the nouns and verbs of your system
UI layer agnostic (use Phoenix or something else if you'd like)
Data layer agnostic (allowing interchangeable data layers)
Ash concentrates on modeling your domain and business logic, avoiding the busywork and boilerplate that doesn't directly support that goal. You can think of Ash as a flexible and extensible domain modelling language which also happens to generate an Elixir application.
The framework uses DSLs (Domain Specific Languages) throughout, and the big idea is that once you've declared your system using Ash DSLs, it becomes introspectable. From this introspectable data structure, you can derive practically anything you can imagine.
The Big Idea behind Ash
The core concept is straightforward:
You write your system using Ash DSLs
This creates an internal Elixir data structure
Ash enables introspection of this structure
From this, you can generate numerous components
Another way to think about it: Ash focusses on the application layer (the middle red layer) and from there derives ways to present your app to the world - Ash Phoenix helpers, admin interfaces, APIs, and more. You can even swap data layers as needed.
By keeping all your business logic within the application layer, Ash helps you build more maintainable, focused systems.
The Myth of "Dark Magic" in Ash Framework
One common misconception about Ash Framework is that its extensive use of macros and DSLs constitutes some kind of "dark magic" - complex, inscrutable code that works in mysterious ways. This perception can create hesitation for developers considering Ash for their projects. However, what seems like dark magic is in reality much simpler.
At its core, Ash's macros serve a straightforward purpose: they transform your declarative definitions into well-structured data that can be easily traversed and inspected. The DSLs may feel like another language at first, but they're fundamentally just Elixir - you're not learning a new language syntax, but rather a structured way of using Elixir's existing capabilities.
Spark, the library that Ash uses to define its DSLs, is where the macros are written for you. But these macros are simply responsible for creating a large but simple data structure which can be introspected. This introspectability is the true power of Ash. While code itself is difficult to meaningfully introspect, the data structures that Ash creates allow for rich analysis and generation.
Think of it this way: when you define resources in Ash, you're not writing magic incantations - you're building a blueprint. Once your blueprint is complete, Ash can read it to automatically generate APIs, documentation, UIs, database migrations, and much more. The only limit is your imagination.
This approach stands in contrast to frameworks that rely heavily on convention or implicit behavior. With Ash, what you see is what you get - your resource definitions explicitly state the capabilities, relationships, and behaviors of your system. The "magic" is simply the framework's ability to understand and extend those definitions.
For developers new to Ash, embracing this concept makes the learning curve far less intimidating. Rather than mastering an arcane system, you're learning how to express your domain model clearly and consistently. The initial investment in learning the Ash patterns pays significant dividends as your application grows in complexity.
As Arthur C. Clarke famously stated, "Any sufficiently advanced technology is indistinguishable from magic." Once you understand the underlying principles of Ash, the magic fades away, revealing a powerful but ultimately straightforward tool for building sophisticated applications with less effort.
