Go Fiber : API Express-like en Go — tutoriel déploiement 2026

Introduction

Imaginez un développeur à Dakar ou à Abidjan qui cherche à exposer une API REST pour une application mobile de paiement Wave ou CinetPay. Il connaît Node.js et Express, mais son équipe veut migrer vers un langage compilé pour gagner en robustesse et en performances. Go est le candidat naturel : compilé en un binaire statique, typage fort, goroutines légères pour la concurrence. Mais parmi les dizaines de frameworks Go disponibles, lequel choisir pour retrouver la productivité d’Express sans sacrifier la vitesse ?

La réponse en 2026, c’est Go Fiber. Ce framework s’est imposé comme la référence pour les équipes venant du monde JavaScript, en reproduisant fidèlement l’API d’Express.js tout en s’appuyant sur fasthttp, le moteur HTTP Go capable de traiter jusqu’à dix fois plus de requêtes par seconde que la bibliothèque standard net/http. Résultat : une syntaxe familière, une courbe d’apprentissage douce, et des performances de niveau production prêtes pour les charges réelles des plateformes fintech et e-commerce de la sous-région.

Dans ce tutoriel, vous allez construire une API REST complète de zéro, avec gestion des routes, des paramètres, des middleware, la validation des requêtes JSON, une connexion PostgreSQL via pgx v5, puis un build Docker optimisé prêt à être déployé sur un VPS Hetzner CX22 à 3,79 €/mois — le type d’hébergement le plus courant pour les startups tech ouest-africaines.

Prérequis

• Go 1.23 minimum — Go 1.25 recommandé (requis par pgx v5). Télécharger sur go.dev/dl.
• Docker installé en local pour l’étape de déploiement.
• PostgreSQL 14+ accessible (local ou Supabase free tier).
• Un éditeur de code — VS Code avec l’extension Go officielle ou Neovim avec gopls.
• Connaissance de base de Go (types, fonctions, modules) et de HTTP (méthodes, codes de statut).
• Durée estimée : 30 à 45 minutes pour suivre toutes les étapes.

Étape 1 — Fiber vs Gin vs Echo : choisir son framework Go

Avant d’écrire la première ligne de code, il faut comprendre pourquoi Fiber est le bon choix dans votre contexte. L’écosystème Go compte trois frameworks dominants : Gin, Echo et Fiber. Les trois sont matures et utilisés en production, mais ils ne partagent pas les mêmes philosophies ni les mêmes compromis.

Gin est bâti sur net/http et httprouter. Il est rapide (zéro allocation sur le routage), dispose d’un écosystème de middleware très riche, et est le framework Go le plus étoilé sur GitHub. Son API est concise mais reste spécifiquement « Go » — il n’y a pas de référence volontaire à d’autres langages. Si vous démarrez en Go sans bagage JavaScript, Gin est excellent.

Echo est lui aussi bâti sur net/http. Son point fort est la flexibilité : il supporte HTTP/2 nativement (ce que Fiber ne peut pas faire directement, fasthttp ne gérant pas HTTP/2 en standard), dispose d’un binder de données très complet, et offre une abstraction propre pour les groupes de routes. Echo est souvent préféré dans les projets qui ont besoin de WebSocket et d’HTTP/2 simultanément.

Fiber, lui, prend un pari différent : sacrifier la compatibilité native net/http au profit d’une vitesse maximale via fasthttp, et adopter délibérément la syntaxe d’Express.js pour baisser le seuil d’entrée. Le package net/http crée un objet Request et un ResponseWriter par requête avec des allocations mémoire à chaque fois ; fasthttp réutilise ses objets via des pools, réduisant drastiquement la pression sur le garbage collector. Sur un VPS modeste — comme le CX22 à 4 Go de RAM — cette économie de mémoire se traduit par une latence plus stable sous charge élevée.

Le tableau ci-dessous résume les différences clés pour vous aider à décider :

Pour un projet API REST sans besoin de HTTP/2 ni de streaming bidirectionnel complexe, Fiber v3 est le choix optimal en 2026 : il offre la productivité Express, les performances fasthttp, et une version v3 qui apporte la gestion des contextes Go natifs (context.Context) et une meilleure gestion des erreurs.

Étape 2 — Initialiser le module Go et installer les dépendances

Un projet Go moderne s’organise autour des modules, introduits avec Go 1.11 et devenus le standard absolu depuis Go 1.16. Le fichier go.mod joue le même rôle que package.json en Node.js : il identifie votre module, déclare sa version minimale de Go, et liste ses dépendances directes. Avant d’installer quoi que ce soit, il faut donc initialiser ce module.

