Ash Domain functions - best practices / approach

I don’t know what would be considered best practice, but I’d almost certainly implement this as a read action against the tanks resource using a warehouse (or warehouse id) as an argument, then expose the action via a code interface.

I happened to have this page open on another browser tab: Actions — ash v3.29.3

when you define a read action as a code interface you can also pass in a load

e.g. if you have

defmodule Domain do

  resource do
    resource Warehouse do
      define :get_warehouse, action: read, get_by: :id
    end
  end
end


Domain.get_warehouse(id, load: [:tanks]) 

That will give you the warehouse including the tanks

I’ve personally used the load option to get all the data in one place. Or if i really needed to load data later down the line I called Ash.load(resource, :rel) directly.

I realized that @zachdaniel had already given me pointers on this a while back - using a generic action.

My issue is that “read” actions are essentially queries that start with a universe of resource records and narrow it down & refine the set based on the filters, preparations, etc.

In this case, I simply want a functional way to get into the internals of a resource struct without flavoring the use of that function with Ash and other internal structural knowledge.

So a generic action paired with a define seems to work.

In the domain:

define :get_tanks_in_warehouse, action: :get_tanks, args: [:wh]

And in the resource:

  action :get_tanks, {:array, :struct} do
      constraints items: [instance_of: Flow.Model.Tank]

      argument :wh, :struct, allow_nil?: false, constraints: [instance_of: __MODULE__]

      run fn input, _ ->
        {:ok, wh} =
          input.params.wh
          |> Ash.load([:tanks])

        {:ok, wh.tanks}
      end
    end

This seems worthwhile as I intend to use it with ash_json_api.

Keen to hear if others think that makes sense and if there is a better approach to take.

Thanks
Martin

Using generic actions like this can be good, but it won’t work with ash_json_api because it’s not possible to provide a struct as input to an action. So to put this over an API you’d want the argument to be an id.

Separately, there is a thing called related routes that is exactly for this purpose that uses the primary reads of the relevant actions and then there is no need for the action at all (for ash_json_api).

Thanks. I found the related routes “feature” a few weeks ago.

So, in general… should I be wary of writing pure Elixir functions in the “Domain” module that simply use the defined functions and Ash semantics as needed to create the wanted behavior. So in this case, I am not sure that it was much of an improvement from the origin al simple function to the generic action wrapped via the define. Obviously the latter gives me all of the ! variants and the “can” helpers, but I am keen to get a sense of how often you (and others) simply extend the domain with plain Elixir functions.

Thanks again to you and the others in this forum for creating such a vibrant and supportive community.

Martin

Nothing wrong with writing those functions, just up to you if you need the benefits of a generic action or not Functions are a simple tool and often using a simple tool is good. Since you’re aware of what you can get from generic actions, you can ultimately decide whether or not you need a generic action or not.

I personally error on the side of making generic actions and when I need functions they typically exist for a reason and I group them in some way to indicate that reason. Like if I have common helpers for building a UI I might put those in their own module MyApp.MyDomain.LiveViewHelpers or something along those lines. But when in doubt, finding a way to either extend an existing domain action or create a new one often yields better fruit down in the long run.

Very clear and practical. Many thanks again.