Cette page rassemble les correspondances API et les pièges typiques pour migrer un service HTTP existant vers Chappe. Pour les chiffres de performance comparés, voir lien:https://codeberg.org/Vidocq/chappe/blob/main/BENCH.md[BENCH.md].
|
Chappe est en |
Depuis Jetty
| Jetty | Chappe | Note |
|---|---|---|
|
|
Plus serré ; pas de connecteur séparé. |
|
Foy sur Chappe |
Servlet via le pont Foy. |
|
|
Pas de pool plateforme ; pas de tuning. |
|
Composition |
Modèle plus simple, sans |
|
|
|
|
|
Skip auto si |
Depuis Netty
| Netty | Chappe | Note |
|---|---|---|
|
Virtual threads |
Pas de boucle d’événements applicative. |
|
Pas d’équivalent direct |
Composer via |
|
|
Modèle synchrone — Loom le rend équivalent en scalabilité. |
|
|
Pas de pool de buffers exposé à l’utilisateur. Le |
|
Inclus de base |
Parsing HTTP/1.1 et HTTP/2 dans |
|
Migrer un pipeline Netty complexe (par exemple un proxy multi-protocoles avec backpressure custom) est un chantier sérieux. Chappe ne réplique pas l’extensibilité bas niveau de Netty au niveau channel. Si vous écrivez votre propre protocole binaire ou avez besoin d’un contrôle fin du backpressure côté écriture, Chappe n’est probablement pas le bon outil. |
Depuis Undertow
| Undertow | Chappe | Note |
|---|---|---|
|
|
API equivalente. |
|
|
API fluide, mêmes verbes. |
|
|
Fallback chain filesystem → classpath natif. |
|
Inutile |
Tous les handlers Chappe sont synchrones bloquants sur virtual thread. |
|
Virtual threads |
Pas de tuning de pool. |
|
Headers internes |
|
Depuis JDK 25 HttpServer
com.sun.net.httpserver.HttpServer est minimal et n’est pas pensé pour la production. Avantage : sans dépendance. Désavantages : pas de HTTP/2, pas de virtual threads par défaut, multiplexage limité.
| JDK HttpServer | Chappe | Note |
|---|---|---|
|
|
Builder fluide. |
|
|
Match par méthode + path, pas seulement par préfixe. |
|
|
Fonction pure ; pas d’accès direct à la socket. |
|
Par défaut |
Aucun setup. |
Migration vers la CLI standalone
Si votre besoin est seulement « servir un site statique en production » (cas Docker), basculer le launcher Java vers chappe serve :
java \
-jar chappe-cli/target/chappe-cli-*-shaded.jar \
serve --root /var/www/site --port 8080 --gzip
Configuration via YAML, headers conditionnels par variable d’environnement, sidecars .gz au build via le plugin Maven. Voir Référence — CLI chappe serve.
Points de bascule typiques
| Fonction existante | Bascule Chappe |
|---|---|
Logger HTTP access (Tomcat, Jetty |
|
Compression Brotli runtime |
Non supportée. Sidecars |
WebSocket |
Planifié — voir lien:https://codeberg.org/Vidocq/chappe/blob/main/BUG.md[BUG.md]. |
Servlet API complète |
Foy sur Chappe (Jakarta Servlet 6.1). |
JAX-RS / REST |
Cassini sur Chappe (Jakarta REST 4.0). |
TLS PEM natif |
Non supporté côté Chappe. Convertir en PKCS12 avec |
Capacits prtes pour la migration
-
CLI standalone (
chappe serve --config …) — packaging Docker direct, image jlink ~50 Mo. -
Filter.gzip()+StaticFileHandler.preferPrecompressed(true)— compression ngocie + sidecars.br/.gz. -
StaticFileHandler.spaFallback("/index.html")/.notFoundFile("/404.html")— routing SPA et 404 personnalisée. -
Filter.addHeaderIfEnv("STAGING", "true", "X-Robots-Tag", "noindex, nofollow")— headers conditionnels par environnement. -
Router.mount(prefix, handler)— composition d’extensions Servlet/REST sans couplage.