Créez un répertoire de travail, puis initialisez le module avec un chemin de module qui correspond à votre dépôt (on utilise ici un exemple générique) :

mkdir api-fiber && cd api-fiber
go mod init github.com/votre-org/api-fiber

Cette commande crée go.mod avec votre chemin de module et la version Go installée. Installez maintenant les deux dépendances principales : Fiber v3 et le driver PostgreSQL pgx v5.

go get github.com/gofiber/fiber/v3@latest
go get github.com/jackc/pgx/v5@latest
go get github.com/jackc/pgx/v5/pgxpool@latest

Go télécharge les modules dans son cache local ($GOPATH/pkg/mod) et met à jour go.mod ainsi que go.sum (le fichier de vérification cryptographique des dépendances). Vous pouvez vérifier l’installation avec go list -m all qui liste tous les modules du projet. Si vous voyez github.com/gofiber/fiber/v3 dans la liste, l’installation a réussi. Le fichier go.sum ne doit jamais être modifié manuellement — Go le gère seul et il doit être commité dans votre dépôt pour garantir la reproductibilité des builds.

Étape 3 — Premier serveur Hello World

Avant de construire une API complète, il faut valider que l’installation fonctionne et comprendre la structure de base d’une application Fiber. Cette étape reproduit intentionnellement la simplicité d’un serveur Express minimal, pour que vous puissiez voir immédiatement la ressemblance avec ce que vous connaissez peut-être de Node.js.

Créez le fichier main.go à la racine du projet :

package main

import (
    "log"

    "github.com/gofiber/fiber/v3"
)

func main() {
    // Crée une nouvelle instance Fiber avec la configuration par défaut
    app := fiber.New()

    // Déclare une route GET sur la racine
    app.Get("/", func(c fiber.Ctx) error {
        return c.SendString("Salam ! API Fiber opérationnelle.")
    })

    // Démarre le serveur sur le port 3000
    // log.Fatal arrête le programme si Listen retourne une erreur
    log.Fatal(app.Listen(":3000"))
}

Démarrez le serveur avec go run main.go. Fiber affiche sa bannière dans le terminal — version, nombre de routes, adresse d’écoute. Testez avec curl http://localhost:3000 : vous devez recevoir la chaîne de salutation. Si vous obtenez connection refused, vérifiez que le port 3000 n’est pas déjà utilisé par un autre processus (lsof -i :3000 sur Linux/macOS). La structure fiber.Ctx est l’équivalent Fiber de l’objet (req, res) d’Express : il encapsule à la fois la requête entrante et la réponse à construire.

Étape 4 — Routes, paramètres d’URL et middleware

Une API REST réelle nécessite plusieurs routes avec différentes méthodes HTTP, la lecture de paramètres dynamiques dans les URL, et des middleware pour des traitements transversaux comme la journalisation ou l’authentification. Fiber gère tout cela avec une syntaxe quasi-identique à Express, ce qui rend la transition très naturelle.

Voici comment structurer un ensemble de routes CRUD pour une ressource « produit », avec un middleware de logging appliqué globalement :

package main

import (
    "log"
    "time"

    "github.com/gofiber/fiber/v3"
)

// Middleware de logging maison : loggue méthode, path et durée de traitement
func Logger(c fiber.Ctx) error {
    start := time.Now()
    // next() passe la main au handler suivant dans la chaîne
    err := c.Next()
    log.Printf("%s %s — %v", c.Method(), c.Path(), time.Since(start))
    return err
}

func main() {
    app := fiber.New()

    // Enregistre le middleware de logging sur toutes les routes
    app.Use(Logger)

    // Groupe de routes /api/v1 — équivalent d'Express Router
    api := app.Group("/api/v1")

    // :id est un paramètre dynamique dans l'URL
    api.Get("/produits", listerProduits)
    api.Get("/produits/:id", getProduit)
    api.Post("/produits", creerProduit)
    api.Put("/produits/:id", mettreAJourProduit)
    api.Delete("/produits/:id", supprimerProduit)

    log.Fatal(app.Listen(":3000"))
}

func listerProduits(c fiber.Ctx) error {
    return c.JSON(fiber.Map{"produits": []string{"Thiéboudienne surgelé", "Bissap séché"}})
}

