Servir l’application

http4s exécute votre HttpApp[F] sur un serveur. Le choix moderne par défaut est Ember, un serveur entièrement écrit en Scala et basé sur cats-effect et fs2, disponible sous la forme de org.http4s.ember.server.EmberServerBuilder.

Les applications plus anciennes peuvent utiliser Blaze, mais Ember est la solution recommandée pour l'avenir.

EmberServerBuilder.default[F] fournit un constructeur que vous configurez de manière fluide : vous liez l'hôte et le port, rattachez l'application, puis appelez .build pour obtenir une Resource[F, Server].

L'utilisation d'une Resource garantit que le socket est libéré lors de l'arrêt.

Ember utilise les types ip4s pour assurer la sûreté de typage du réseau. Les interpolateurs ipv4"..." et port"..." valident les valeurs à la compilation : une adresse invalide ou un port hors limites ne pourra donc pas être compilé.

Importez com.comcast.ip4s._ pour y accéder.

Le serveur est une Resource parce qu'il possède un socket qui doit être ouvert et fermé proprement. resource.use(_ => ...) le maintient en fonctionnement pendant toute la durée de l'effet interne.

Utilisez IO.never pour l'exécuter jusqu'à l'interruption du processus.

La classe principale d'une application http4s étend IOApp, qui fournit un environnement d'exécution cats-effect géré. Vous implémentez run, qui renvoie IO[ExitCode].

IOApp gère pour vous les pools de threads, la gestion des signaux et l'arrêt progressif.

Pour tout assembler, construisez la ressource du serveur, puis utilisez-la avec use et IO.never afin que le processus reste actif, en renvoyant ExitCode.Success.

C'est le point d'entrée http4s canonique.

Les applications réelles acquièrent davantage qu'un serveur : un pool de connexions à une base de données, un client HTTP, une configuration. Composez-les dans une seule compréhension for sur Resource afin qu'ils soient tous libérés dans l'ordre inverse.

Transmettez les clients acquis à la construction des routes.

Comme le serveur vit dans une Resource, l'annulation de la fibre (par exemple lors d'un SIGTERM sous IOApp) exécute le finaliseur qui cesse d'accepter les connexions et ferme le socket.

Ember laisse se terminer les requêtes en cours dans le délai d'arrêt configurable.

Enveloppez l'HttpApp final avec l'intergiciel du serveur avant de le transmettre au constructeur. Les intergiciels courants sont Logger, CORS, GZip et ErrorHandling.

L'ordre est important : l'enveloppe la plus externe voit la requête en premier et la réponse en dernier.

Lisez l'hôte, le port et les secrets depuis l'environnement avec une bibliothèque de configuration telle que ciris ou pureconfig, en renvoyant la configuration dans une Resource ou un effet.

Évitez de coder les ports en dur afin que le même binaire puisse s'exécuter dans différents environnements.

Exposez une route de vivacité telle que GET /health qui renvoie 200, afin que les orchestrateurs puissent sonder le processus. Ajoutez un intergiciel de journalisation des requêtes et de métriques pour assurer la visibilité.

Gardez les vérifications d'état peu coûteuses et indépendantes des dépendances afin qu'elles reflètent l'état du processus, et non celui des services en aval.

Rappelez-vous pourquoi le serveur est modélisé comme une Resource.

Vous avez servi l'application avec EmberServerBuilder, l'avez lié à l'aide des littéraux ip4s et l'avez exécutée depuis une IOApp avec build.use(_ => IO.never).

Vous avez composé des ressources, enveloppé des intergiciels, lu la configuration depuis l'environnement, ajouté une route d'état de santé et utilisé Resource pour assurer un arrêt progressif.