We’ll get this out soon. We actually have it driving the Phoenix CRUD scaffolding with very minimal edits (including queries and mutations). Just some work around serialization (eg, views probably don’t want serialized time structs they then have to deserialize) and some utilities for error feedback before we push this out there.

Here’s a sneak peek of working code. Note the 3-arity actions; Absinthe processes input using the associated document, hands off result to action for response. It is pretty cool to have your Absinthe schema handle the complexities of input validation and database operations and just focus on what to show them!

  @graphql """
  mutation ($id: ID!, $user: InputUser!) {
    user: update_user(id: $id, input: $user) { ... UserFields }
  }
  """
  # Note: The "UserFields" fragment used above is defined by the View, as
  #       it's a view concern.
  def update(conn, %{user: user}, []) do
    conn
    |> put_flash(:info, "User updated successfully.")
    |> redirect(to: user_path(conn, :show, user))
  end
  def update(conn, %{user: user}, _errors) do
    conn
    |> put_flash(:error, "An error occurred.")
    |> redirect(to: user_path(conn, :edit, user))
  end

You’re my hero for making these!

We have an experimental library that does exactly this. Let me see if we can carve out some time this week and get a beta released.