Ash Framework is revolutionizing software development on many fronts. It saves countless hours of development while giving you the flexibility you need to adapt your application to evolving business requirements — at a pace you're unlikely to find in other frameworks.

To truly benefit from it, however, you need to "think in Ash" so you can deliver better software, faster.

I came to Ash Framework after using Laravel, CodeIgniter, Django, and the .NET Framework. While working solo on an HR application, I accomplished in three months what previously would take a team of four people to achieve in the same period. Initially, I was held back by the mindset I brought from those other frameworks, but the moment I learned to "think in Ash," my approach to software development changed dramatically. My throughput increased, and the quality of code improved significantly.

The goal of this series of articles is to help you — and other developers — think in Ash with the support of real-life features currently in production. By doing so, you can take full advantage of the Ash Framework and deliver software that is both reliable, secure, and maintainable, without experiencing the same hurdles I faced.

In this serie of articles, we'll be building below multi tenant help-center application that will actually be used at help.zippiker.com

This series assumes that you have installed the Ash Framework alongside the Phoenix Framework. If you haven't installed it yet, feel free to pause here and follow the instructions at https://hexdocs.pm/ash/get-started.html to get set up.

Another Way of Looking at a Framework!

I used to think of frameworks as "all-in-one" solutions. From Laravel to Django, you often get the frontend, backend, and database in a single framework — enabling you to build end-to-end applications without leaving that ecosystem. However, Ash is unique.

The Ash Framework sits at the heart — or core — of your application.

It's a layer that ensures everything in your application remains consistent and aligned. In most applications, this is where all your business logic converges, allowing the entire system to work harmoniously.

This layer maintains data consistency, handles business logic, and ensures uniformity across your application. While some people put this logic in models, others in repositories or services — or in multiple different places — Ash was designed specifically for this task so to say as an Ash developper. Consequently, you'll need to pair Ash with other frameworks like Phoenix to build a complete, functional application end users can use.

As an application framework, Ash ensures your business logic remains centralized, reliable, extensible, and atomic in nature.

Ash has its own domain-specific language (DSL) built using Elixir macros. Simply put, it introduces a set of predefined keywords but uses Elixir's syntax — such as Resource, Domain, Action, Attribute, Preparations, and Changes. Because of this, you'll need to know Elixir before you can use the Ash Framework.

Describe(Model) Your Application

Ash allows us to describe — or if you like, model — our application using different categories of files (resources, domains, actions, policies, preparations, and more).

Through its powerful tooling, you can then generate the rest of your application logic. If you need to make changes down the line, you simply modify the corresponding files, and you can rest assured that your changes will be reflected everywhere.

When we talk about modeling your application, we're referring to using specific keywords to represent how your application works, which validations to apply, how to authorize various actions, and so on. You do this from a single point, ensuring that your entire application remains consistent and is in harmony.

Think of how you use a .yaml file to describe your GitHub workflows and let GitHub handle the execution, or how you configure Terraform for infrastructure as a service. Ash works almost the same, but for your Elixir softwares' business logic.

To describe your application, Ash uses at minimum Domains and Resources. A resource is a representation of data structure, in other frameworks it's a model. In a typical application a resource represents a table in the database, but it can also represent a CSV file or an API, while the domain is like the facade to group related resources together.

So, let's take a closer look by describing our domain and resources under it.