Filosofía Elixir / OTP
aplicada en autowebapp

La aplicación tiene un supervisor :one_for_one real con cinco hijos declarados en orden estricto de inicio:

• AutowebappWeb.Telemetry — métricas del sistema.
• DNSCluster — clustering Erlang vía DNS.
• Phoenix.PubSub — bus de mensajes en tiempo real.
• Autowebapp.Shared.Discovery — Agent que resuelve URLs de microservicios al arrancar.
• AutowebappWeb.Endpoint — servidor HTTP, siempre el último para que todo esté listo antes de aceptar tráfico.

El orden importa: con estrategia :one_for_one y arranque secuencial, si Discovery fallara al iniciar, el Endpoint no llegaría a arrancar.

def start(_type, _args) do
  children = [
    AutowebappWeb.Telemetry,
    {DNSCluster, query: Application.get_env(:autowebapp, :dns_cluster_query) || :ignore},
    {Phoenix.PubSub, name: Autowebapp.PubSub},
    Autowebapp.Shared.Discovery,
    AutowebappWeb.Endpoint  # siempre el último
  ]
  opts = [strategy: :one_for_one, name: Autowebapp.Supervisor]
  Supervisor.start_link(children, opts)
end

Cada LiveView conectada es un proceso BEAM. Cuando un pasajero abre el navegador en /pasajero/buscar, el servidor crea un proceso GenServer específico para esa conexión WebSocket. Si 5.000 pasajeros están conectados simultáneamente, hay 5.000 procesos LiveView independientes. Si el proceso de uno muere, los otros 4.999 ni se enteran.

La comunicación por mensajes es exactamente lo que ocurre con el sistema de notificaciones. El ciclo completo es:

def subscribe(rol, id) do
  Phoenix.PubSub.subscribe(@pubsub, topic(rol, id))
end

Phoenix.PubSub.broadcast(
  @pubsub,
  topic(rol, id),
  {:nueva_notificacion, notificacion}
)

def handle_info({:nueva_notificacion, notif}, socket) do
  {:noreply, update(socket, :notificaciones, &[notif | &1])}
end

a) El Agent de Discovery

Autowebapp.Shared.Discovery es el ejemplo más limpio de este patrón. Inicia con estado nil (sin configuración cargada) y lo reemplaza tras el primer fetch HTTP exitoso.

Arranque del Agent con estado inicial nil:

use Agent

def start_link(_opts) do
  Agent.start_link(fn -> nil end, name: __MODULE__)
end

Primera llamada a get_config/0: descarga las URLs de los microservicios y las almacena en el Agent:

def get_config(force_reload \\ false) do
  cached = if force_reload, do: nil, else: Agent.get(__MODULE__, & &1)
  if cached do
    {:ok, cached}
  else
    case client.fetch_config() do
      {:ok, data} ->
        case parse_and_validate(data) do
          {:ok, config} ->
            Agent.update(__MODULE__, fn _ -> config end)  # ← estado mutable
            {:ok, config}
          # ...
        end
    end
  end
end

El flujo de estado es: nil → fetch HTTP → %Config{core: ..., pagos: ..., login: ..., htmls: ..., images: ...}. A partir de ahí, cada LiveView llama get_config/0 y obtiene la caché sin volver a hacer HTTP.

---

b) Socket assigns: inmutabilidad en LiveView

Los assigns del socket siguen el mismo principio. En LiveView, el socket es una struct inmutable. Cuando "asignas" algo, creas un socket nuevo con ese valor; el original nunca se modifica. Esto hace que el estado del socket sea trazable y libre de efectos secundarios ocultos.

# Cada assign/3 devuelve un socket NUEVO — el anterior no se toca
socket =
  socket
  |> assign(:app_state, app_state)
  |> assign(:current_user_id, usuario_id)
  |> assign(:app_role, app_role)

La cadena de pipes es azúcar sintáctico: cada llamada recibe el socket devuelto por la anterior y produce uno nuevo. Puedes razonar sobre el estado final del socket leyendo las líneas de arriba hacia abajo, sin preocuparte por mutaciones ocultas en otro hilo.

El patrón dominante de la aplicación es: cada cliente HTTP es un behaviour puro + una implementación real (_impl) + un mock de test (_mock). El código de dominio solo conoce el contrato; nunca sabe si habla con HTTP real o con un mock.

Ejemplo: behaviour puro sin implementación