func getProduit(c fiber.Ctx) error {
    // c.Params() lit le segment :id dans l'URL
    id := c.Params("id")
    return c.JSON(fiber.Map{"id": id, "nom": "Produit example"})
}

func creerProduit(c fiber.Ctx) error {
    return c.Status(fiber.StatusCreated).JSON(fiber.Map{"message": "Produit créé"})
}

func mettreAJourProduit(c fiber.Ctx) error {
    id := c.Params("id")
    return c.JSON(fiber.Map{"id": id, "message": "Mis à jour"})
}

func supprimerProduit(c fiber.Ctx) error {
    return c.SendStatus(fiber.StatusNoContent)
}

Quelques points importants à noter sur ce code. La fonction c.Next() dans le middleware est le mécanisme de passage à l’étape suivante dans la chaîne de traitement — exactement comme next() dans Express. La méthode app.Group() crée un sous-routeur avec un préfixe commun, ce qui permet de versionner votre API (/api/v1, /api/v2) sans dupliquer les enregistrements de middleware. fiber.Map est un alias de map[string]interface{} pratique pour construire des réponses JSON à la volée. Testez les routes avec curl -X POST http://localhost:3000/api/v1/produits et curl http://localhost:3000/api/v1/produits/42.

Étape 5 — Validation des requêtes et binding JSON

Accepter du JSON arbitraire sans validation est la source numéro un de bugs et de failles dans les API. Fiber v3 intègre un système de binding qui parse le corps de la requête et le mappe vers une struct Go — et Go étant statiquement typé, la struct elle-même constitue un premier niveau de validation (les champs attendus, leurs types). Pour des règles métier plus fines (champ obligatoire, longueur min/max, format email), on associe généralement le validateur go-playground/validator.

Installez le validateur :

go get github.com/go-playground/validator/v10

Voici comment définir une struct de requête avec ses règles de validation, et un handler qui les applique avant d’utiliser les données :

package main

import (
    "log"

    "github.com/go-playground/validator/v10"
    "github.com/gofiber/fiber/v3"
)

// validate est une instance partagée — créer une seule fois est la bonne pratique
var validate = validator.New()

// CreerProduitDTO représente le corps attendu pour créer un produit
type CreerProduitDTO struct {
    Nom      string  `json:"nom" validate:"required,min=2,max=100"`
    Prix     float64 `json:"prix" validate:"required,gt=0"`
    Categorie string `json:"categorie" validate:"required,oneof=alimentaire textile electronique"`
}

func creerProduitAvecValidation(c fiber.Ctx) error {
    dto := new(CreerProduitDTO)

    // BodyParser parse le JSON et le mappe sur la struct
    if err := c.Bind().JSON(dto); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{
            "erreur": "Corps de requête invalide",
            "detail": err.Error(),
        })
    }

    // Applique les règles de validation déclarées dans les tags
    if err := validate.Struct(dto); err != nil {
        // Convertit les erreurs de validation en réponse lisible
        erreurs := make(map[string]string)
        for _, e := range err.(validator.ValidationErrors) {
            erreurs[e.Field()] = e.Tag()
        }
        return c.Status(fiber.StatusUnprocessableEntity).JSON(fiber.Map{
            "erreur":  "Données invalides",
            "champs": erreurs,
        })
    }

    // Ici, dto est garanti valide — on peut le persister
    return c.Status(fiber.StatusCreated).JSON(fiber.Map{
        "message": "Produit créé",
        "nom":     dto.Nom,
    })
}

func main() {
    app := fiber.New()
    app.Post("/api/v1/produits", creerProduitAvecValidation)
    log.Fatal(app.Listen(":3000"))
}

Testez la validation avec une requête volontairement incorrecte : curl -X POST http://localhost:3000/api/v1/produits -H 'Content-Type: application/json' -d '{"nom":"A","prix":-5}'. La réponse doit être un 422 Unprocessable Entity avec un objet JSON détaillant les champs en erreur (nom: min, prix: gt, categorie: required). C’est exactement le comportement attendu par une API REST correcte : ne jamais laisser des données invalides pénétrer dans la couche métier.

Étape 6 — Connexion PostgreSQL avec pgx v5

Une API de production lit et écrit dans une base de données. PostgreSQL est le choix naturel pour les projets sérieux en Afrique de l’Ouest — il est gratuit, robuste, supporte JSON natif (utile pour stocker des métadonnées flexibles), et plusieurs hébergeurs locaux comme DigitalOcean (accessible via Dollar africain sur certaines plateformes) ou Supabase offrent des instances gérées. La bibliothèque pgx v5 de Jack Christensen est le driver PostgreSQL Go le plus performant et le plus complet disponible en 2026.

