Discovering the Ash Framework

The Ash Framework now it has a stable API!

Bill Tihen

Last updated on Sun, 05 May 2024 Code, Elixir Language, Ash Framework

I’m always on the lookout for good ways to organize large and complex codebases.

I’ve been curious about the Elixir Ash Framework and with the current ‘stable’ release, I decided to spend part of my vacation to explore and hopefully learn Ash. To explore and remember what I learn I am writing myself an Ash Tutorial - example based more than full explanations. Perhaps this will interest you too.

Purpose

This tutorial tries to build on existing tutorials and documentation on Ash and present enough code examples and explanations, that a beginner (like me), can successfully build an application.

The idea is to build a relatively simple Ash app (a Support Ticket system), and integrate it with a Phoenix web application. And then provide alternative API (GraphQL / Json) - to make the app available to say a mobile App.

Overview

Having played with Ash a bit now, it nicely separates the Data Layer and Business Logic, the Access APIs AND facilitates common needs / patterns, ie:

Validations & Constraints
Queries (aggregates, calculations)
Authentication (not yet authorization)
… Without excluding standard elixir tooling. I haven’t tried this, but Ash claims to be easily extensible.

Given the flexibility of Ash’s uses of resources, we will start with a very simple organization (similar to rails - resources will reflect database tables that are directly acted upon. Once the App gets a bit more complicated (and our resources get a annoyingly large), we will restructure the app to reflect a more modular approach.

NOTE: A resource based app that separates the Data Layer, Business Logic and Access Layers is a new fresh approach, but takes a bit of rethinking.

In the Thinking Elixir Podcast # 123 Zach describes the design of Ash to be Declarative Design designed to preserve functional mindset and splits applications into two aspects.

Resources - a description of attributes and what actions are allowed (what is required and what should happen)
Engine - follow the instructions of the resource

However, I like to think of Ash as having four Layers:

Engines - The Ash engine handles the parallelization/running of requests to Ash.
Application APIs - external access to data and actions (AshActions, AshJsonAPI, AshGraphQL, etc)
Resources - a description of what should happen (actions allowed and the data required)
Data Layer - data persistence (in memory, ETS, Mnesia, PostgreSQL, etc)

Ash Structure

Long-term our system will need users, tickets and comments.

For now we need to create the minimal infrastructure needed by Ash, this includes:

An Ash Resource - the core workable aspects of our data and its associated information.
An Ash Registry - of the Resources and extension the API has access to (basically binds the application together).
An Ash Api - ways to access and manipulate our Resources

Resources

Documentation

Ash Framework 1.5 - Video and Slides

Elixir Ash Phoenix GraphQL JSON API