Fiber : le framework web inspiré d'Express qui tourne sur Fasthttp

Express réinterprété sur le moteur Fasthttp

Fiber se définit en une phrase : un framework web écrit en Go, inspiré d'Express et construit sur Fasthttp, présenté comme le moteur HTTP le plus rapide de l'écosystème Go. Le README assume ce double héritage : la facilité d'Express et la performance brute de Go, dans une logique minimaliste revendiquée comme la voie UNIX. La cible est explicite, les nouveaux venus en Go, arrivés de Node.js, qui retrouvent dans Fiber des méthodes et des principes déjà connus. Le projet affiche 40 097 étoiles, 2 025 forks et seulement 43 issues ouvertes. La version majeure courante est v3, installée via le chemin de module github.com/gofiber/fiber/v3, tandis que la branche v2 continue de recevoir des correctifs.

Installation : Go 1.25, un module et dix lignes

Le prérequis est net : Fiber v3 exige Go 1.25 ou supérieur. L'installation suit le circuit classique des modules : go mod init github.com/your/repo, puis go get -u github.com/gofiber/fiber/v3. Le démarrage rapide du README tient en un seul fichier : fiber.New() crée l'application, app.Get associe une fonction recevant un fiber.Ctx à la route racine, c.SendString renvoie la réponse, et app.Listen sur le port 3000 démarre le serveur, log.Fatal remontant les erreurs de démarrage. L'exemple introduit les trois concepts du framework : initialisation, définition de route, lancement. Rien d'autre n'est requis pour un premier service, ce qui situe la barre d'entrée au niveau du langage lui-même.

Allocation zéro : la règle du contexte qui change tout

La section Zero Allocation du README impose une contrainte que les venus d'Express doivent intégrer : les valeurs renvoyées par fiber.Ctx ne sont pas immuables par défaut et sont réutilisées entre les requêtes. La règle énoncée tient en deux interdictions : n'utiliser les valeurs du contexte qu'à l'intérieur du gestionnaire, et ne jamais en conserver de références. Une fois le gestionnaire terminé, toute valeur obtenue du contexte sera réutilisée par une requête suivante. C'est le prix de l'absence d'allocation mémoire mise en avant par le projet, et la documentation dédiée détaille les cas limites. Un cache de résultats ou un accès asynchrone aux valeurs de requête exigent donc une copie explicite.

net/http et Fiber : deux mondes, une couche adaptor

Le README aborde frontalement la compatibilité. À cause de l'usage d'unsafe, Fiber peut ne pas toujours être compatible avec la dernière version de Go, et v3 a été testé avec Go 1.25 ou supérieur. Le routeur accepte cependant les gestionnaires net/http existants : un http.HandlerFunc s'enregistre directement. Le README avertit toutefois que ces gestionnaires adaptés n'accèdent pas aux fonctions de fiber.Ctx et supportent le surcoût d'une couche de compatibilité. Le style recommandé reste celui d'Express, avec les interfaces fiber.Req et fiber.Res et des middlewares recevant un callback next. Les migrations partielles sont donc possibles, mais le bénéfice complet du modèle de Fiber suppose des gestionnaires natifs.

Des middlewares intégrés et un dépôt contrib

La liste des middlewares internes est longue : adaptor, basicauth, cache, compress, cors, csrf, et d'autres encore, chacun documenté sur docs.gofiber.io. Les capacités étendues passent par des dépôts séparés : gofiber/template pour les moteurs de templates, gofiber/contrib pour WebSocket, Socket.io et d'autres intégrations, et le dépôt recipes qui contient notamment un exemple de Server-Sent Events. Un limiteur de débit fait partie des middlewares de première main. Le README complète le tableau avec les fonctions de base : routage, service de fichiers statiques, points d'API, support des middlewares et de Next. Pour une API, la combinaison limiter, cors et cache couvre la plupart des besoins courants.

Ce que disent vraiment les benchmarks

Le README appuie la performance sur les tests TechEmpower, avec un renvoi vers une page de benchmarks du projet. Les mentions de performance extrême et de faible empreinte mémoire ne sont pas quantifiées dans le dépôt : les chiffres vivent sur la page TechEmpower et le wiki dédié. Cette prudence mérite d'être notée, car Fasthttp et net/http n'ont pas le même profil, et un framework rapide sur le test plaintext ne dit rien du coût de vos gestionnaires de base de données. Le signal le plus fiable pour une équipe reste un test sur son propre endpoint, avec les versions épinglées, v3.5.0 et son runtime Go, les gains documentés portant surtout sur l'allocation mémoire.

Deux lignes de versions, un engagement MIT

Les releases montrent une double maintenance : v3.5.0 le 13 août 2026, mais aussi v2.52.15 le 12 août et v2.52.14 le 6 juillet. Une équipe restée sur v2 reçoit donc des correctifs, sans bénéficier d'office des évolutions de v3, dont le chemin de module diffère. La licence est MIT, copyright Fenny et Contributors, avec le texte standard : usage, modification, redistribution et sous-licence autorisées, logiciel fourni sans garantie. Le projet finance son développement via GitHub Sponsors, avec JetBrains, OpenAI et Anthropic listés comme sponsors d'outils. Discord et les issues servent de canaux d'écoute des utilisateurs, cités comme tels dans la section philosophie du README.

Conclusion éditoriale

Fiber vise les développeurs venant de Node.js et d'Express qui veulent écrire des API en Go sans réapprendre un idiome différent. Trois points méritent une lecture avant adoption : la règle de réutilisation du contexte, imposée par l'allocation zéro de Fasthttp, la dépendance à Go 1.25 ou plus pour v3, et le surcoût de la couche adaptor pour les gestionnaires net/http existants. Choisissez la ligne dès le départ, v3.5.0 pour un projet neuf, et vérifiez les benchmarks TechEmpower liés dans le README plutôt que les seules mentions de performance.

Sources officielles

1. Official documentation
2. Official README
3. Project repository
4. Release notes