DEV Community: Artur Plysiuk

From Database Factories (Like ExMachina) to Business State

Artur Plysiuk — Mon, 12 Oct 2026 19:28:00 +0000

I came to Elixir from Ruby, as did most of my team and many Elixir developers at the time. When we needed test data for Ecto, we were literally looking for FactoryBot for Elixir. ExMachina was presented by FactoryBot's creators as exactly that, so we added it without questioning the choice.

FactoryBot and ExMachina organize test data around models or schemas: define their attributes and associations, then build or persist them. That is what I mean by database factories in this article. The plain helpers in Ecto's test factories guide fit the same model.

The problem is the model itself, which looks good in Hello World examples but forces you to work around it in a real business application.

Automatic associations build the wrong graph

Suppose a project, its owner, and its manager must all belong to the same organization:

A typical ExMachina implementation looks like this:

def organization_factory do
  %MyApp.Organization{name: "Acme"}
end

def user_factory do
  %MyApp.User{
    organization: build(:organization)
  }
end

def project_factory do
  %MyApp.Project{
    organization: build(:organization),
    owner: build(:user),
    manager: build(:user)
  }
end

A test then creates a project with one call:

project = insert(:project)

The result contains one project, two users, and three organizations. The project belongs to one organization, while its owner and manager belong to two others. The records satisfy the database constraints, but the business state is wrong.

To create a valid project, the test has to build the graph explicitly:

organization = insert(:organization)
owner = insert(:user, organization: organization)
manager = insert(:user, organization: organization)

project =
  insert(:project,
    organization: organization,
    owner: owner,
    manager: manager
  )

That restores correctness, but it also bypasses ExMachina's main feature: creating the association graph automatically and persisting it from one insert(:project) call. The persistence part mattered in 2015, when Ecto could not yet insert such a graph itself. After Ecto 2.0 added support for it, ExMachina removed most of its Ecto-specific code and delegated insertion to MyApp.Repo.insert!.

Once associations are inserted and passed explicitly, the factory library is no longer needed. The remaining code fits the small helper pattern from Ecto's documentation:

def build(:user, attributes \\ []) do
  %MyApp.User{name: "Jane"}
  |> struct!(attributes)
end

def insert(factory_name, attributes \\ []) do
  factory_name
  |> build(attributes)
  |> MyApp.Repo.insert!()
end

These two functions cover the useful core of a database factory. The vast majority of ExMachina's remaining API is unnecessary.

I tried to make ExMachina reuse associations

Our tests were not as fast as I wanted them to be. When I traced test setup, I found that the automatic association behavior shown above was producing an embarrassing number of unnecessary records. Removing ExMachina from the existing suite was not a small change, so I tried to reduce those inserts without abandoning it. Here is a simplified version using the schema from the example above:

def maybe_insert(%{__meta__: %{state: :built}} = value) do
  ExMachina.EctoStrategy.handle_insert(value, %{repo: MyApp.Repo})
end

def maybe_insert(value), do: value

def maybe_get_assoc(nil, _association), do: nil

def maybe_get_assoc(value, association) do
  value
  |> MyApp.Repo.preload(association)
  |> get_in(association |> List.wrap() |> Enum.map(&Access.key!/1))
end

def project_factory(attrs) do
  owner = maybe_insert(attrs[:owner])
  manager = maybe_insert(attrs[:manager])

  organization =
    maybe_insert(attrs[:organization]) ||
      maybe_get_assoc(owner, :organization) ||
      maybe_get_assoc(manager, :organization) ||
      insert(:organization)

  shared_user = owner || manager || insert(:user, organization: organization)

  %MyApp.Project{
    organization: organization,
    owner: owner || shared_user,
    manager: manager || shared_user
  }
end

The workaround improved performance in parts of the suite and produced more consistent association graphs, but it remained low-level and incomplete. If both owner and manager arrived as built structs, each could bring its own automatically built organization. Handling that case required more traversal and association replacement. I was already writing a dependency planner inside ExMachina.

Let the application create the state

