Ash: when to use Registry, and what are the advantages?

My understanding of how Ash works is that

  • the basic unit that has “internal structure & logic” are the Resource.
  • zero or one DataLayer can be specified for each Resource.
  • the API (like an Elixir Context) provides entry points to the Resources it guards. This can be through (changeset-mediated) actions defined on the resources, or through extensions, JSON/GraphQL etc.

What I understand is that within an API, Resources can be grouped using a registry:

What I don’t understand is when I should be doing that, and what the advantages are (the docs doesn’t really answer that for me). What is the best practice around Registries, and at what scale would it make sense to use them?

3 Likes

Mostly registries were a compile time optimisation that helped break circular dependencies. With recent compiler improvements both in Elixir and Spark they can be removed in almost cases. There are some cases where they’re still needed (usually extensions doing things that would otherwise break) but you’ll know when you need them. The rule of thumb is now that they’re generally not needed.

5 Likes

From @zachdaniel on the discord group:

First thing to note, we actally don’t need registries anymore. I’ve been steadily removing them from examples in various places.

You can do

defmodule Api do
  use Ash.Api

  resources do
    resource Foo
    resource Bar
  end
end

There is only one use case that needs registries (the experimental ash_paper_trail)and it is being updated to use resources instead .

Documentation is also steadily being updated to remove registries and according to Zach they will possibly be removed for Ash 3.0

3 Likes

Aha! I was just today trying to understand what registry was used for (cause I could find nothing).

2 Likes