Servire l'applicazione

http4s esegue il Suo HttpApp[F] su un backend. La scelta moderna predefinita è Ember, un server interamente in Scala basato su cats-effect e fs2, disponibile come org.http4s.ember.server.EmberServerBuilder.

Le applicazioni meno recenti possono usare Blaze, ma Ember è la soluzione consigliata per il futuro.

EmberServerBuilder.default[F] restituisce un builder da configurare in modo fluente: si associano host e porta, si collega l’applicazione e infine si chiama .build per ottenere una Resource[F, Server].

L’uso di una Resource garantisce che il socket venga rilasciato durante l’arresto.

Ember utilizza i tipi ip4s per una gestione dei network type-safe. Gli interpolatori ipv4"..." e port"..." verificano i valori in fase di compilazione, quindi un indirizzo non valido o una porta fuori intervallo impediscono la compilazione.

Importi com.comcast.ip4s._ per accedervi.

Il server è una Resource perché gestisce un socket che deve essere aperto e chiuso correttamente. resource.use(_ => ...) lo mantiene in esecuzione per tutta la durata dell’effetto interno.

Usi IO.never per eseguire l’applicazione fino all’interruzione del processo.

La classe principale di un’applicazione http4s estende IOApp, che fornisce un runtime cats-effect gestito. È necessario implementare run, restituendo IO[ExitCode].

IOApp gestisce per Lei pool di thread, segnali e arresto controllato.

Unendo i passaggi: si costruisce la risorsa del server, poi la si usa con IO.never per mantenere attivo il processo, restituendo ExitCode.Success.

Questo è il punto di ingresso canonico di http4s.

Le applicazioni reali acquisiscono più risorse di un semplice server: un pool di connessioni al database, un client HTTP, la configurazione. Le si compongono in un’unica comprensione for su Resource, così vengono tutte rilasciate in ordine inverso.

Passi i client acquisiti alla costruzione delle route.

Poiché il server vive in una Resource, la cancellazione della fiber (ad esempio in seguito a SIGTERM sotto IOApp) esegue il finalizer che interrompe l’accettazione delle connessioni e chiude il socket.

Ember completa le richieste in corso entro un timeout di arresto configurabile.

Avvolga l’HttpApp finale con i middleware del server prima di passarlo al builder. Tra i più comuni ci sono Logger, CORS, GZip ed ErrorHandling.

L’ordine è importante: il wrapper più esterno vede per primo la richiesta e per ultimo la risposta.

Legga host, porta e segreti dall’ambiente con una libreria di configurazione come ciris o pureconfig, restituendo la configurazione come parte di una Resource o di un effetto.

Eviti di codificare le porte direttamente nel codice, così lo stesso binario può essere eseguito in ambienti diversi.

Esponga una route di liveness come GET /health che restituisca 200, così gli orchestratori possono verificare il processo. Aggiunga middleware per il logging delle richieste e per le metriche.

Mantenga i controlli di salute semplici e privi di dipendenze, in modo che riflettano lo stato del processo e non quello dei servizi downstream.

Ricordi perché il server è modellato come una Resource.

Ha esposto l’applicazione con EmberServerBuilder, l’ha associata usando i literal di ip4s e l’ha eseguita da una IOApp con build.use(_ => IO.never).

Ha composto risorse, avvolto middleware, letto la configurazione dall’ambiente, aggiunto una route di health check e usato Resource per un arresto controllato.