A business operation can say more in a few words than a bunch of inserts. With direct inserts, starting a conversation means creating a thread, two participants, the first message, and a read marker for its author:

thread = insert(:thread)

insert(:thread_participant, thread: thread, user: author)
insert(:thread_participant, thread: thread, user: recipient)

message =
  insert(:message,
    thread: thread,
    sender: author,
    body: "Hello"
  )

insert(:message_read, message: message, user: author)

The message_read record is easy to omit because it looks optional, or simply because the author forgets it. Enough small omissions like this, and tests begin from states the application itself never creates.

The test can instead call the application operation that already creates a valid conversation:

%{thread: thread, message: message} =
  MyApp.Chat.start_conversation!(author, recipient, %{body: "Hello"})

The application operation already knows how to assemble this state. If the persistence model changes but starting a conversation does not, tests that call the operation do not have to change with it.

Calling business functions can make test setup slower than direct inserts, but a fast test that starts from the wrong state is not useful. Saša Jurić reported that after banning ExMachina from new client projects and using context functions instead, their tests became simpler and more reliable.

One interface for business operations

In another codebase, I did not add ExMachina. I wrote a params_for helper that took an operation name and optional overrides:

def params_for(:create_project, overrides \\ %{}) do
  %{
    name: random_string(),
    description: random_string()
  }
  |> Map.merge(overrides)
end

A test used it like this:

create_project_params = params_for(:create_project)

project =
  MyApp.Projects.create_project!(
    create_project_params,
    %{
      organization: organization,
      owner: user,
      manager: user
    }
  )

params_for could generate inputs for an operation that created several entities, but it could not create or pass that operation's dependencies.

The helper was global, so :create_project had to be unique across the application. The name already identified the operation, but every test still had to pair it with MyApp.Projects.create_project!/2. My next prototype put that pairing in one map:

%{
  create_organization: %{...},
  create_user: %{...},
  create_project: %{
    params: %{
      organization: fn -> raise "specify manually" end,
      owner: fn -> raise "specify manually" end,
      manager: fn -> raise "specify manually" end,
      name: &random_string/0,
      description: &random_string/0
    },
    resolve: fn args ->
      project =
        MyApp.Projects.create_project!(
          Map.take(args, [:name, :description]),
          Map.take(args, [:organization, :owner, :manager])
        )

      %{project: project}
    end
  }
}

Nothing in this registry depends on Ecto. A resolver can write to any storage system or avoid persistence entirely.

I added exec/2 to look up the operation, generate missing parameters, merge explicit values, and call its resolver with one map. Tests now had one interface while the application function kept its original API:

%{project: project} =
  exec(:create_project,
    organization: organization,
    owner: user,
    manager: user
  )

This version of exec returned the resolver's result directly and removed the separate params_for call, but callers still had to supply associations. ExUnit setup already provided a shared map for them: each callback receives the context and returns values merged back into it. I changed exec to read matching parameters from that context and return the updated map:

context = %{
  organization: organization,
  owner: user,
  manager: user
}

%{project: project} = exec(context, :create_project)

The context-aware exec merges the resolver's result into the context and returns the updated map, so commands can be piped together:

%{organization: organization, user: user, project: project} =
  %{}
  |> exec(:create_organization)
  |> exec(:create_user)
  |> then(fn context ->
    Map.merge(context, %{owner: context.user, manager: context.user})
  end)
  |> exec(:create_project)

This worked, but every test still repeated the dependency order and the manual mapping from user to owner and manager.

From commands to entities

The registry still did not record that one command's output could satisfy another command's input. I solved that by assigning an entity name to each value stored in the context.

An entity name identifies a role in the test context, not a database type. A client owner and an internal manager can therefore be separate entities even when both are stored in the same users table. In the simpler schema below, both roles deliberately refer to :user, so one record fills both roles.

To describe and validate the entities produced and required by each command, I replaced the map registry with a DSL built with Spark and added a dependency-resolution engine.

That implementation became SeedFactory (GitHub, documentation). Here is the same registry as a SeedFactory schema:

