Servir la aplicación

http4s ejecuta su HttpApp[F] en un backend. La opción moderna predeterminada es Ember, un servidor escrito íntegramente en Scala y basado en cats-effect y fs2, disponible como org.http4s.ember.server.EmberServerBuilder.

Las aplicaciones más antiguas pueden usar Blaze, pero Ember es la opción recomendada en adelante.

EmberServerBuilder.default[F] proporciona un builder que puede configurar de forma fluida: vincule el host y el puerto, asocie la aplicación y, después, llame a .build para obtener un Resource[F, Server].

Usar un Resource garantiza que el socket se libere al apagar el servidor.

Ember usa tipos de ip4s para ofrecer redes con seguridad de tipos. Los interpoladores ipv4"..." y port"..." validan los valores en tiempo de compilación, por lo que una dirección no válida o un puerto fuera de rango no se podrán compilar.

Importe com.comcast.ip4s._ para acceder a ellos.

El servidor es un Resource porque posee un socket que debe abrirse y cerrarse correctamente. resource.use(_ => ...) lo mantiene en ejecución durante la duración del efecto interno.

Use IO.never para ejecutarlo hasta que se interrumpa el proceso.

La clase principal de una aplicación http4s extiende IOApp, que proporciona un entorno de ejecución administrado por cats-effect. Debe implementar run, que devuelve IO[ExitCode].

IOApp gestiona los grupos de hilos, las señales y el apagado ordenado por usted.

Para unirlo todo: construya el recurso del servidor y, después, use use con IO.never para que el proceso permanezca activo, devolviendo ExitCode.Success.

Este es el punto de entrada canónico de http4s.

Las aplicaciones reales adquieren más recursos que un servidor: un pool de conexiones a la base de datos, un cliente HTTP y la configuración. Compóngalos en una sola comprensión for sobre Resource para que todos se liberen en orden inverso.

Pase los clientes adquiridos al construir las rutas.

Como el servidor vive en un Resource, cancelar la fibra (por ejemplo, al recibir SIGTERM bajo IOApp) ejecuta el finalizador, que deja de aceptar conexiones y cierra el socket.

Ember procesa las solicitudes en curso dentro de un tiempo de espera de apagado configurable.

Envuelva el HttpApp final con middleware del servidor antes de pasarlo al builder. Algunos middleware habituales son Logger, CORS, GZip y ErrorHandling.

El orden es importante: la envoltura más externa ve primero la solicitud y por último la respuesta.

Lea el host, el puerto y los secretos del entorno mediante una biblioteca de configuración como ciris o pureconfig, y devuelva la configuración como parte de un Resource o un efecto.

Evite codificar los puertos directamente para que el mismo binario se ejecute en distintos entornos.

Exponga una ruta de disponibilidad como GET /health que devuelva 200 para que los orquestadores puedan comprobar el proceso. Añada middleware de registro de solicitudes y métricas para obtener visibilidad.

Mantenga las comprobaciones de estado rápidas y sin dependencias, de modo que reflejen el estado del proceso y no el de los servicios posteriores.

Recuerde por qué el servidor se modela como un Resource.

Sirvió la aplicación con EmberServerBuilder, la vinculó mediante literales de ip4s y la ejecutó desde un IOApp con build.use(_ => IO.never).

Compuso recursos, envolvió middleware, leyó la configuración del entorno, añadió una ruta de estado y recurrió a Resource para realizar un apagado ordenado.