Take-A-Number Deluxe

GenServer

GenServer (servidor genérico) es un comportamiento que abstrae las interacciones comunes cliente-servidor entre procesos de Elixir.

¿Recuerdas el bucle de recepción de cuando aprendimos sobre procesos? El comportamiento GenServer proporciona abstracciones para implementar esos bucles y para intercambiar mensajes con un proceso que ejecuta un bucle así. Facilita mantener el estado y ejecutar código asíncrono.

El comportamiento GenServer define un callback obligatorio, init/1, y algunos callbacks opcionales interesantes: handle_call/3, handle_cast/2 y handle_info/3. Se supone que los clientes que usan un GenServer no deben llamar a esos callbacks directamente. En su lugar, el módulo GenServer proporciona funciones que los clientes pueden usar para comunicarse con un proceso GenServer.

A menudo, un solo módulo define tanto una API de cliente, un conjunto de funciones que otras partes de tu aplicación Elixir pueden llamar para comunicarse con este proceso GenServer, como implementaciones de callbacks de servidor, que contienen la lógica de este GenServer.

Primero veamos un ejemplo sencillo de un GenServer y después aprendamos qué significa cada callback.

Ejemplo

Este es un servidor de ejemplo que puede responder a las repetitivas inquisiciones de pasajeros molestos durante un largo viaje por carretera, más exactamente a la pregunta: «¿ya llegamos?». Lleva la cuenta de cuántas veces se ha hecho esta pregunta y devuelve respuestas cada vez más irritadas.

defmodule AnnoyingPassengerAutoresponder do
  use GenServer
  # Client API

  def start_link(init_arg) do
    GenServer.start_link(__MODULE__, init_arg)
  end

  def are_we_there_yet?(pid) do
    GenServer.call(pid, :are_we_there_yet?)
  end

  # Server callbacks

  @impl GenServer
  def init(_init_arg) do
    # the initial count of questions asked is always 0
    state = 0
    {:ok, state}
  end

  @impl GenServer
  def handle_call(:are_we_there_yet?, _from, state) do
    reply =
      cond do
        state <= 3 -> "No."
        state <= 10 -> "I told you #{state} times already. No."
        true -> "..."
      end

    # increase the count of questions asked
    new_state = state + 1
    # reply to the caller
    {:reply, reply, new_state}
  end
end

Callbacks

init/1

Un servidor se puede iniciar llamando a GenServer.start/3 o GenServer.start_link/3. Aprendimos la diferencia entre esas funciones en el concepto de enlaces.

Esas dos funciones:

• Aceptan como primer argumento un módulo que implementa el comportamiento GenServer.
• Aceptan cualquier cosa como segundo argumento, llamado init_arg. Como sugiere el nombre, este argumento se pasa al callback init/1.
• Aceptan un tercer argumento opcional con opciones avanzadas para ejecutar el proceso, que no veremos por ahora.

Iniciar un servidor llamando a GenServer.start/3 o GenServer.start_link/3 invoca el callback init/1 de forma bloqueante. El valor que devuelve init/1 determina si el servidor se puede iniciar correctamente.

Por lo general, el callback init/1 devuelve uno de estos valores:

• {:ok, state}. El servidor iniciará su bucle de recepción usando state como estado inicial. state puede ser de cualquier tipo.
• {:stop, reason}. reason puede ser de cualquier tipo. El servidor no iniciará su bucle de recepción. El proceso terminará con el motivo indicado.

También hay posibilidades más avanzadas que no veremos por ahora.

Si el bucle de recepción del servidor se inicia, las funciones GenServer.start/3 y GenServer.start_link/3 devuelven una tupla {:ok, pid}. De lo contrario, devuelven {:error, reason}.

handle_call/3

Se puede enviar un mensaje que requiere una respuesta a un proceso servidor con GenServer.call/2. Esta función espera el pid de un proceso servidor en ejecución como primer argumento, y el mensaje como segundo argumento. El mensaje puede ser de cualquier tipo.

El callback handle_call/3 se encarga de manejar y responder a los mensajes síncronos. Recibe tres argumentos:

1. message: el valor pasado como segundo argumento a GenServer.call/2.
2. from: el pid del proceso que llama a GenServer.call/2. La mayoría de las veces se puede ignorar este argumento.
3. state: el estado actual del servidor. Recuerda que su valor inicial se estableció en el callback init/1.

Por lo general, el callback handle_call/3 devuelve una tupla de 3 elementos {:reply, reply, state}. Esto significa que el segundo elemento de la tupla, una reply que puede ser de cualquier tipo, se enviará de vuelta a quien hizo la llamada. El tercer elemento de la tupla, state, es el nuevo estado del servidor después de manejar este mensaje.

También hay posibilidades más avanzadas que no veremos por ahora.

handle_cast/2

Se puede enviar un mensaje que no requiere una respuesta a un proceso servidor con GenServer.cast/2. Sus argumentos son idénticos a los de GenServer.call/2.

El callback handle_cast/2 se encarga de manejar esos mensajes. Recibe dos argumentos, message y state, que son los mismos argumentos que en el callback handle_call/3 (excepto from).

Por lo general, el callback handle_cast/2 devuelve una tupla de 2 elementos {:noreply, state}.

También hay posibilidades más avanzadas que no veremos por ahora.

¿Debería usar call o cast?

Casi siempre usa call, incluso si tu código cliente no necesita la respuesta del servidor.

Usar call espera la respuesta, lo que sirve como mecanismo de contrapresión (para evitar que los clientes envíen demasiados mensajes a la vez). Recibir una respuesta del servidor es también la única forma de saber con certeza que el servidor recibió y manejó el mensaje del cliente.

handle_info/2

Los mensajes también pueden llegar a la bandeja de entrada del servidor por medios distintos a llamar a GenServer.call/2 o GenServer.cast/2, por ejemplo llamando a la función básica send/2.

Para manejar esos mensajes, usa el callback handle_info/2. Este callback funciona exactamente igual que handle_cast/2.

El comportamiento GenServer proporciona una implementación comodín de handle_info/2 que registra los errores de los mensajes inesperados. Si sobrescribes esa implementación predeterminada, asegúrate de incluir siempre tu propia implementación comodín. Si lo olvidas, el servidor fallará si recibe un mensaje inesperado.

Tiempos de espera

El valor que devuelve cada uno de los cuatro callbacks descritos arriba se puede ampliar con un elemento más de la tupla, un timeout. Por ejemplo, en lugar de devolver {:ok, state} desde init/1, devuelve {:ok, state, timeout}.

El timeout se puede usar para detectar la ausencia de mensajes en el buzón durante un periodo específico. Si el servidor devuelve un timeout desde uno de sus callbacks, y han transcurrido los milisegundos especificados sin que llegue ningún mensaje, se llama a handle_info/2 con :timeout como primer argumento.