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've built many custom business applications and consistently observe the same pattern. Our clients want to—and should—focus their investment on innovative features that deliver unique business value. Yet traditionally, significant effort gets consumed by "commodity" functionality that doesn't differentiate their product.
These necessary but standard components often require teams to reinvent solutions that already exist across thousands of applications. Our clients rightfully question investing heavily in these "below the waterline" elements when they should be allocating resources toward their competitive advantages.
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 minimising time spent below it. The framework accomplishes this by modelling your domain and deriving everything else.
What is Ash Framework?
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 modelling 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. 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 focuses 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 creates hesitation for developers considering Ash for their projects. However, what seems like dark magic is really 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. 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 behaviour. With Ash, what you see is what you get - your resource definitions explicitly state the capabilities, relationships, and behaviours 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.
Want to learn more about Ash? Here’s everything you need to know about Ash Framework.
If you need more active guidance Alembic’s Ash Premium Support service provides a direct line to our team of Ash Experts for fast, high-quality support that improves your knowledge and speeds up delivery.