La bonne pratique pour une application web est d’utiliser pgxpool (pool de connexions) plutôt qu’une connexion simple. Un pool maintient plusieurs connexions ouvertes en permanence, évitant le coût de l’établissement d’une nouvelle connexion TCP+TLS à chaque requête HTTP. Voici comment l’intégrer dans une application Fiber propre :

package main

import (
    "context"
    "log"
    "os"

    "github.com/gofiber/fiber/v3"
    "github.com/jackc/pgx/v5/pgxpool"
)

// App regroupe les dépendances — pattern simple pour éviter les variables globales
type App struct {
    DB *pgxpool.Pool
}

func main() {
    // Lire l'URL de connexion depuis l'environnement — ne jamais hardcoder
    dbURL := os.Getenv("DATABASE_URL")
    if dbURL == "" {
        log.Fatal("DATABASE_URL non défini")
    }

    // Créer le pool avec un contexte racine
    pool, err := pgxpool.New(context.Background(), dbURL)
    if err != nil {
        log.Fatalf("Impossible de créer le pool Postgres : %v", err)
    }
    defer pool.Close()

    // Vérifier la connectivité avant de démarrer le serveur
    if err := pool.Ping(context.Background()); err != nil {
        log.Fatalf("Postgres injoignable : %v", err)
    }
    log.Println("✓ Connexion Postgres établie")

    a := &App{DB: pool}

    app := fiber.New()
    app.Get("/api/v1/produits", a.listerProduitsDB)
    app.Post("/api/v1/produits", a.creerProduitDB)

    log.Fatal(app.Listen(":3000"))
}

func (a *App) listerProduitsDB(c fiber.Ctx) error {
    rows, err := a.DB.Query(context.Background(),
        "SELECT id, nom, prix FROM produits ORDER BY id DESC LIMIT 50")
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{
            "erreur": "Erreur base de données",
        })
    }
    defer rows.Close()

    type Produit struct {
        ID   int     `json:"id"`
        Nom  string  `json:"nom"`
        Prix float64 `json:"prix"`
    }

    var produits []Produit
    for rows.Next() {
        var p Produit
        if err := rows.Scan(&p.ID, &p.Nom, &p.Prix); err != nil {
            continue
        }
        produits = append(produits, p)
    }

    return c.JSON(fiber.Map{"produits": produits})
}

func (a *App) creerProduitDB(c fiber.Ctx) error {
    type Payload struct {
        Nom  string  `json:"nom"`
        Prix float64 `json:"prix"`
    }
    var p Payload
    if err := c.Bind().JSON(&p); err != nil {
        return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"erreur": err.Error()})
    }

    var id int
    err := a.DB.QueryRow(context.Background(),
        "INSERT INTO produits (nom, prix) VALUES ($1, $2) RETURNING id",
        p.Nom, p.Prix,
    ).Scan(&id)
    if err != nil {
        return c.Status(fiber.StatusInternalServerError).JSON(fiber.Map{
            "erreur": "Insertion échouée",
        })
    }

    return c.Status(fiber.StatusCreated).JSON(fiber.Map{"id": id})
}

Créez la table de test dans votre base Postgres avec CREATE TABLE produits (id SERIAL PRIMARY KEY, nom VARCHAR(100) NOT NULL, prix NUMERIC(10,2) NOT NULL);, puis démarrez avec DATABASE_URL="postgres://user:pass@localhost/mabd" go run main.go. Le message ✓ Connexion Postgres établie confirme que le pool est prêt. Notez l’utilisation des paramètres numérotés ($1, $2) au lieu de la concaténation de chaînes : c’est la protection contre les injections SQL, fondamentale dans toute API exposée publiquement.

Étape 7 — Build statique + image Docker optimisée

L’un des grands avantages de Go pour les équipes avec des ressources limitées est la production d’un binaire statique autonome : aucune dépendance d’exécution, aucune JVM, aucun interpréteur Python à installer sur le serveur cible. Avec Fiber, ce binaire inclut le serveur HTTP complet et toute la logique applicative dans un seul fichier exécutable. Pour une API Go typique, la taille du binaire compilé est de l’ordre de 8 à 15 Mo — parfait pour des images Docker légères et des déploiements rapides sur des connexions internet variables.

