@joelwallis your opinion is greatly appreciated. Do you think we should implement an adapter abstraction right now? Do you think an adapter approach is even necessar at all considering Plug is by far the most important web server abstraction?

I thought about it a bit more and think we should implement the adapter approach right away. The reason is that we can implement a GRPC adapter for service-to-service authentication in our product.

This is the API of DoorFrame I have in mind right now:

# controllers/auth_controller.ex
defmodule AppWeb.StatusController do
  use AppWeb, :controller

  def auth(conn, _) do
    case DoorFrame.Adapter.Plug.authenticate(conn, App.Auth.Handler) do
      {:ok, conn, _response} ->
        conn

      {:error, conn, _error} ->
        conn
    end
  end
end

# door_frame/adapter/plug.ex
defmodule DoorFrame.Adapter.Plug do
  def authenticate(%Plug.Conn{} = conn, handler) do
    # Parse headers
    # Parse body
    request = parse_conn(conn)

    case handler.authenticate(request) do
      {:ok, response} ->
        # Redirect if necessary
        conn =
          conn
          |> put_status(response.status)
          |> json(response)

        {:ok, conn, response}

      {:error, error} ->
        conn
        |> put_status(error.status)
        |> json(error.payload)

        {:ok, conn, error}
    end
  end
end
# …

Hey @madebyherzblut,

To put down here what we've discussed before, shaw we proceed with a simpler approach, targeting the Plug architecture? I like the idea of having adapters for different types of HTTP interfaces, but I'm afraid that premature optimization could distract us from the main problem we're trying to solve (build a non-opinionated OAuth library). Since the Raxx userbase is still small, we could support it in future versions .

So for the first version we would use DoorFrame module for common logic and DoorFrame.Plug for Plug-specific logic and implementation. Future ones could have the architecture matter revisited.