Learning Ash: Declarative Elixir Apps, Testing and Extensibility

Christian Alexander hosts Rebecca Le and Zach Daniel, co-authors of a book on the Ash Framework for Elixir. They discuss learning the framework, its extensibility, testing and the community libraries built around it.

Le says she has used Ash since early version 1 and works on its core team, documentation and user-interface libraries, including the Cinder data-table library. Daniel describes building Ash and learning from Le’s constructive criticism while her team used early versions on client projects.

Alexander says he struggled to learn Ash because he started with relationships and permissions before understanding the application. The book helped him follow a more gradual path. Le says that progression was intentional: the framework’s pieces existed, but learners needed to see how they fit together.

The book starts with domain modeling and introduces authentication, policies and testing as the example application needs them. Le stresses adding security and tests before deployment and real users, even if they are not the very first concepts taught.

The music application Tunez gives the book room to demonstrate relationships, testing and atomic operations without requiring readers to create large amounts of content. Le says the authors traded off other possible examples and features to keep the book manageable.

Alexander observes that familiar building blocks can support later additions such as TypeScript bindings and AI tooling. Daniel says extensibility was an explicit early goal: extensions can add capabilities or change how actions work, while the core concepts remain useful.

Because the ecosystem was changing quickly, the authors questioned whether it was too early to write foundational material. Daniel says they sought stability for the book’s examples, and that the concepts largely remained stable even as options and extensions grew.

Daniel recalls users who had read the policies guide but still struggled to apply it. A complete reference is valuable, but a learning path with a concrete application can make abstract rules easier to connect to practical decisions.

Daniel compares a framework with strong defaults to a prepared meal and Ash to a customizable bowl: teams can combine extensions to fit their use case. He cites event-driven extensions as an example of changing how actions are implemented.

Writing the book changed the framework. Le says the authors initially omitted testing guidance because Ash applications were ordinary Elixir applications, but users repeatedly asked how to test their actions. Their attempts to explain the process led to generator-based test-data support and a testing chapter.

Daniel says that when he tried to explain the existing testing approach, he realized tooling was missing. Rather than merely documenting an unsatisfactory process, the team built features that made the approach easier to use and teach.

Alexander values testing the central actions because different interfaces and APIs build on them. The speakers describe how declared policies and actions provide a common foundation, while practical tests still matter for the behavior an application relies on.

Le explains why she built Cinder: applications repeatedly need searchable, filterable, paginated tables. She prototyped an abstraction that composes filters, generates interface elements and queries data; the library has since gained more customization.

Daniel says his team replaced a homegrown table implementation with Cinder and removed code. He finds it rewarding to use a community contribution he did not design himself, and cites Ash Authentication as another example of the ecosystem’s shared work.

Alexander describes migrating an application by representing database tables as resources and replacing large context modules with a domain, resources and access patterns. In his experience, common abstractions make it easier to add capabilities, though the work still depends on understanding the model.

The group describes an upfront learning curve around Ash’s DSL and concepts. Le contrasts that with tools that are easy to start but may become harder as requirements grow. Once a developer understands resources, actions and policies, the speakers say those ideas recur across extensions.

Alexander highlights nested forms in the book’s music example: songs can be created while creating albums using Ash Phoenix helpers. Daniel adds API generation as another example of deriving an interface from domain modeling.

Daniel cautions that a single line exposing functionality through an API can do a great deal. The convenience is powerful, but engineers need to understand what it exposes and how authorization applies. His lightsaber analogy captures both the learning investment and the potential consequences of misuse.

Daniel reports that AI assistants and existing examples have helped new engineers at his company learn Ash and Elixir more quickly, and says simple questions in the community have become less common. These are observations from his team and community, not a controlled measurement of learning outcomes.

Alexander closes by recommending that learners follow the book, build the example and see how the pieces connect. The authors thank him and the audience.