defmodule MyApp.SeedFactorySchema do
  use SeedFactory.Schema

  command :create_organization do
    param :name, generate: &Faker.Company.name/0

    resolve(fn args ->
      with {:ok, organization} <- MyApp.Organizations.create(args) do
        {:ok, %{organization: organization}}
      end
    end)

    produce :organization
  end

  command :create_user do
    param :name, generate: &Faker.Person.name/0
    param :plan, value: :free
    param :organization, entity: :organization

    resolve(fn args ->
      with {:ok, user} <-
             MyApp.Users.create(args.organization, Map.take(args, [:name, :plan])) do
        {:ok, %{user: user}}
      end
    end)

    produce :user
  end

  command :create_project do
    param :organization, entity: :organization
    param :owner, entity: :user
    param :manager, entity: :user
    param :name, generate: &Faker.Company.catch_phrase/0
    param :description, generate: &Faker.Lorem.paragraph/0

    resolve(fn args ->
      project =
        MyApp.Projects.create_project!(
          Map.take(args, [:name, :description]),
          Map.take(args, [:organization, :owner, :manager])
        )

      {:ok, %{project: project}}
    end)

    produce :project
  end
end

With no entities in the context, exec(context, :create_project) creates the missing dependencies and returns the context with execution metadata. The output below shows only the execution history:

context = exec(context, :create_project)

%{organization: organization, user: user, project: project} = context

IO.inspect(context.__seed_factory_meta__.execution_history)