defmodule Autowebapp.Clients.LoginClient do
  @callback fetch_logos(login_url :: String.t()) ::
    {:ok, list(map())} | {:error, any()}

  @callback valida_existencia_habilitacion_correo(
    login_url :: String.t(),
    correo :: String.t(),
    id_app :: String.t(),
    enterprise_id :: integer()
  ) :: {:ok, map()} | {:error, any()}

  @callback valida_pin_email(
    login_url :: String.t(),
    pin :: String.t(),
    correo :: String.t(),
    id_app :: String.t()
  ) :: {:ok, map()} | {:error, any()}

  @callback obtener_usuario_token(
    login_url :: String.t(),
    token :: String.t()
  ) :: {:ok, map()} | {:error, any()}
end

Existen 8 behaviours de este tipo en la aplicación: discovery_client, login_client, viaje_client, pasajero_client, conductor_client, pagos_client, notificacion_client, htmls_client.

Resolución runtime: producción vs. test

defp notificacion_client do
  Application.get_env(
    :autowebapp,
    :notificacion_client,
    Autowebapp.Clients.NotificacionClientImpl
  )
end

En producción devuelve NotificacionClientImpl (HTTP real). En tests, config/test.exs inyecta NotificacionClientMock generado por Mox. El código de dominio nunca distingue entre ambos — solo conoce el contrato del behaviour.

Definición de mocks en test

Mox.defmock(Autowebapp.Clients.LoginClientMock,
  for: Autowebapp.Clients.LoginClient)
Mox.defmock(Autowebapp.Clients.NotificacionClientMock,
  for: Autowebapp.Clients.NotificacionClient)
# ...ídem para los 7 clients restantes

Mox valida en tiempo de compilación que el mock implementa exactamente las callbacks del behaviour. Si el contrato cambia, los mocks fallan — no los tests en silencio.

Concurrencia implícita sin configuración especial

La concurrencia masiva del BEAM es la fundación implícita de todo lo que hace autowebapp. No hay código que la "active" — simplemente está ahí por el hecho de usar Phoenix LiveView. Cuando 5.000 pasajeros están conectados a /pasajero/viaje_activo, el BEAM está manejando al menos 5.000 procesos LiveView en paralelo, más los procesos de socket, los supervisores, el PubSub, el Agent de Discovery, la telemetría... todo concurrente, sin que ningún proceso bloquee a otro.

Hot reload vía config_change/3

Phoenix llama automáticamente a este callback cuando la configuración del endpoint cambia en caliente en desarrollo, sin reiniciar la aplicación completa:

@impl true
def config_change(changed, _new, removed) do
  AutowebappWeb.Endpoint.config_change(changed, removed)
  :ok
end

{DNSCluster, query: Application.get_env(:autowebapp, :dns_cluster_query) || :ignore}

Este es el concepto más rico de la app, con un patrón especialmente elegante que combina persistencia HTTP con entrega en tiempo real.

1. Registro del bus en el árbol de supervisión

{Phoenix.PubSub, name: Autowebapp.PubSub}

2. Naming centralizado de topics

def topic("A", id), do: "conductor:#{id}"
def topic("P", id), do: "pasajero:#{id}"

Solo se llama Notificaciones.topic(rol, id). Si mañana cambia el formato del topic, hay un único lugar donde actualizar.

3. Suscripción en el mount de la LiveView

def subscribe(rol, id) do
  Phoenix.PubSub.subscribe(@pubsub, topic(rol, id))
end

4. Broadcast al ocurrir un evento — el patrón dual

def notificar(core_url, attrs) do
  client = notificacion_client()
  case client.crear(core_url, attrs) do
    {:ok, notificacion} ->
      rol = Map.get(attrs, :destinatario_rol)
      id  = Map.get(attrs, :destinatario_id)
      Phoenix.PubSub.broadcast(
        @pubsub,
        topic(rol, id),
        {:nueva_notificacion, notificacion}
      )
      {:ok, notificacion}
    {:error, reason} = error ->
      Logger.error("[Notificaciones] Error: #{inspect(reason)}")
      error
  end
end

• Paso 1 — persistencia HTTP: la notificación se crea en core-empresas vía HTTP antes de cualquier broadcast. Garantía: el usuario la verá aunque cierre la app y vuelva más tarde.
• Paso 2 — broadcast PubSub (best-effort): solo se ejecuta si la persistencia fue exitosa. Si el usuario está conectado, recibe la notificación al instante. Si no hay nadie suscrito, el mensaje se descarta silenciosamente — sin errores, sin reintentos necesarios.

5. Recepción en el handle_info de la LiveView

El proceso LiveView del conductor o pasajero recibe el mensaje en su mailbox, actualiza sus assigns y Phoenix re-renderiza únicamente los componentes que cambiaron:

def handle_info({:nueva_notificacion, notif}, socket) do
  {:noreply, update(socket, :notificaciones, &[notif | &1])}
end