La meilleure pratique Docker pour Go est le multi-stage build : une première image de compilation (qui contient le SDK Go complet, ~300 Mo) produit le binaire, puis une image finale minimaliste ne contient que ce binaire. Créez un Dockerfile à la racine :

# ── Étape 1 : compilation ─────────────────────────────────────────────────────
FROM golang:1.25-alpine AS builder

# Désactive cgo pour un binaire 100 % statique sans dépendances libc
ENV CGO_ENABLED=0 GOOS=linux GOARCH=amd64

WORKDIR /app

# Copier go.mod et go.sum en premier pour profiter du cache Docker
# (les dépendances ne sont re-téléchargées que si ces fichiers changent)
COPY go.mod go.sum ./
RUN go mod download

# Copier le reste du code source
COPY . .

# Compiler avec les optimisations de taille (-ldflags)
RUN go build -ldflags="-s -w" -o /app/api .

# ── Étape 2 : image finale minimale ──────────────────────────────────────────
FROM scratch

# Copier les certificats CA depuis builder pour les appels HTTPS sortants
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

# Copier uniquement le binaire compilé
COPY --from=builder /app/api /api

# Exposer le port applicatif
EXPOSE 3000

# Point d'entrée
ENTRYPOINT ["/api"]

Construisez l’image avec docker build -t api-fiber:latest .. La première construction prend quelques minutes (téléchargement des dépendances). Les builds suivants sont rapides grâce au cache des layers Docker. Vérifiez la taille de l’image finale avec docker images api-fiber : vous devriez obtenir une image entre 8 et 15 Mo — comparable à une image Nginx vide, et incomparablement plus légère qu’une image Node.js (environ 300 Mo). Testez localement avec docker run -p 3000:3000 -e DATABASE_URL="postgres://..." api-fiber:latest avant de pousser vers votre registre.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Déployer une API Go Fiber en Afrique de l’Ouest présente des opportunités et des contraintes spécifiques que les tutoriels européens ignorent généralement. Voyons comment adapter chaque couche de la stack.

Hébergement économique. Le binaire Go Fiber tourne parfaitement sur un Hetzner CX22 (2 vCPU Intel, 4 Go RAM, 40 Go SSD, 20 To de trafic, environ 3,79 €/mois en 2025-2026), accessible via PayPal ou carte prépayée Visa. Pour une API avec 100 à 500 requêtes simultanées, cette machine suffit amplement grâce au faible empreinte mémoire de fasthttp. Contrairement à une application Node.js ou Python qui nécessiterait souvent 1 à 2 Go de RAM au repos, un binaire Go Fiber bien écrit démarre en moins de 50 Mo de RAM, laissant le reste pour PostgreSQL ou Redis en colocation.

Intégration des passerelles de paiement locales. Wave (Sénégal, Côte d’Ivoire, Mali) et CinetPay (multi-pays CEDEAO) exposent des APIs REST JSON standard — exactement ce que Go Fiber sait consommer. Créez un package dédié dans votre projet (internal/payment/wave.go, internal/payment/cinetpay.go) avec les clients HTTP Go natifs (net/http pour les appels sortants — Fiber utilise fasthttp uniquement pour le serveur entrant, pas pour les clients HTTP). La gestion des webhooks de confirmation de paiement est triviale avec Fiber : un endpoint POST avec vérification de signature HMAC-SHA256.

Zones isolées et déploiement on-prem. Dans plusieurs pays de la sous-région, des entreprises opèrent des datacenters privés ou des infrastructures on-premise avec connectivité Internet intermittente. Le binaire statique Go est ici un atout majeur : aucun package manager à exécuter, aucune dépendance à résoudre au démarrage. Copiez le binaire sur le serveur (via scp ou une clé USB si nécessaire), configurez un service systemd, et l’API redémarre automatiquement après coupure électrique. Une image Docker de 10 Mo peut également être transférée via un simple docker save | gzip et docker load sans accès à un registre distant.

Bande passante et optimisation des réponses. Sur des connexions ADSL ou fibre partagée typiques de Dakar, Abidjan ou Ouagadougou, la compression gzip des réponses JSON est essentielle. Fiber propose un middleware de compression en une ligne : app.Use(compress.New()) après go get github.com/gofiber/fiber/v3/middleware/compress. Pour les API mobiles, utilisez systématiquement des champs de pagination (limit, offset ou curseurs) pour limiter la taille des réponses et ne jamais renvoyer des milliers d’enregistrements en un seul appel.