[#execution[exec(create_project): create_organization → create_user → create_project]]

Both owner and manager refer to the :user entity, so SeedFactory uses the same user for both roles. An organization or user already present in the context is reused.

Dependencies can still be passed explicitly:

%{project: project} =
  exec(context, :create_project,
    organization: organization,
    owner: owner,
    manager: manager
  )

exec/2 starts from a particular command. With produce/2, the test only names the entity it needs:

context = produce(context, :project)

When the schema also contains an independent :announcement branch, a test can request both:

context = produce(context, [:project, :announcement])

This brings the API back to a short declaration of the test data, much like insert(:project). SeedFactory resolves the required command branches, stores their results in the context, and reuses matching entities already there.

Traits describe state

FactoryBot traits are named groups of attributes, and they can also be applied to associations. ExMachina has no trait API. Its README uses derived factories and pipe helpers for similar variations. SeedFactory keeps the idea of a named variation but maps it to a command execution, so a trait can point to a command alone, require fixed arguments, or accept a value:

command :activate_user do
  param :user, entity: :user, with_traits: [:pending]

  resolve(fn %{user: user} ->
    {:ok, %{user: MyApp.Users.activate!(user)}}
  end)

  update :user
end

command :set_user_country do
  param :user, entity: :user
  param :country

  resolve(fn %{user: user, country: country} ->
    {:ok, %{user: MyApp.Users.set_country!(user, country)}}
  end)

  update :user
end

# A trait assigned by the creation command
trait :pending, :user do
  exec :create_user
end

# A transition from :pending to :active
trait :active, :user do
  from :pending
  exec :activate_user
end

# Match fixed command arguments
trait :free, :user do
  exec :create_user, args_pattern: %{plan: :free}
end

trait :premium, :user do
  exec :create_user, args_pattern: %{plan: :premium}
end

# Accept the value supplied through produce/2
trait :country, :user do
  exec :set_user_country, args_pattern: %{country: _}
end

Country is a parameterized trait, so its value becomes part of the entity's recorded state. Requesting the same value does nothing, while another value runs set_user_country again.

Traits are requested declaratively through produce:

# Trait with fixed command arguments
context = produce(context, user: [:premium])

# Transition and parameterized trait
context = produce(context, user: [:active, country: "Germany"])

# New value for the parameterized trait
context = produce(context, user: [country: "Canada"])

IO.inspect(context.__seed_factory_meta__)

#SeedFactory.Meta<
  current_traits: %{
    user: [:premium, :active, {:country, "Canada"}],
    organization: []
  },
  execution_history: [
    #execution[produce(user: [country: "Canada"]): set_user_country],
    #execution[produce(user: [:active, {:country, "Germany"}]): activate_user → set_user_country],
    #execution[produce(user: [:premium]): create_organization → create_user]
  ],
  ...
>

If a required state cannot be recreated through the application's business operations, as with some legacy or intentionally invalid states, a test can still use direct MyApp.Repo calls or a private helper. If the same shortcut is repeated in several tests, it can become a command in the SeedFactory schema, keeping shared setup paths in one central registry.

A natural question at this point is what happens when a test needs two users, since both would be stored under the same :user name. SeedFactory has a mechanism for that, and a few more features I have not covered, but I had to stop somewhere before this article turned into a retelling of the documentation. I wanted to show the reasoning that led to this API.

Final thought

The database-factory model, where tests request records and factories create their associations, is the goto statement of test setup. You can live with it, but it makes the test suite harder to maintain.

You're probably underusing middleware for HTTP response handling

Artur Plysiuk — Sun, 17 May 2026 21:08:32 +0000

When you wrap an external API in Elixir, most of what a function like Acme.fetch_user/1 does is response handling: validate the status, parse the body, translate failures. That code almost always lives after the Tesla.get call, in a case or a handle_response/1 at the end of a |> pipeline.

That's the wrong place. A middleware can return {:error, ...} from Tesla.run, which makes Tesla's telemetry event record the request as failed. A function called after Tesla.get can't do that. It only sees the result. Failures it detects don't reach telemetry, so your observability stack undercounts them.

Code samples use Tesla. Same shapes apply to Req. Pick whichever you're using and translate as you go.

Real APIs don't read their own docs

Real APIs are dirtier than tutorial examples. A few I've run into:

I've seen well-known, large providers respond with bodies that fail to parse. Yup, broken JSON
A field documented as a boolean returns the JSON string "true" for true and, the JSON string "No" for false.
A field documented as a string returns "N/A", or just "", to mean NULL.

Your API client translates external bytes into something your application can rely on, and that parsing can fail. Malformed JSON already makes Tesla return {:error, ...}. A malformed value inside a well-formed JSON is the same failure, one layer up.

The pattern that fails

Here is a fetch_user/1 written in a pattern I see a lot. handle_response/1 is a shared helper: every endpoint in the module funnels through it. fetch_user, create_user, delete_invoice all end with |> handle_response(): one place for the wrap, one place for error translation. Here is just one endpoint to keep the example small.

def fetch_user(id) do
  case client() |> Tesla.get("/users/#{id}") |> handle_response() do
    {:ok, body} -> {:ok, decode_user(body)}
    {:error, :not_found} -> {:error, :not_found}
    _ -> {:error, :service_unavailable}
  end
end

defp handle_response({:ok, %Tesla.Env{status: status, body: body}})
     when status in 200..299 do
  {:ok, body}
end

defp handle_response({:ok, %Tesla.Env{status: 404}}) do
  {:error, :not_found}
end

defp handle_response({:ok, %Tesla.Env{status: status, body: body}}) do
  Logger.error("Acme API returned unexpected status #{status}: #{inspect(body)}")
  {:error, {:unexpected_status, status, body}}
end

defp handle_response(result), do: result

defp decode_user(body) do
  {:ok, created_at, _} = DateTime.from_iso8601(body["created_at"])

  %{
    id: body["id"],
    first_name: body["first_name"],
    last_name: body["last_name"],
    email: body["email"],
    created_at: created_at
  }
end

When the API returns a 500, handle_response/1 produces {:error, {:unexpected_status, 500, body}}, the case falls through to _ -> {:error, :service_unavailable}, and the caller gets a clean tagged tuple. The function itself is doing nothing wrong.

Tesla considers the request successful. The middleware chain returned {:ok, env}. The standard [:tesla, :request, :stop] telemetry event records it as :ok. Tesla.Middleware.Retry, whose default should_retry matches {:error, _}, sees {:ok, env} and doesn't fire. The 500 only becomes an "error" inside handle_response/1's return value and the surrounding case. That's application code, after the request is done.

The Logger.error inside handle_response/1 is a patch for this. Telemetry doesn't catch the 5xx, so someone adds a log line by hand. The error reaches the logs but skips the telemetry pipeline, and every API client module grows its own version.

Body parsing has the same hole. decode_user/1 returns the user map directly and can't signal a parse error. If the API renames email to email_address, body["email"] is nil and the caller gets a user with nil in the email field. If body["created_at"] is missing or malformed, DateTime.from_iso8601/1 returns {:error, _} and the {:ok, created_at, _} = ... match raises a MatchError. Phoenix or Oban catches the exception, but Tesla still considers the request successful and the telemetry event still says :ok.

Middleware can fail the request

When a middleware returns {:error, ...} from Tesla.run, the request short-circuits. The Telemetry middleware emits [:tesla, :request, :stop] with error: reason in the metadata, and Tesla.get returns {:error, ...} (or Tesla.get! raises a Tesla.Error). A handle_response/1 chained after the call only sees the result, so any failure it spots stays out of telemetry.

A 404 from fetch_user/1 means the user doesn't exist, return {:error, :not_found}. A 404 from POST /users means the route isn't there, which is a bug to crash on. Same status, different meaning. The middleware can't decide globally what counts as "ok"; the caller has to declare it.

Doing it in middleware

The middleware takes a per-call map of expected statuses and how to parse their bodies. Here's fetch_user/1 using it:

def fetch_user(id) do
  case Tesla.get(client(), "/users/#{id}",
         opts: [
           parse_body: %{
             200 => &decode_user/1,
             404 => fn _ -> {:ok, nil} end
           }
         ]) do
    {:ok, %Tesla.Env{status: 200, body: user}} -> {:ok, user}
    {:ok, %Tesla.Env{status: 404}} -> {:error, :not_found}
    {:error, _} -> {:error, :service_unavailable}
  end
end

defp decode_user(body) do
  with :ok <- check_required(body, ["id", "first_name", "last_name", "email", "created_at"]),
       {:ok, created_at, _} <- DateTime.from_iso8601(body["created_at"]) do
    {:ok,
     %{
       id: body["id"],
       first_name: body["first_name"],
       last_name: body["last_name"],
       email: body["email"],
       created_at: created_at
     }}
  end
end

defp check_required(body, fields) do
  case Enum.filter(fields, &is_nil(Map.get(body, &1))) do
    [] -> :ok
    missing -> {:error, {:missing_fields, missing}}
  end
end

The middleware behind parse_body:

defmodule ParseBody do
  @behaviour Tesla.Middleware

  @impl true
  def call(env, next, _opts) do
    with {:ok, env} <- Tesla.run(env, next) do
      parsers = Keyword.fetch!(env.opts, :parse_body)

      case Map.fetch(parsers, env.status) do
        :error ->
          {:error,
           {:unexpected_status,
            status: env.status, expected: Map.keys(parsers), body: env.body}}

        {:ok, parser} ->
          case parser.(env.body) do
            {:ok, parsed} ->
              {:ok, %{env | body: parsed}}

            {:error, reason} ->
              {:error,
               {:parse_error, status: env.status, reason: reason, body: env.body}}
          end
      end
    end
  end
end

Parser failures short-circuit with and become failed Tesla requests, not a separate validation step the caller has to remember. They fire the same [:tesla, :request, :stop] event as any other failure, with the error in metadata.

The handle_response/1 helper is gone. The when status in 200..299 guard is gone. The Logger.error is gone too. Telemetry handles the logging now.

{:error, _} in fetch_user/1 swallows the structured errors, so the function doesn't need to unpack them.

Order matters when wiring it in. ParseBody goes after Tesla.Middleware.Telemetry (so Telemetry records its {:error, _} as the request's result) and before Tesla.Middleware.JSON (so the body is already decoded when ParseBody sees it):

defp client do
  Tesla.client([
    {Tesla.Middleware.BaseUrl, "https://api.acme.com"},
    {Tesla.Middleware.Telemetry, metadata: %{service: :acme}},
    ParseBody,
    Tesla.Middleware.JSON
  ])
end

A note on `Tesla.get!`

If retrying or falling back on a transient outage isn't part of how the caller actually behaves, :service_unavailable is ceremony. Application code doesn't pattern-match {:error, :service_unavailable} on every Repo.get/2. We assume the database works; if it doesn't, the request crashes and the supervisor or web framework deals with it.

You can apply the same discipline to an external API. Use Tesla.get! instead of Tesla.get, drop :service_unavailable from the contract, and let any failed request become a Tesla.Error exception. Phoenix turns it into a 500. Oban retries the job. The two clauses left in fetch_user/1 collapse to:

case Tesla.get!(...) do
  %Tesla.Env{status: 200, body: user} -> {:ok, user}
  %Tesla.Env{status: 404} -> {:error, :not_found}
end

Whether to do this depends on the API's stability and the caller's context.

When it wants to be data

Most parsers are boilerplate: required fields, ISO timestamps, nullability checks. A schema handles that better than a function. tesla_middleware_mold and Mold give you that. fetch_user/1 with a schema:

def fetch_user(id) do
  case Tesla.get(client(), "/users/#{id}", opts: [mold: %{200 => user_schema(), 404 => nil}]) do
    {:ok, %Tesla.Env{status: 200, body: user}} -> {:ok, user}
    {:ok, %Tesla.Env{status: 404}} -> {:error, :not_found}
    {:error, _} -> {:error, :service_unavailable}
  end
end

defp user_schema do
  %{
    id: :string,
    first_name: :string,
    last_name: :string,
    email: :string,
    created_at: :datetime
  }
end

200 => schema runs Mold.parse/2. 404 => nil accepts the response without parsing. Anything else fails the request.

The function shape Mold accepts as a parser is the same one the middleware accepts (body -> {:ok, term} | {:error, reason}), so you can mix schemas with hand-written parsers in the same map, depending on which is cleaner for which response.

Nothing in this article requires tesla_middleware_mold. The hand-rolled ParseBody above is around 20 lines once you collapse the formatting; dropping it into your own codebase gives you the same telemetry behavior. Reach for the library when you also want to stop hand-writing parsers.

Writing dynamic Ecto queries with Composite

Artur Plysiuk — Mon, 19 Feb 2024 18:46:02 +0000

There is already an existing article in Ecto docs about dynamic queries https://hexdocs.pm/ecto/dynamic-queries.html so you might think why another article is needed.

Indeed, the article from docs contains a solid foundation. However, I suggest organizing the final code differently. Let's examine the code:

def filter(params) do
  Post
  |> join(:inner, [p], assoc(p, :authors), as: :authors)
  |> order_by(^filter_order_by(params["order_by"]))
  |> where(^filter_where(params))
end

def filter_order_by("published_at_desc"),
  do: [desc: dynamic([p], p.published_at)]

def filter_order_by("published_at"),
  do: dynamic([p], p.published_at)

def filter_order_by("author_name_desc"),
  do: [desc: dynamic([authors: a], a.name)]

def filter_order_by("author_name"),
  do: dynamic([authors: a], a.name)

def filter_order_by(_),
  do: []

def filter_where(params) do
  Enum.reduce(params, dynamic(true), fn
    {"author", value}, dynamic ->
      dynamic([authors: a], ^dynamic and a.name == ^value)

    {"category", value}, dynamic ->
      dynamic([p], ^dynamic and p.category == ^value)

    {"published_at", value}, dynamic ->
      dynamic([p], ^dynamic and p.published_at > ^value)

    {_, _}, dynamic ->
      # Not a where parameter
      dynamic
  end)
end

One of the goals of the article was to demonstrate the use of the Ecto.Query.dynamic/2 macro. However, dynamic queries are not only about the usage of the Ecto.Query.dynamic/2 macro. Ecto queries are composable by design. Therefore, writing dynamic Ecto queries is all about the optional application of functions. The ultimate aim is to compose a query by given input parameters and Ecto.Query.dynamic/2 may not be needed at all.

I've observed various approaches to writing dynamic Ecto queries.
While I won't list them here, the Composite library is a result of refactoring those places.

Let's look at the alternative implementation with Composite:

def filter(params) do
  Post
  |> join(:inner, [p], assoc(p, :authors), as: :authors)
  |> Composite.new(params)
  |> Composite.param("order_by", &order_by(&1, ^order_instructions(&2)))
  |> Composite.param("author", &where(&1, [authors: a], a.name == ^name))
  |> Composite.param("category", &where(&1, category: ^&2))
  |> Composite.param("published_at", &where(&1, [p], p.published_at > ^&2))
end

defp order_instructions(value) do
  case value do
    "published_at_desc" -> [desc: :published_at]
    "published_at" -> [:published_at]
    "author_name_desc" -> [desc: dynamic([authors: a], a.name)]
    "author_name" -> dynamic([authors: a], a.name)
  end
end

Apart from having fewer lines of code, this implementation places all used parameters at the top level, eliminating the need to delve deep into the implementation of nested functions. Essentially, it resembles a router.
Composite.new/2 wraps the Ecto query into a Composite struct.

Composite.param/3 function calls define how to modify a query if a given parameter is present. The presence of the parameter is controlled by the :ignore? option, which ignores the following values by default: nil, "", [], %{}.

The third argument of the Composite.param/3 function is a modifier function for the query. An important property of this function is that the first argument is an Ecto query, and the second argument is a value of the specified parameter. This is important, because this is one of the default patterns when writing Ecto queries, as it allows sequential composition using a pipe operator. Thus, with the named function the last instruction can be written as:

# ...
|> Composite.param("published_at", &posts_published_after/2)
# ...
def posts_published_after(query, value) do
  where(query, [p], p.published_at > ^value)
end

You may have noticed, that the :authors association is always joined at the beginning of the query. It would be more efficient to optimize this part and join the association only when needed based on the input parameters. Composite can handle this by using dependencies. Each dependency is declared with the loader function which will be invoked before invoking the parameter handler.

def filter(params) do
  Post
  |> Composite.new(params)
  |> Composite.param(
    "order_by",
    fn query, value -> order_by(query, ^order_instructions(value)) end,
    requires: fn
      "author_name" -> :authors
      "author_name_desc" -> :authors
      _ -> nil
    end
  )
  |> Composite.param("author", &where(&1, [authors: a], a.name == ^&2), requires: :authors)
  |> Composite.param("category", &where(&1, category: ^&2))
  |> Composite.param("published_at", &where(&1, [p], p.published_at > ^&2))
  |> Composite.dependency(:authors, &join(&1, :inner, [p], assoc(p, :authors), as: :authors))
end

defp order_instructions(value) do
  case value do
    "published_at_desc" -> [desc: :published_at]
    "published_at" -> [:published_at]
    "author_name_desc" -> [desc: dynamic([authors: a], a.name)]
    "author_name" -> dynamic([authors: a], a.name)
  end
end

To convert the struct back to Ecto query, we can call Composite.apply/1 function at the end of the chain. This is done automatically by Ecto when you invoke functions from Ecto.Repo or Ecto.Query modules, because Composite implements the Ecto.Queryable protocol.

%{"category" => "Open Source"}
|> filter()
|> Composite.apply()
#Ecto.Query<from p0 in Post, where: p0.category == ^"Open Source">

%{
  "category" => "Open Source",
  "author" => "John Doe",
  "order_by" => "author_name"
}
|> filter()
|> Composite.apply()
# #Ecto.Query<from p0 in Post, join: a1 in assoc(p0, :authors), as: :authors,
#  where: a1.name == ^"John Doe", where: p0.category == ^"Open Source",
#  order_by: [asc: a1.name]>

This article doesn't describe all the features of Composite because the initial example is not very complex, reach out to docs for details. Source code is available on GitHub

That's it. Hope this helps :)