Tutoriels frères

• Rust Axum : API REST haute performance en Rust pour PME — tutoriel frère du même cluster, pour les équipes prêtes à investir dans la sécurité mémoire compile-time.
• Elixir Phoenix LiveView : API temps-réel et channels pour applications collaboratives — idéal si votre projet nécessite des WebSockets et de la concurrence massive via le modèle acteurs.

Pour aller plus loin

• 🔝 Retour au pilier : Frameworks backend 2026 pour PME francophone : Rust Axum, Go Fiber, Elixir Phoenix
• gofiber.io — site officiel Fiber, documentation v3, exemples
• github.com/gofiber/fiber — code source, issues, releases
• docs.gofiber.io — référence complète de l’API, middleware contrib officiel
• pkg.go.dev/github.com/jackc/pgx/v5 — documentation pgx v5
• go.dev/doc — documentation officielle Go, tour interactif

FAQ

Q : Fiber est-il adapté pour de la production en 2026, ou est-ce encore expérimental ?
R : Fiber est pleinement adapté à la production. Fiber v3.0.0 est sorti en version stable, et de nombreuses entreprises utilisent Fiber v2 en production depuis 2020. La migration de v2 à v3 est documentée sur docs.gofiber.io/blog/whats-new-in-fiber-v3. La bibliothèque sous-jacente fasthttp est maintenue activement et utilisée par des milliers de projets en production dans le monde.

Q : Pourquoi Fiber ne supporte-t-il pas HTTP/2 nativement ?
R : fasthttp, le moteur sur lequel repose Fiber, ne supporte pas HTTP/2. C’est un choix architectural délibéré : HTTP/2 introduit une complexité de multiplexage incompatible avec l’approche zero-allocation de fasthttp. Si votre API doit servir des navigateurs directement et profiter du multiplexage HTTP/2, placez un reverse proxy Nginx ou Caddy en frontal (Nginx supporte HTTP/2 et proxifie vers votre API Fiber en HTTP/1.1 sur le réseau local, ce qui n’a aucun impact sur les performances internes).

Q : Puis-je utiliser les middleware net/http existants (comme ceux de Gorilla Mux) avec Fiber ?
R : Non directement. Fiber utilisant fasthttp et non net/http, les middleware écrits pour l’interface standard http.Handler ne sont pas compatibles. Il existe cependant un adaptateur fiber.Adaptor dans le package contrib officiel qui permet d’encapsuler un http.Handler pour l’utiliser dans Fiber — utile si vous avez un middleware OAuth ou de telemetry qui ne propose que l’interface standard.

Q : Comment gérer les variables d’environnement en production avec Fiber ?
R : Go ne charge pas de fichier .env automatiquement. En développement, utilisez un package comme godotenv (go get github.com/joho/godotenv) pour charger un fichier .env local. En production (Docker, systemd), injectez les variables directement via l’environnement du conteneur ou du service — n’incluez jamais le fichier .env dans votre image Docker ni dans votre dépôt Git.

Q : Quelle est la différence entre c.Bind().JSON() en Fiber v3 et c.BodyParser() en Fiber v2 ?
R : Fiber v3 a unifié et amélioré son API de binding. c.Bind().JSON(&dto) remplace c.BodyParser(&dto) tout en ajoutant le support du binding de query params (c.Bind().Query(&dto)), des headers (c.Bind().Header(&dto)) et des params d’URL (c.Bind().URI(&dto)) via la même interface fluide. Les deux approches sont fonctionnellement équivalentes pour le parsing JSON, mais la nouvelle API v3 est plus cohérente et plus facile à tester.

Q : Comment déployer avec zéro downtime sur un VPS Hetzner ?
R : L’approche la plus simple est Docker avec un swap de conteneur. Construisez la nouvelle image, poussez-la sur votre serveur, puis exécutez docker stop api && docker rm api && docker run -d --name api --restart=always -p 3000:3000 api-fiber:latest. Le downtime est de l’ordre de quelques secondes (le temps du restart). Pour un vrai zéro downtime, utilisez Docker Swarm ou configurez deux instances derrière un Nginx avec upstream et basculement, ou encore utilisez le rolling update de Docker Compose v2 (docker compose up -d --no-deps api). Sur un CX22 à usage raisonnable, le restart en quelques secondes est souvent acceptable pour une PME.

Site réalisé par [ITS] ITSkillsCenter — formation tech pour l’Afrique de l’Ouest.