DEV Community: Rodolphe D.

Handler / service / repository expliqué à un dev Express

Rodolphe D. — Tue, 18 Aug 2026 10:00:00 +0000

En Semaine 1, on a sorti la logique du handler. Un geste, une fonction : registerUser. Ça a tout changé — jusqu'au jour où cette fonction devient le nouveau monolithe.

Rodolphe D.

Jul 17

Pourquoi tes routes Express deviennent illisibles (et le seul geste qui les sauve)

#node #javascript #webdev #architecture

7 min read

Aujourd'hui, on coupe ce monolithe en trois rôles que tu as déjà croisés sous d'autres noms : handler, service, repository. Pas pour coller un diagramme sur le frigo. Pour savoir où mettre la prochaine règle métier quand le fichier grossit — sans retomber dans le routes.js de 400 lignes.

Promesse : à la fin, tu sauras qui fait quoi, tu auras le découpage sur le register que tu connais, et tu sauras aussi quand ne pas le faire.

1. Le problème après le premier geste

Voici où on en était. La logique est hors du handler — bien. Mais elle fait encore tout :

async function registerUser({ email, password }) {
  if (!email || !email.includes('@')) {
    throw new ValidationError('Email invalide')
  }
  if (!password || password.length < 8) {
    throw new ValidationError('Mot de passe trop court (8 caractères min)')
  }

  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    throw new ConflictError('Cet email est déjà utilisé')
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })

  try {
    await sendWelcomeEmail(user.email)
  } catch (err) {
    console.error('Envoi email échoué', err)
  }

  return { id: user.id, email: user.email }
}

Trois natures de travail dans la même fonction :

Règles métier — « email valide », « mot de passe ≥ 8 », « email unique ».
Persistance — findUnique, create.
Effet de bord — l'email de bienvenue.

Tant que c'est court, ça va. Le jour où tu ajoutes « vérifier un code d'invitation », « écrire dans une table d'audit », « choisir le provider d'email selon l'env », cette fonction devient le fichier que tu n'oses plus ouvrir — juste un cran plus bas dans la pile.

Le premier geste (sortir du handler) reste nécessaire. Il n'est plus suffisant.

2. Les trois rôles, en français de café

Oublie un instant les buzzwords. Pose-toi trois questions sur chaque bout de code :

Question	Rôle	En Express, ça ressemble à…
« Comment je parle HTTP ? »	Handler	la route, le controller
« Qu'est-ce que mon produit autorise / décide ? »	Service	la logique métier, parfois appelée use case
« Comment je lis / écris les données ? »	Repository	l'accès Prisma / SQL / ORM

Le handler décode req, appelle le service, traduit résultat/erreur en status HTTP. Il ne connaît pas Prisma. Il ne hash pas de mot de passe.
Le service applique les règles. Il dit « cet email est déjà pris ». Il ne sait pas si ça vient de Postgres ou d'un mock en mémoire. Il ne connaît pas res.status.
Le repository parle à la base. findByEmail, create. Pas de règle « mot de passe trop court » ici — ce n'est pas son job.

Le test mental, le même qu'en Semaine 1, se décline :

Peux-tu tester une règle métier sans lancer Express ? → service isolé.
Peux-tu changer de base (ou mocker) sans réécrire les règles ? → repository derrière une interface claire.
Peux-tu lire la route en 10 secondes ? → handler mince.

3. Le même register, découpé

Repository — la base, rien d'autre

// userRepository.js
class UserRepository {
  constructor(prisma) {
    this.prisma = prisma
  }

  findByEmail(email) {
    return this.prisma.user.findUnique({ where: { email } })
  }

  create({ email, passwordHash }) {
    return this.prisma.user.create({
      data: { email, passwordHash },
    })
  }
}

module.exports = { UserRepository }

Pas de validation. Pas de bcrypt. Des questions à la base, des réponses.

Service — les règles du produit

// registerService.js
const bcrypt = require('bcrypt')
const { sendWelcomeEmail } = require('./mailer')

class ValidationError extends Error {}
class ConflictError extends Error {}

class RegisterService {
  constructor(users) {
    this.users = users // UserRepository
  }

  async register({ email, password }) {
    if (!email || !email.includes('@')) {
      throw new ValidationError('Email invalide')
    }
    if (!password || password.length < 8) {
      throw new ValidationError('Mot de passe trop court (8 caractères min)')
    }

    const existing = await this.users.findByEmail(email)
    if (existing) {
      throw new ConflictError('Cet email est déjà utilisé')
    }

    const passwordHash = await bcrypt.hash(password, 12)
    const user = await this.users.create({ email, passwordHash })

    try {
      await sendWelcomeEmail(user.email)
    } catch (err) {
      console.error('Envoi email échoué', err)
    }

    return { id: user.id, email: user.email }
  }
}

module.exports = { RegisterService, ValidationError, ConflictError }

Le service orchestre. Il décide. Il délègue le stockage au repository. Toujours zéro req / res.

Handler — le traducteur HTTP

// handler.js
const express = require('express')
const { PrismaClient } = require('@prisma/client')
const { UserRepository } = require('./userRepository')
const {
  RegisterService,
  ValidationError,
  ConflictError,
} = require('./registerService')

const prisma = new PrismaClient()
const users = new UserRepository(prisma)
const registerService = new RegisterService(users)

const app = express()
app.use(express.json())

app.post('/register', async (req, res, next) => {
  try {
    const user = await registerService.register(req.body)
    return res.status(201).json(user)
  } catch (err) {
    if (err instanceof ValidationError) {
      return res.status(400).json({ error: err.message })
    }
    if (err instanceof ConflictError) {
      return res.status(409).json({ error: err.message })
    }
    return next(err)
  }
})

module.exports = app

Même job qu'en Semaine 1 — mais il appelle un service, pas une fonction fourre-tout. Le câblage (prisma → repo → service) se fait une fois, au démarrage. Les routes ne créent plus leurs dépendances dans le handler.

4. Ce que ça change concrètement

Tester sans HTTP ni vraie DB. Tu injectes un faux repository :

const { test } = require('node:test')
const assert = require('node:assert')
const { RegisterService, ValidationError } = require('./registerService')

test('refuse un mot de passe trop court', async () => {
  const fakeUsers = {
    findByEmail: async () => null,
    create: async () => {
      throw new Error('ne doit pas être appelé')
    },
  }
  const service = new RegisterService(fakeUsers)

  await assert.rejects(
    () => service.register({ email: 'ada@example.com', password: '123' }),
    ValidationError,
  )
})

La règle métier est vérifiée. Aucun Express. Aucun Postgres. Le fake ne fait que ce que le service a le droit d'attendre du repository.

Changer d'outil sans réécrire le métier. Demain tu remplaces Prisma par pg brut, ou tu ajoutes un cache devant findByEmail : tu touches le repository. Le service et le handler restent.

Lire le projet par responsabilité. « Où est la règle du mot de passe ? » → service. « Où est la requête SQL / Prisma ? » → repository. « Où est le 409 ? » → handler. Tu ne fouilles plus un seul fichier de 300 lignes pour les trois réponses.

5. Et en Go, c'est la même carte

Si tu as suivi la Semaine 2 et la Semaine 4, tu as déjà vu le handler mince et les erreurs-valeurs. Le découpage se lit pareil :

Express	Go (idée)
`RegisterService.register`	`RegisterService.Register` (méthode sur un struct)
`UserRepository.findByEmail`	`UserRepository.FindByEmail`
injection via `constructor`	injection via champs du struct + câblage dans `main`
`instanceof ValidationError`	`errors.Is(err, ErrValidation)`

Même carte mentale. Autre syntaxe. La semaine prochaine, on pose exactement ce squelette en Go — pas en théorie, en arborescence de projet.

6. Quand ne pas faire ça

Trois couches pour un script de 40 lignes, c'est du théâtre.

Règle simple que j'utilise :

Une route, logique courte → fonction + handler mince (Semaine 1). Stop.
La fonction métier mélange règles et SQL, et ça commence à faire mal → introduis service / repository.
Tu ajoutes une deuxième façon d'entrer (job cron, CLI, autre transport) → le service devient obligatoire ; le handler HTTP n'est plus le seul client.

Ce n'est pas « clean architecture ou rien ». C'est « un cran de découpe quand la douleur apparaît », pas avant. Les projets juniors que je vois partent trop souvent du diagramme à six couches et n'écrivent jamais la première règle métier.

7. Ce qu'il faut retenir

Handler = HTTP. Service = décisions du produit. Repository = données. Le premier geste (sortir du handler) reste la fondation ; ces trois rôles sont ce que tu ajoutes quand registerUser devient le nouveau fichier qu'on évite.

Si tu ne retiens qu'une phrase : chaque couche a une seule question à laquelle répondre — et elle ne répond pas aux deux autres.

La semaine prochaine : on pose le squelette du fil rouge Go — ton premier vrai backend, structuré handler / service / repository, prêt à grandir (parties 2 et 3 plus tard).

La série continue.

Ce que Go t'oblige à faire que Node te laissait éviter : les erreurs explicites

Rodolphe D. — Tue, 11 Aug 2026 12:15:46 +0000

En Semaine 2, on a posé le même POST /register en Express et en Go, côte à côte. Un fil est resté volontairement tendu : if err != nil partout, une erreur qui se renvoie au lieu de se lancer. Plaisir ou corvée ?

Rodolphe D.

Jul 21

De Node à Go : le même POST /register, côte à côte

#go #javascript #node #webdev

7 min read

Aujourd'hui, on coupe ce fil. Pas pour te convaincre que Go a inventé la gestion d'erreurs — Node sait aussi gérer des erreurs. Pour montrer ce que Go refuse de te laisser faire, et ce que Node te laisse éviter jusqu'au jour où ça te revient en pleine face.

Promesse simple : à la fin, tu sauras pourquoi if err != nil n'est pas du bruit, et tu auras un schéma mental pour traduire tes try/catch en retours d'erreur Go — sans perdre le fil métier.

1. Ce que Node te laisse faire (et que tu fais)

En Node, une erreur est optionnelle jusqu'à ce qu'elle explose.

Tu peux écrire ceci, et ça tourne :

async function registerUser({ email, password }) {
  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    throw new ConflictError('Cet email est déjà utilisé')
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })
  await sendWelcomeEmail(user.email) // et si ça plante ?
  return { id: user.id, email: user.email }
}

Trois façons de "gérer" l'échec de sendWelcomeEmail, toutes légales :

Ne rien faire. L'erreur remonte, le catch du handler (s'il existe) la transforme en 500. L'inscription a peut-être réussi en base, mais le client reçoit une erreur. Ou pire : pas de catch, et le process crache un UnhandledPromiseRejection.
Avaler silencieusement. Un try/catch vide, ou un .catch(() => {}). L'inscription réussit, l'email disparaît dans le vide, personne n'est prévenu.
Logger et continuer. Comme en Semaine 1 : on catch, on console.error, on renvoie quand même l'utilisateur créé. C'est le bon choix ici — mais rien dans le langage ne te l'impose.

Le point n'est pas que Node est mauvais. C'est que le langage te laisse choisir de ne pas choisir. Tu peux oublier un await. Tu peux oublier un catch. Tu peux laisser une Promise rejeter sans jamais la regarder. Le runtime proteste parfois, parfois trop tard, parfois jamais en local.

Et le pire : ça a l'air de marcher. Jusqu'à ce qu'un email ne parte pas en prod, ou qu'un findUnique échoue pour une raison réseau et que tu te retrouves avec un undefined que tu traites comme un user.

2. Ce que Go refuse

En Go, une fonction qui peut échouer le dit dans sa signature. Pas dans un commentaire. Pas dans un @throws que personne ne lit. Dans le type de retour.

func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error)

Deux valeurs. Le résultat et l'erreur. L'appelant voit qu'il y a une erreur possible. Et le compilateur ne te laisse pas faire semblant :

user, err := RegisterUser(db, in)
// Si tu ignores err et que tu utilises user, tu as un bug.
// Go ne te force pas à checker err — mais la convention, l'outil, et
// tout le code autour te le rappellent à chaque ligne.

Petite nuance honnête, parce que je n'aime pas les slogans : Go ne compile pas un oubli de if err != nil. Tu peux écrire _ = err ou ignorer err et continuer. Ce n'est pas un garde-fou magique du compilateur.

Ce qui change, c'est ailleurs :

L'erreur est une valeur, pas un événement qui traverse la pile en silence.
Elle est dans le flux : tu la vois à chaque appel, dans le même ordre que le code métier.
La convention est si forte (if err != nil { return ..., err }) que le code qui l'ignore se remarque. Un _ = err crie. Un throw oublié en JS, non.

Node te laisse éviter. Go te met l'échec sous le nez, à chaque étape.

3. Le même register, vu par les erreurs

Reprends RegisterUser de la Semaine 2, mais cette fois on ne regarde que le chemin des erreurs.

func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error) {
    if !strings.Contains(in.Email, "@") {
        return RegisteredUser{}, fmt.Errorf("%w: email invalide", ErrValidation)
    }
    if len(in.Password) < 8 {
        return RegisteredUser{}, fmt.Errorf("%w: mot de passe trop court (8 caractères min)", ErrValidation)
    }

    var exists bool
    if err := db.QueryRow(
        "SELECT EXISTS(SELECT 1 FROM users WHERE email = $1)", in.Email,
    ).Scan(&exists); err != nil {
        return RegisteredUser{}, err // erreur infra : on la remonte telle quelle
    }
    if exists {
        return RegisteredUser{}, ErrConflict
    }

    hash, err := bcrypt.GenerateFromPassword([]byte(in.Password), 12)
    if err != nil {
        return RegisteredUser{}, err
    }

    var id string
    if err := db.QueryRow(
        "INSERT INTO users (email, password_hash) VALUES ($1, $2) RETURNING id",
        in.Email, string(hash),
    ).Scan(&id); err != nil {
        return RegisteredUser{}, err
    }

    if err := sendWelcomeEmail(in.Email); err != nil {
        // Choix métier explicite : l'email ne doit pas faire échouer l'inscription.
        log.Printf("envoi email échoué: %v", err)
    }

    return RegisteredUser{ID: id, Email: in.Email}, nil
}

Chaque if err != nil est une décision écrite :

Étape	Si ça échoue	Décision
Validation email / password	Données pourries	Erreur métier (`ErrValidation`), stop
`QueryRow` EXISTS	Base down / SQL cassé	Remonter l'erreur infra, stop
Email déjà pris	Conflit métier	`ErrConflict`, stop
`bcrypt`	Rare, mais possible	Remonter, stop
`INSERT`	Contrainte, réseau, etc.	Remonter, stop
Email de bienvenue	SMTP down	Logger et continuer

En Node, la dernière ligne du tableau est souvent un oubli ou un try/catch collé après coup. Ici, le "continuer malgré l'échec de l'email" est une ligne que tu lis dans le flux principal. Ce n'est plus un détail caché dans un catch trois niveaux plus haut.

C'est ça, le vrai contraste : l'échec n'est plus un événement latéral, c'est une branche du code métier.

4. `errors.Is`, wrapping, et pourquoi `fmt.Errorf("%w")`

En Semaine 1–2, côté Express, on avait des classes : ValidationError, ConflictError. Le handler faisait instanceof.

En Go, l'équivalent idiomatique :

var (
    ErrValidation = errors.New("données invalides")
    ErrConflict   = errors.New("cet email est déjà utilisé")
)

Et pour ajouter du contexte sans perdre l'identité de l'erreur :

return RegisteredUser{}, fmt.Errorf("%w: email invalide", ErrValidation)

Le %w (wrap) dit : "cette erreur est encore ErrValidation, avec un message plus précis". Le handler peut alors faire :

user, err := RegisterUser(db, in)
switch {
case err == nil:
    // 201 + JSON
case errors.Is(err, ErrValidation):
    http.Error(w, err.Error(), http.StatusBadRequest)
case errors.Is(err, ErrConflict):
    http.Error(w, err.Error(), http.StatusConflict)
default:
    http.Error(w, "erreur serveur", http.StatusInternalServerError)
}

Pourquoi pas comparer avec == ? Parce qu'après un wrap, err == ErrValidation est faux — tu as une nouvelle valeur qui contient ErrValidation. errors.Is déroule la chaîne. C'est l'instanceof des erreurs-valeurs.

Et le default ? C'est le filet pour tout ce que tu n'as pas nommé : timeout DB, disque plein, bug. Tu ne fuis pas ces erreurs — tu refuses de les exposer telles quelles au client. En Node, l'équivalent est souvent un next(err) vers un middleware d'erreur global. Même idée, mais en Go tu le vois dans le handler, pas trois fichiers plus loin.

5. La traduction mentale Node → Go

Si tu viens de JS, voilà le tableau que j'aurais voulu avoir le premier jour :

Node	Go
`throw new Error(...)`	`return zeroValue, err`
`try { ... } catch (e) { ... }`	`if err != nil { ... }` juste après l'appel
`instanceof ValidationError`	`errors.Is(err, ErrValidation)`
Classe d'erreur custom	`var ErrX = errors.New("...")` (+ wrap `%w` pour le détail)
Promise rejetée non catchée	Valeur `error` non inspectée (visible, mais pas bloquée par le compilateur)
`async/await` qui "saute" au catch	Retour anticipé `return ..., err` — le flux reste linéaire

Un piège classique quand on débarque : vouloir recréer try/catch avec un panic / recover. Ça existe. Ce n'est pas le chemin pour les erreurs attendues (validation, conflit, DB down). panic, c'est pour "le programme ne peut plus continuer de façon sensée" — bug, invariant cassé. Pas pour "l'email est déjà pris".

Si tu te surprends à écrire panic pour une 400, tu es en train de réimporter le modèle mental Node dans un langage qui a un autre contrat.

6. Et le bruit dans le code ?

Objection légitime : "ok, mais c'est verbeux. Quatre lignes pour un appel qui en ferait une en JS."

Oui. Au début, ça grince. Puis trois choses arrivent.

D'abord, tu arrêtes de te demander où l'erreur est gérée. Elle est gérée ici, ou elle est renvoyée ici. Pas de chasse au catch manquant trois fonctions plus haut.

Ensuite, tu te mets à lire les erreurs comme du métier. "Si l'INSERT échoue, on remonte. Si l'email échoue, on log." Ce n'est plus du plomberie — c'est la spec, écrite en Go.

Enfin, tu remarques que Node n'était pas plus court : tu avais déplacé le coût. Moins de lignes dans le happy path, plus d'incertitude sur le chemin d'échec. Go inverse le trade-off : plus de lignes, moins d'incertitude.

Je ne vais pas te dire que c'est toujours agréable. Certains jours, le dixième if err != nil de la fonction me fatigue. Mais je ne me suis jamais réveillé à 3 h du matin en me demandant pourquoi une Promise avait rejeté en silence dans un job cron. Ce genre de nuit, Go me les a largement évitées.

7. Mini-exercice : le piège du `_`

Avant de refermer, un anti-pattern à reconnaître au premier coup d'œil :

user, _ := RegisterUser(db, in) // ❌ l'erreur disparaît
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(user)   // user peut être vide / partiel

Le _ dit au compilateur "je sais, je jette". En review, c'est un drapeau rouge sauf cas très documenté (ex. une fermeture de fichier où tu as déjà décidé d'ignorer l'erreur de Close — et encore, on débat).

La version honnête :

user, err := RegisterUser(db, in)
if err != nil {
    // traduire en HTTP, ou remonter
    return
}

Si tu dois vraiment ignorer, écris pourquoi en une ligne de commentaire. Le silence du _ sans explication, c'est exactement le comportement que Node te laissait avoir par défaut — et qu'on essaye de ne plus reproduire.

8. Ce qu'il faut retenir

Go ne t'apprend pas "à mieux gérer les erreurs" par magie. Il t'empêche de faire comme si l'échec n'existait pas. Chaque appel qui peut rater te tend une valeur error. Tu la traites, tu la wrap, ou tu l'assumes à voix haute. Ce que Node te laissait éviter — l'oubli, le catch manquant, la Promise orpheline — devient une décision visible dans le fichier.

Si tu ne retiens qu'une phrase : en Go, l'erreur est une valeur dans le flux ; en Node, c'est souvent un événement que tu peux rater.

La semaine prochaine : Handler / service / repository, expliqué à un dev Express — comment découper quand le fichier grossit, sans retomber dans le monolithe de routes de la Semaine 1.

La série continue.

« J'ai fini le tuto Node, et là je suis bloqué » — le mur dont personne ne parle

Rodolphe D. — Fri, 07 Aug 2026 06:20:00 +0000

Tu as fini le tuto.

Le vrai, le gros, celui de douze heures. Tu as tout suivi, tout tapé, tout fait tourner. À la fin, l'application marchait. Tu t'es senti capable. Tu t'es dit : « ça y est, je sais faire une API ».

Et puis tu as ouvert un dossier vide pour faire la tienne.

Curseur qui clignote. index.js. Rien.

Pas parce que tu as oublié la syntaxe. Tu la connais. Mais là, tout seul, sans quelqu'un qui te dit quoi taper à la ligne suivante, tu ne sais pas par où commencer. Et cette sensation-là, ce vide entre « j'ai fini le tuto » et « je sais faire », personne ne t'avait prévenu qu'elle existait.

C'est de ce mur que je veux parler. Parce que ce n'est pas un défaut chez toi. C'est une étape.

1. Le piège n'est pas le tuto, c'est ce qu'il te cache

Un tuto, c'est une suite de bonnes décisions déjà prises pour toi.

Quel dossier créer. Quel package installer. Où mettre le fichier de config. Quand extraire une fonction. À chaque embranchement, le formateur a choisi le bon chemin, et toi tu l'as suivi. Tu as tapé du code, oui. Mais tu n'as pris aucune décision.

Or coder, le vrai coder, c'est presque que ça : décider. Choisir entre deux structures. Trancher un nom de variable. Décider si ce bout de logique mérite sa propre fonction. Un développeur qui bosse, ce n'est pas quelqu'un qui connaît toutes les réponses — c'est quelqu'un qui sait avancer quand il n'y en a pas.

Le tuto t'a entraîné à taper. Il ne t'a pas entraîné à décider. Et c'est exactement la compétence qui te manque devant ton dossier vide. Ce n'est pas un trou dans ton savoir. C'est un muscle que tu n'as jamais sollicité, parce qu'on ne te l'a jamais laissé faire.

2. Pourquoi « un tuto de plus » ne réglera rien

Ta réaction instinctive face au blocage, c'est de retourner là où tu te sens compétent. Un autre tuto. Un cours de plus. Une nouvelle techno à cocher.

Je comprends le réflexe. Le tuto, c'est confortable : il y a une barre de progression, une fin, une petite dose de « j'ai réussi » à chaque étape. Le dossier vide, lui, ne te donne rien. Aucune barre, aucune validation, juste toi et des décisions à prendre.

Mais chaque tuto supplémentaire renforce précisément le muscle que tu as déjà, et laisse s'atrophier celui qui te manque. Tu deviens très bon à suivre, et toujours aussi bloqué à décider. C'est le fameux tutorial hell : pas un manque de connaissances, un excès de connaissances jamais mises à l'épreuve du choix.

La sortie n'est pas d'apprendre plus. Elle est de décider plus, sur un terrain assez petit pour que ce soit supportable.

3. La sortie : le plus petit projet qui décide à ta place de rien

Le mur tombe le jour où tu construis quelque chose que le tuto n'a pas prémâché. Mais « construis ton projet ! » est un conseil inutile — c'est justement le dossier vide qui te paralyse.

Alors on rétrécit. Beaucoup.

Pas une app. Pas un clone de Twitter. Une seule route qui fait une chose. Un endpoint GET /health qui répond { status: 'ok' }. C'est tout. Ça a l'air ridicule, et c'est le but : c'est assez petit pour que tu ne puisses pas te cacher derrière « je ne sais pas par où commencer ». Tu sais faire ça. Tu l'as fait cent fois dans les tutos.

La différence, cette fois : tu le fais dans un dossier vide, sans copier. Tu décides du nom du fichier. Tu décides d'installer Express ou d'utiliser le serveur natif. Tu décides où répondre. Chaque micro-décision est un peu inconfortable — et c'est exactement le muscle qui travaille.

const express = require('express')
const app = express()

app.get('/health', (req, res) => {
  res.json({ status: 'ok' })
})

app.listen(3000, () => console.log('En écoute sur le port 3000'))

Quinze lignes. Rien d'impressionnant. Mais si tu les as écrites sans tuto ouvert dans un autre onglet, tu viens de faire une chose que douze heures de vidéo ne t'avaient jamais fait faire : avancer seul.

Ensuite, tu ajoutes une décision à la fois. Une route POST qui reçoit un JSON. Puis une validation du champ reçu. Puis stocker les données quelque part — d'abord dans un tableau en mémoire, et tant pis si ce n'est pas « propre ». Chaque ajout est une nouvelle décision, prise par toi. C'est comme ça que le muscle grossit : par petites charges, pas en soulevant l'app entière d'un coup.

4. La règle qui garde le muscle en vie : jamais copier sans décider

Tu vas retomber sur des tutos, c'est inévitable, et c'est même utile. La question n'est pas de les fuir, c'est de changer ce que tu en fais.

La règle tient en une phrase : tu as le droit de lire n'importe quel tuto, mais pas de copier une ligne sans pouvoir dire pourquoi elle est là.

Concrètement. Tu bloques sur la validation d'un body, tu vas voir comment quelqu'un fait. Bien. Mais avant de coller sa solution dans ton projet, tu te forces à répondre : pourquoi cette ligne ? qu'est-ce qu'elle fait ? qu'est-ce qui casse si je l'enlève ? Si tu ne sais pas répondre, tu ne colles pas — tu creuses jusqu'à savoir. Le tuto redevient une doc que tu consultes, au lieu d'un pilote automatique que tu suis.

C'est la nuance entre apprendre dans un tuto et apprendre d'un tuto. La première te laisse bloqué au premier dossier vide. La seconde construit, décision après décision, le seul truc qui te fera passer le mur.

5. Ce qu'il faut retenir

Si tu es bloqué après avoir « tout appris », ce n'est pas que tu n'en sais pas assez. C'est que tu n'as jamais eu à décider seul, parce que le format tuto décide toujours à ta place.

La sortie n'est pas un cours de plus. C'est le plus petit projet possible, dans un dossier vide, où chaque ligne est une décision que tu prends toi-même — quitte à ce que ce soit déplaisant au début.

Et, le jour où décider ne te fait plus peur sur du petit, tu es prêt pour du plus gros. C'est aussi le moment idéal pour attaquer un langage qui te force la main sur ces décisions dès le départ — mais ça, c'est le sujet d'un autre article de la série.

Commence par ton GET /health. Aujourd'hui. Dossier vide, aucun onglet ouvert. C'est quinze lignes et c'est le premier mur qui tombe.

From Node to Go - the same POST /register, side by side

Rodolphe D. — Fri, 24 Jul 2026 09:15:32 +0000

A registration endpoint is small enough to hold in your head and real enough to hurt: validate the input, hash the password, write to the database, send a welcome email. In Express, I pulled the business logic out of the route handler — the logic in its own registerUser function, and a tiny handler whose only job is to translate HTTP into that logic and back. The result: a handler you can read at a glance, and a business rule you can test without ever starting a server. (The full before/after lives in the starter repo linked at the bottom — grab it if you want to run everything yourself.)

Today I'm changing the language, not the subject. I take that same endpoint and set it next to its Go equivalent. Same gesture, same split: the logic on one side, the HTTP handler on the other.

No sleight of hand, no framework hiding behind the curtain. Just the code, side by side. The contrasts come after — today, we just look.

1. The Express version, for reference

Same shape as before: the logic lives in registerUser, and a thin handler only translates.

const bcrypt = require('bcrypt')
const { PrismaClient } = require('@prisma/client')
const { sendWelcomeEmail } = require('./mailer')

const prisma = new PrismaClient()

class ValidationError extends Error {}
class ConflictError extends Error {}

// Business logic, decoupled from the framework: it knows nothing about
// req/res. You can call it from a script, a test, a job — anywhere.
async function registerUser({ email, password }) {
  if (!email || !email.includes('@')) {
    throw new ValidationError('Invalid email')
  }
  if (!password || password.length < 8) {
    throw new ValidationError('Password too short (8 characters minimum)')
  }

  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    throw new ConflictError('This email is already taken')
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })

  try {
    await sendWelcomeEmail(user.email)
  } catch (err) {
    console.error('Failed to send email', err)
  }

  return { id: user.id, email: user.email }
}

module.exports = { registerUser, ValidationError, ConflictError }

const express = require('express')
const { registerUser, ValidationError, ConflictError } = require('./registerUser')

const app = express()
app.use(express.json())

// The handler is thin: read the request, call the business logic,
// translate the result (or a business error) into an HTTP response.
app.post('/register', async (req, res, next) => {
  try {
    const user = await registerUser(req.body)
    return res.status(201).json(user)
  } catch (err) {
    if (err instanceof ValidationError) return res.status(400).json({ error: err.message })
    if (err instanceof ConflictError) return res.status(409).json({ error: err.message })
    return next(err)
  }
})

module.exports = app

2. The same endpoint, in Go

Here's the same endpoint, structured the same way, in Go: the logic on one side, the handler on the other.

One difference in layers I want to name right away, so you don't mistake it for magic: on the Express side, the database went through Prisma, an ORM. On the Go side, I'm showing plain SQL with database/sql — the idiomatic default in the language. It's a subject of its own, and I'll come back to it another day.

RegisterUser is the Go mirror of registerUser: the business logic, decoupled, with no knowledge of net/http.

package main

import (
    "database/sql"
    "errors"
    "fmt"
    "log"
    "strings"

    "golang.org/x/crypto/bcrypt"
)

// Business errors — the Go equivalent of ValidationError / ConflictError.
// They never mention an HTTP status: the logic doesn't know HTTP exists.
var (
    ErrValidation = errors.New("invalid input")
    ErrConflict   = errors.New("this email is already taken")
)

// RegisterInput describes, explicitly, the shape of the expected data.
type RegisterInput struct {
    Email    string
    Password string
}

// RegisteredUser describes what the function returns.
type RegisteredUser struct {
    ID    string
    Email string
}

// RegisterUser holds the business logic. It knows nothing about
// *http.Request or http.ResponseWriter: call it from a script, a test, a job.
func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error) {
    if !strings.Contains(in.Email, "@") {
        return RegisteredUser{}, fmt.Errorf("%w: invalid email", ErrValidation)
    }
    if len(in.Password) < 8 {
        return RegisteredUser{}, fmt.Errorf("%w: password too short (8 characters minimum)", ErrValidation)
    }

    var exists bool
    if err := db.QueryRow(
        "SELECT EXISTS(SELECT 1 FROM users WHERE email = $1)", in.Email,
    ).Scan(&exists); err != nil {
        return RegisteredUser{}, err
    }
    if exists {
        return RegisteredUser{}, ErrConflict
    }

    hash, err := bcrypt.GenerateFromPassword([]byte(in.Password), 12)
    if err != nil {
        return RegisteredUser{}, err
    }

    var id string
    if err := db.QueryRow(
        "INSERT INTO users (email, password_hash) VALUES ($1, $2) RETURNING id",
        in.Email, string(hash),
    ).Scan(&id); err != nil {
        return RegisteredUser{}, err
    }

    if err := sendWelcomeEmail(in.Email); err != nil {
        // Sending the email must not fail the registration.
        log.Printf("failed to send email: %v", err)
    }

    return RegisteredUser{ID: id, Email: in.Email}, nil
}

If you've never read Go, four landmarks are enough to keep you from getting lost in this file:

A function can return several values. Look at the signature: func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error). It hands back two things at once — the result and an error. That's the Go convention: you often return (result, error), and the caller checks the error right after. Nothing more to grasp here; I'll cover it in depth in the next piece.
nil is the absence of a value. The mental equivalent of the null you know. A db set to nil means "no connection."
:= declares and assigns at once (hash, err := ...), where var only declares (var id string). Two ways to introduce a variable, depending on whether you already have a value to put in it.
The initial capital decides visibility. RegisterUser starts with a capital: it's exported, visible from outside the package. sendWelcomeEmail, lowercase, stays private to the package. The language reads the case like a scope keyword.

With those four landmarks, the rest reads like pseudo-code.

The handler next — thin, only relaying HTTP to the business logic, exactly like the Express side.

package main

import (
    "database/sql"
    "encoding/json"
    "errors"
    "net/http"
)

// registerHandler is thin: decode, call RegisterUser, translate to HTTP.
// It is an HTTP<->domain translator, not a place where logic lives.
func registerHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        var in RegisterInput
        if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
            http.Error(w, "invalid request body", http.StatusBadRequest)
            return
        }

        user, err := RegisterUser(db, in)
        switch {
        case err == nil:
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusCreated)
            json.NewEncoder(w).Encode(user)
        case errors.Is(err, ErrValidation):
            http.Error(w, err.Error(), http.StatusBadRequest)
        case errors.Is(err, ErrConflict):
            http.Error(w, err.Error(), http.StatusConflict)
        default:
            http.Error(w, "server error", http.StatusInternalServerError)
        }
    }
}

And the wiring: a http.ServeMux from the standard library, mux.HandleFunc("POST /register", ...). No third-party router, no framework — just the stdlib.

package main

import (
    "database/sql"
    "log"
    "net/http"

    _ "github.com/jackc/pgx/v5/stdlib"
)

func main() {
    db, err := sql.Open("pgx", "postgres://user:pass@localhost:5432/register")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    mux := http.NewServeMux()
    mux.HandleFunc("POST /register", registerHandler(db))

    log.Println("listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", mux))
}

One detail in passing: sendWelcomeEmail is a stub here, the same way mailer.js was on the Express side — nothing to dwell on.

3. What jumps out

Now that we have both versions side by side, a few contrasts show up right away. No need to dig — they're right on the surface.

First, the types. In Go, RegisterInput and RegisteredUser are declared, in black and white, at the top of the file. The shape of the expected data isn't a tacit convention or a comment — it's written down, and the compiler enforces it. On the Express side, req.body is a dynamic object: its shape exists in your head, maybe in a comment, but nowhere does the language check it for you. That's what I like here: I don't have to guess what RegisterUser wants — the signature tells me.

Next, the errors: if err != nil everywhere, an error you return instead of throwing. I like seeing every possible failure written right there, in the flow — but it's a big topic, and it's the whole subject of the next deep dive in this series.

Something else that's missing: a framework. No Express, no equivalent. net/http comes from the standard library, and the POST /register routing you saw in main.go has been built in since recent versions of Go — zero HTTP dependencies to install. That changes the nature of the project: the router is nobody's business but the stdlib's. And there's a flip side I appreciate: no framework version to track, no breaking change to brace for at every upgrade.

Last point, the plain SQL with database/sql: the queries are spelled out in full inside RegisterUser, not tucked away behind an ORM. I'll admit I like seeing exactly what goes to the database, with no layer to guess at — but that too is a big subject of its own, for another day.

4. The proof it runs

Here's the test from the Express side, restated as a question: can you test this rule without starting an HTTP server? On the Express side the answer turned out to be yes, once the logic was out of the handler. Let's see what it looks like in Go.

package main

import (
    "errors"
    "testing"
)

// Validation happens before any DB access: no database and no server needed.
func TestRegisterUser_RejectsShortPassword(t *testing.T) {
    _, err := RegisterUser(nil, RegisterInput{Email: "ada@example.com", Password: "123"})
    if !errors.Is(err, ErrValidation) {
        t.Fatalf("expected ErrValidation, got: %v", err)
    }
}

Look at what doesn't happen. go test, and that's it: no server starting up, no database to spin up. The first argument passed to RegisterUser is literally nil — no connection, no mock, nothing. And it works, because the email and password validation fires before the code ever touches db. The business rule is checked in a few milliseconds, and it can fail for one reason only: itself.

It's the same demonstration as on the Express side, with node:test on registerUser. Change the language, keep the gesture: decouple the logic from the framework, and the test becomes trivial to write.

5. What's next

One thread was left deliberately taut in this piece: if err != nil, everywhere, at every call that can fail. A pleasure or a chore? That's the whole subject of the next deep dive.

If I had to sum up the feeling of this comparison in one sentence: on the Go side, everything is written down, nothing is hidden. The types, the errors, the SQL queries, the routing — it's all there, in front of you, in the file. At first it throws you a little; there are more lines to read. After a while, I find it restful: I never have to wonder what's happening behind a decorator or an ORM, because the answer is always in the file open in front of me.

The series continues.

Want to run the whole thing yourself? The full journey — Express before/after plus this Go version, both runnable from a clean clone — lives in the free node-to-go-starter repo, with a one-page Express→Go cheat sheet. Grab it here: https://github.com/bu7ch/node-to-go-starter.

De Node à Go : le même POST /register, côte à côte

Rodolphe D. — Tue, 21 Jul 2026 12:08:03 +0000

La semaine dernière, on a nettoyé le register en Express. La logique métier est sortie du handler, direction sa propre fonction registerUser : un handler devenu minuscule, un traducteur HTTP↔métier, et une règle métier qu'on peut tester sans lancer de serveur. Si tu ne l'as pas lu, commence par là — tout ce qui suit s'appuie dessus.

Aujourd'hui, on change de langage, pas de sujet. Je prends ce même endpoint — inscription, validation, hash du mot de passe, écriture en base, email de bienvenue — et je le pose à côté de son équivalent en Go. Même geste, même découpage : la logique d'un côté, le handler HTTP de l'autre.

Pas de tour de magie, pas de framework caché derrière. Juste le code, côte à côte. Les contrastes viendront ensuite — aujourd'hui, on regarde.

1. La version Express, pour mémoire

Tu connais déjà ce code, il vient de la semaine dernière : la logique dans registerUser, un handler mince qui ne fait que traduire.

const bcrypt = require('bcrypt')
const { PrismaClient } = require('@prisma/client')
const { sendWelcomeEmail } = require('./mailer')

const prisma = new PrismaClient()

class ValidationError extends Error {}
class ConflictError extends Error {}

async function registerUser({ email, password }) {
  if (!email || !email.includes('@')) {
    throw new ValidationError('Email invalide')
  }
  if (!password || password.length < 8) {
    throw new ValidationError('Mot de passe trop court (8 caractères min)')
  }

  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    throw new ConflictError('Cet email est déjà utilisé')
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })

  try {
    await sendWelcomeEmail(user.email)
  } catch (err) {
    console.error('Envoi email échoué', err)
  }

  return { id: user.id, email: user.email }
}

module.exports = { registerUser, ValidationError, ConflictError }

const express = require('express')
const { registerUser, ValidationError, ConflictError } = require('./registerUser')

const app = express()
app.use(express.json())

app.post('/register', async (req, res, next) => {
  try {
    const user = await registerUser(req.body)
    return res.status(201).json(user)
  } catch (err) {
    if (err instanceof ValidationError) return res.status(400).json({ error: err.message })
    if (err instanceof ConflictError) return res.status(409).json({ error: err.message })
    return next(err)
  }
})

module.exports = app

2. Le même endpoint, en Go

Voici le même endpoint, structuré pareil, en Go : la logique d'un côté, le handler de l'autre.

Une différence de couche à assumer tout de suite, pour ne pas te laisser croire à une magie : côté Express, la base passait par Prisma, un ORM. Côté Go, je montre du SQL direct avec database/sql — c'est le défaut idiomatique du langage, on y reviendra en détail Semaine 9.

RegisterUser est le miroir Go de registerUser : la logique métier, découplée, qui ne connaît pas net/http.

package main

import (
    "database/sql"
    "errors"
    "fmt"
    "log"
    "strings"

    "golang.org/x/crypto/bcrypt"
)

// Erreurs métier — l'équivalent Go de ValidationError / ConflictError.
// Elles ne mentionnent aucun code HTTP : la logique ne sait pas que HTTP existe.
var (
    ErrValidation = errors.New("données invalides")
    ErrConflict   = errors.New("cet email est déjà utilisé")
)

// RegisterInput décrit, explicitement, la forme des données attendues.
type RegisterInput struct {
    Email    string
    Password string
}

// RegisteredUser décrit ce que la fonction renvoie.
type RegisteredUser struct {
    ID    string
    Email string
}

// RegisterUser porte la logique métier. Elle ne connaît ni *http.Request ni
// http.ResponseWriter : on pourrait l'appeler depuis un script, un test, un job.
func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error) {
    if !strings.Contains(in.Email, "@") {
        return RegisteredUser{}, fmt.Errorf("%w: email invalide", ErrValidation)
    }
    if len(in.Password) < 8 {
        return RegisteredUser{}, fmt.Errorf("%w: mot de passe trop court (8 caractères min)", ErrValidation)
    }

    var exists bool
    if err := db.QueryRow(
        "SELECT EXISTS(SELECT 1 FROM users WHERE email = $1)", in.Email,
    ).Scan(&exists); err != nil {
        return RegisteredUser{}, err
    }
    if exists {
        return RegisteredUser{}, ErrConflict
    }

    hash, err := bcrypt.GenerateFromPassword([]byte(in.Password), 12)
    if err != nil {
        return RegisteredUser{}, err
    }

    var id string
    if err := db.QueryRow(
        "INSERT INTO users (email, password_hash) VALUES ($1, $2) RETURNING id",
        in.Email, string(hash),
    ).Scan(&id); err != nil {
        return RegisteredUser{}, err
    }

    if err := sendWelcomeEmail(in.Email); err != nil {
        // L'email ne doit pas faire échouer l'inscription.
        log.Printf("envoi email échoué: %v", err)
    }

    return RegisteredUser{ID: id, Email: in.Email}, nil
}

Si tu n'as jamais lu de Go, quatre repères suffisent pour ne pas te perdre dans ce fichier :

Une fonction peut renvoyer plusieurs valeurs. Regarde la signature : func RegisterUser(db *sql.DB, in RegisterInput) (RegisteredUser, error). Elle rend deux choses d'un coup — le résultat et une erreur. C'est la convention Go : on renvoie souvent (résultat, erreur), et l'appelant vérifie l'erreur juste après. Rien de plus à comprendre ici, on y revient en détail Semaine 4.
nil, c'est l'absence de valeur. L'équivalent mental du null que tu connais. Un db à nil, c'est « pas de connexion ».
:= déclare et assigne en même temps (hash, err := ...), là où var déclare seul (var id string). Deux façons d'introduire une variable, selon que tu as déjà une valeur à mettre dedans ou non.
La majuscule initiale décide de la visibilité. RegisterUser commence par une majuscule : elle est exportée, visible depuis l'extérieur du package. sendWelcomeEmail, minuscule, reste privée au package. Le langage lit la casse comme un mot-clé de portée.

Avec ces quatre repères, le reste se lit comme du pseudo-code.

Le handler, ensuite — mince, qui ne fait que relayer HTTP vers la logique métier, exactement comme côté Express.

package main

import (
    "database/sql"
    "encoding/json"
    "errors"
    "net/http"
)

// registerHandler est mince : décoder, appeler RegisterUser, traduire en HTTP.
// C'est un traducteur HTTP↔métier, pas un endroit où vit la logique.
func registerHandler(db *sql.DB) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        var in RegisterInput
        if err := json.NewDecoder(r.Body).Decode(&in); err != nil {
            http.Error(w, "corps de requête invalide", http.StatusBadRequest)
            return
        }

        user, err := RegisterUser(db, in)
        switch {
        case err == nil:
            w.Header().Set("Content-Type", "application/json")
            w.WriteHeader(http.StatusCreated)
            json.NewEncoder(w).Encode(user)
        case errors.Is(err, ErrValidation):
            http.Error(w, err.Error(), http.StatusBadRequest)
        case errors.Is(err, ErrConflict):
            http.Error(w, err.Error(), http.StatusConflict)
        default:
            http.Error(w, "erreur serveur", http.StatusInternalServerError)
        }
    }
}

Et le câblage : un http.ServeMux de la bibliothèque standard, mux.HandleFunc("POST /register", ...). Pas de routeur tiers, pas de framework — juste la stdlib.

package main

import (
    "database/sql"
    "log"
    "net/http"

    _ "github.com/jackc/pgx/v5/stdlib"
)

func main() {
    db, err := sql.Open("pgx", "postgres://user:pass@localhost:5432/register")
    if err != nil {
        log.Fatal(err)
    }
    defer db.Close()

    mux := http.NewServeMux()
    mux.HandleFunc("POST /register", registerHandler(db))

    log.Println("écoute sur :8080")
    log.Fatal(http.ListenAndServe(":8080", mux))
}

Un détail au passage : sendWelcomeEmail est un stub ici, comme l'était mailer.js en Semaine 1 — pas la peine de s'y attarder.

3. Ce qui saute aux yeux

Maintenant qu'on a les deux versions côte à côte, quelques contrastes ressortent tout de suite. Pas besoin de creuser, ils sont en surface.

D'abord, les types. En Go, RegisterInput et RegisteredUser sont déclarés, noir sur blanc, en haut du fichier. La forme des données attendues n'est pas une convention tacite ni un commentaire — c'est écrit, et le compilateur la fait respecter. Côté Express, req.body est un objet dynamique : sa forme existe dans ta tête, dans un commentaire peut-être, mais nulle part le langage ne la vérifie pour toi. Voilà ce que j'aime là-dedans : je n'ai pas besoin de deviner ce qu'attend RegisterUser, la signature me le dit.

Ensuite, les erreurs : if err != nil partout, une erreur qui se renvoie au lieu de se lancer. Ça me plaît de voir chaque échec possible écrit là, dans le flux — mais c'est un gros morceau, on y consacrera la Semaine 4 en entier.

Autre chose qui manque : un framework. Pas d'Express, pas d'équivalent. net/http vient de la bibliothèque standard, et le routing POST /register que tu as vu dans main.go est natif depuis les dernières versions de Go — zéro dépendance HTTP à installer. Ça change la nature du projet : le routeur n'est l'affaire de personne d'autre que la stdlib. Ça a un revers que j'apprécie : pas de version de framework à traquer, pas de breaking change à anticiper à chaque mise à jour.

Dernier point, le SQL direct avec database/sql : les requêtes sont écrites en toutes lettres dans RegisterUser, pas cachées derrière un ORM. J'avoue aimer voir exactement ce qui part vers la base, sans couche à deviner — mais c'est un autre gros sujet, Semaine 9 : SQL sans se tirer une balle dans le pied.

4. La preuve que ça tourne

Tu te souviens du test de la Semaine 1 : peux-tu tester cette règle sans lancer un serveur HTTP ? Côté Express, la réponse avait fini par être oui, une fois la logique sortie du handler. Voyons ce que ça donne côté Go.

package main

import (
    "errors"
    "testing"
)

// La validation lève avant tout accès à la base : pas besoin de DB ni de serveur.
func TestRegisterUser_RefuseMotDePasseTropCourt(t *testing.T) {
    _, err := RegisterUser(nil, RegisterInput{Email: "ada@example.com", Password: "123"})
    if !errors.Is(err, ErrValidation) {
        t.Fatalf("attendu ErrValidation, obtenu: %v", err)
    }
}

Regarde bien ce qui ne se passe pas. go test, et c'est tout : aucun serveur qui démarre, aucune base de données à monter. Le premier argument passé à RegisterUser est carrément nil — pas de connexion, pas de mock, rien. Et ça fonctionne, parce que la validation de l'email et du mot de passe lève avant même que le code touche db. La règle métier est vérifiée en quelques millisecondes, et elle ne peut échouer que pour une seule raison : elle-même.

C'est la même démonstration qu'en Semaine 1, avec node:test sur registerUser. Changement de langage, même geste : découpler la logique du framework, et le test devient trivial à écrire.

5. Pour la suite

Un fil est resté volontairement tendu dans cet article : if err != nil, partout, à chaque appel qui peut échouer. Plaisir ou corvée ? C'est tout le sujet du prochain plongeon,

Si je devais résumer la sensation de cette comparaison en une phrase : côté Go, tout est écrit, rien n'est caché. Les types, les erreurs, les requêtes SQL, le routing — tout est là, sous tes yeux, dans le fichier. Au début, ça déroute un peu, il y a plus de lignes à lire. Après un moment, je trouve ça reposant : je n'ai jamais à me demander ce qui se passe derrière un décorateur ou un ORM, la réponse est toujours dans le fichier ouvert devant moi.

La série continue.

Pourquoi tes routes Express deviennent illisibles (et le seul geste qui les sauve)

Rodolphe D. — Fri, 17 Jul 2026 10:20:47 +0000

Je t'avais promis cet article il y a un moment.

Dans un article précédent, je racontais un projet Node que je détestais rouvrir. À la fin, j'avais annoncé la suite : pourquoi les routes Express finissent toujours par devenir illisibles. Et puis plus rien. Silence radio pendant des semaines.

Pas d'excuse compliquée. J'ai laissé traîner, comme on laisse traîner un refactor qu'on sait nécessaire mais jamais urgent. Sauf que le sujet n'a pas arrêté de me trotter dans la tête. Alors le voilà, enfin.

Promesse simple : à la fin de cet article, tu sauras pourquoi ton fichier de routes se transforme en cauchemar. Et tu repartiras avec un geste concret pour arrêter l'hémorragie, pas juste un constat déprimant.

1. Ce fichier que tu n'oses plus ouvrir

Tu vois de quel fichier je parle.

Celui que tu as écrit il y a six mois, un vendredi après-midi, pour livrer la fonctionnalité à temps. À l'époque il faisait vingt lignes. Aujourd'hui il en fait deux cents, et personne ne sait vraiment comment.

Chaque nouvelle règle métier s'est ajoutée au même endroit. Une vérification ici. Un appel à la base de données là. Un if de plus, imbriqué dans un if précédent. Puis un email à envoyer, parce que le produit l'a demandé un mardi et qu'il fallait livrer le mercredi.

Maintenant, quand il faut y toucher, tu hésites. Tu relis trois fois avant de changer une ligne. Tu te demandes ce qui va casser ailleurs, dans une route que tu ne regardes jamais.

Alors tu copies-colles la logique dans un nouveau fichier plutôt que de réutiliser celle qui existe déjà. Tu te dis que tu nettoieras plus tard. Le "plus tard" n'arrive jamais.

Si cette scène te parle, tu n'es pas seul. Et ce n'est pas parce que tu écris du mauvais code.

2. Le vrai coupable (spoiler : ce n'est pas Express)

La réaction naturelle, c'est d'accuser Express. Ou la taille du fichier. "Je devrais juste le découper en plus petits morceaux."

Ça ne suffit pas. Découper un mauvais fichier en trois mauvais fichiers ne règle rien : ça déplace juste le problème, avec un import en plus.

Le vrai coupable, c'est ailleurs. C'est que ta logique métier — les règles qui font que ton produit est ton produit — est collée au framework. Elle vit à l'intérieur du handler, mélangée à req et res du début à la fin.

Résultat : impossible de séparer "ce que fait mon application" de "comment Express reçoit une requête HTTP".

Voici le test qui révèle le problème en une seconde. Prends une règle métier de ta route — "le mot de passe doit faire au moins 8 caractères", par exemple. Pose-toi cette question :

Peux-tu tester cette règle sans lancer un serveur HTTP ?

Si la réponse est non — s'il faut monter un serveur, simuler une requête, lire une réponse JSON juste pour vérifier une règle de validation — alors voilà le problème. Ta logique et ton framework sont soudés ensemble. Et tout ce qui est soudé finit par devenir impossible à faire évoluer sans tout casser.

3. Le code, tel qu'il est aujourd'hui

Regarde cette route d'inscription. Validation, hash du mot de passe, écriture en base, envoi d'un email : tout est là, dans le même bloc, req et res mêlés à chaque étape.

const express = require('express')
const bcrypt = require('bcrypt')
const { PrismaClient } = require('@prisma/client')
const { sendWelcomeEmail } = require('./mailer')

const app = express()
app.use(express.json())
const prisma = new PrismaClient()

app.post('/register', async (req, res) => {
  const { email, password } = req.body

  if (!email || !email.includes('@')) {
    return res.status(400).json({ error: 'Email invalide' })
  }
  if (!password || password.length < 8) {
    return res.status(400).json({ error: 'Mot de passe trop court (8 caractères min)' })
  }

  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    return res.status(409).json({ error: 'Cet email est déjà utilisé' })
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })

  try {
    await sendWelcomeEmail(user.email)
  } catch (err) {
    console.error('Envoi email échoué', err)
  }

  return res.status(201).json({ id: user.id, email: user.email })
})

module.exports = app

Rien de honteux là-dedans. C'est même du code qui marche, qui a probablement tourné en prod sans souci depuis six mois. Mais essaie d'appliquer le test de la section précédente à la règle "le mot de passe doit faire au moins 8 caractères". Pour la tester, il faut faire tourner tout ce fichier — Express, Prisma, le mailer compris.

4. Le geste : sortir la logique du handler

Voilà le seul geste dont tu as besoin. Pas un pattern à trois lettres, pas une nouvelle couche d'abstraction. Une fonction.

Tu prends toute la logique métier — validation, vérification en base, hash, création, email — et tu la sors dans sa propre fonction, registerUser(data). Cette fonction ne connaît ni req ni res. Elle reçoit des données simples (email, password), elle renvoie un résultat simple, ou elle lève une erreur.

Attention à un malentendu classique : registerUser n'est pas devenue une fonction magiquement isolée du monde. Elle continue de taper la base de données, de hasher un mot de passe, d'envoyer un email. Ses effets de bord n'ont pas disparu, ils sont toujours là. Ce qui a changé, c'est autre chose : elle ne dépend plus d'Express. Tu pourrais l'appeler depuis un script, un test, une tâche planifiée, une autre route — elle s'en fiche. C'est ça, le gain : l'indépendance vis-à-vis du framework, pas une histoire de pureté.

const bcrypt = require('bcrypt')
const { PrismaClient } = require('@prisma/client')
const { sendWelcomeEmail } = require('./mailer')

const prisma = new PrismaClient()

class ValidationError extends Error {}
class ConflictError extends Error {}

async function registerUser({ email, password }) {
  if (!email || !email.includes('@')) {
    throw new ValidationError('Email invalide')
  }
  if (!password || password.length < 8) {
    throw new ValidationError('Mot de passe trop court (8 caractères min)')
  }

  const existing = await prisma.user.findUnique({ where: { email } })
  if (existing) {
    throw new ConflictError('Cet email est déjà utilisé')
  }

  const passwordHash = await bcrypt.hash(password, 12)
  const user = await prisma.user.create({ data: { email, passwordHash } })

  try {
    await sendWelcomeEmail(user.email)
  } catch (err) {
    console.error('Envoi email échoué', err)
  }

  return { id: user.id, email: user.email }
}

module.exports = { registerUser, ValidationError, ConflictError }

Remarque les erreurs typées, ValidationError et ConflictError. C'est ce qui permet à la logique métier de dire "ceci est invalide" sans jamais mentionner un code HTTP. Elle ne sait même pas que HTTP existe.

Et le handler, dans tout ça ? Il devient minuscule. Son seul travail : traduire une requête HTTP en appel à registerUser, puis traduire le résultat (ou l'erreur) en réponse HTTP. Rien de plus. C'est un traducteur HTTP↔métier, pas un endroit où vit la logique.

const express = require('express')
const { registerUser, ValidationError, ConflictError } = require('./registerUser')

const app = express()
app.use(express.json())

app.post('/register', async (req, res, next) => {
  try {
    const user = await registerUser(req.body)
    return res.status(201).json(user)
  } catch (err) {
    if (err instanceof ValidationError) return res.status(400).json({ error: err.message })
    if (err instanceof ConflictError) return res.status(409).json({ error: err.message })
    return next(err)
  }
})

module.exports = app

Une poignée de lignes. Tu le lis en entier sans effort, et tu sais exactement ce qu'il fait : il reçoit, il délègue, il répond.

5. Pourquoi c'est mieux

Ce n'est pas juste plus joli à regarder. Trois choses changent concrètement.

D'abord, tu peux tester la règle métier sans lancer un serveur. Plus besoin de monter Express, de simuler une requête HTTP, de parser une réponse JSON pour vérifier qu'un mot de passe trop court est rejeté. Tu appelles registerUser directement, avec un objet, et tu regardes ce qu'elle renvoie ou ce qu'elle lève.

const { test } = require('node:test')
const assert = require('node:assert')
const { registerUser, ValidationError } = require('./registerUser')

test('refuse un mot de passe trop court — sans lancer Express ni DB', async () => {
  await assert.rejects(
    () => registerUser({ email: 'ada@example.com', password: '123' }),
    ValidationError,
  )
})

Regarde bien ce test. Aucun app.listen, aucun supertest, aucun port à ouvrir. Je teste la règle métier sans lancer de serveur. Le test s'exécute en quelques millisecondes, et il ne peut échouer que pour une seule raison : la règle elle-même est cassée. Pas parce que le port 3000 était pris, pas parce qu'une requête a mis trop de temps à répondre.

Ensuite, cette fonction devient réutilisable ailleurs que dans une route HTTP. Un script d'import en masse depuis un CSV, une tâche planifiée qui crée des comptes de test, une deuxième route qui inscrit via une invitation — tout ça peut appeler registerUser directement, sans repasser par Express, sans fabriquer une fausse requête HTTP pour appeler du code qui n'a jamais eu besoin de HTTP.

Enfin — et c'est peut-être le bénéfice le plus sous-estimé — ton handler redevient lisible d'un coup d'œil. Une poignée de lignes. Tu sais ce qu'il fait sans avoir à dérouler deux cents lignes de if imbriqués. Le jour où quelqu'un d'autre (ou toi, dans six mois) doit comprendre "que fait cette route", la réponse tient dans le temps de lire le fichier.

Je t'entends déjà venir avec l'objection : "pourquoi pas juste couper en middlewares plus petits ?" Un middleware pour la validation, un pour la vérification en base, un pour l'envoi d'email. Ça se défend, en apparence.

Sauf que ça ne règle rien. Chaque middleware continue de recevoir req et res. La logique métier reste mélangée au framework, juste répartie sur plusieurs fichiers au lieu d'un seul. Tu as déplacé le problème, tu ne l'as pas supprimé. Le test de la section 2 — "peux-tu tester cette règle sans lancer un serveur HTTP ?" — reste tout aussi négatif qu'avant.

6. La suite, et ce qu'il faut retenir

Une dernière remarque, pour ceux qui viennent d'un autre langage ou qui y passeront bientôt : en Node, ce geste reste une discipline à choisir toi-même, rien ne t'y oblige ; en Go, cette même séparation devient presque un réflexe, que la structure du langage encourage.

La série continue.

Si tu ne retiens qu'une phrase de cet article, que ce soit celle-là : la logique métier ne doit pas connaître req/res.

Le projet qui fonctionnait… mais que je détestais modifier

Rodolphe D. — Thu, 28 May 2026 09:03:22 +0000

Il y a un moment que tous les développeurs finissent par vivre.

Celui où ton projet fonctionne parfaitement.

Les routes répondent.

La base de données est connectée.

Les features font exactement ce que tu as prévu.

Et pourtant… tu n’as aucune envie d’y retourner.

“Ça marche” n’est pas une victoire

Je me souviens très bien de ce projet.

Une API Node.js avec Express, PostgreSQL derrière, un peu de Sequelize pour faire propre.

Rien de compliqué.

Au début, tout était fluide.

Tu codes, ça marche, tu avances.

Tu as cette sensation agréable de progression rapide.

Et puis un jour, tu reviens dessus.

Juste pour ajouter une petite fonctionnalité.

Et là… quelque chose change.

Tu ouvres le projet.

Tu regardes une route.

Puis une autre.

Et sans trop comprendre pourquoi, tu sens une forme de blocage.

Pas technique.

Mental.

Le vrai problème n’était pas le code

Sur le moment, je me disais que ça allait.

“C’est normal, c’est un petit projet.”

Mais en réalité, le problème était déjà là.

Mes routes faisaient tout.

Un peu de logique métier ici.

Un appel base de données là.

Une gestion d’erreur bricolée dans un coin.

Rien n’était vraiment structuré.

Mais comme tout fonctionnait… je ne voyais pas le problème.

Jusqu’au jour où j’ai voulu modifier un truc simple

Je voulais juste ajouter une fonctionnalité.

Rien de fou.

Un champ en plus, une petite logique.

Et pourtant, j’ai commencé à hésiter.

“Si je change ça… qu’est-ce que je vais casser ?”

Et c’est là que j’ai compris un truc assez dérangeant.

Mon code fonctionnait… mais je ne lui faisais plus confiance.

Le moment un peu bizarre où tu réalises que tu subis ton propre code

C’est difficile à expliquer.

Tu n’as pas d’erreur.

Pas de bug bloquant.

Mais tu avances avec prudence.

Comme si chaque modification pouvait déclencher une réaction en chaîne.

Et ça, pour un développeur, c’est un signal très clair.

Quelque chose ne va pas dans la structure.

Le premier déclic : arrêter de tout mettre au même endroit

Je n’ai pas tout refactorisé d’un coup.

Personne ne fait ça proprement.

J’ai commencé petit.

Une seule chose : arrêter de mettre toute la logique dans les routes.

Avant, j’avais un truc comme ça :

router.post('/events', async (req, res) => {
  const event = await Event.create(req.body);
  res.json(event);
});

Et dès que ça grossit un peu, ça devient vite ingérable.
Validation, règles métier, permissions… tout finit empilé.

Le changement n’était pas spectaculaire

J’ai juste déplacé la logique.

Un service.

Un contrôleur.

Rien de magique.

// controller
const createEvent = async (req, res) => {
  const event = await eventService.createEvent(req.body);
  res.json(event);
};

// service
const createEvent = async (data) => {
  return Event.create(data);
};

Et honnêtement ?

À ce moment-là, je n’ai pas eu de révélation.

Pas de “wow”.

Juste un truc très simple :

“ok… c’est plus clair.”

Mais le vrai changement est venu après

Le vrai test, ce n’est pas quand tu refactorises.

C’est deux semaines après.

Quand tu reviens dans ton projet.

Et que tu comprends ce que tu as fait sans relire 15 fichiers.

Là, j’ai senti la différence.

Moins de stress.

Moins d’hésitation.

Moins de “je touche ou pas ?”

Ce que j’ai compris à ce moment-là

Ce n’est pas la complexité du code qui pose problème.

C’est le chaos invisible.

Quand tout est mélangé, ton cerveau doit tout retenir en même temps :

logique métier
requêtes SQL
gestion HTTP
erreurs
règles implicites

Et ça fatigue.

Sans que tu t’en rendes compte.

Et pourtant… ce projet fonctionnait parfaitement

C’est ça le piège.

Le code peut être “bon” techniquement.

Mais mauvais à vivre.

Et à un moment, en tant que développeur, tu fais la différence entre :

un projet qui marche
et un projet avec lequel tu peux travailler sereinement

La suite a changé ma façon de coder

Ce petit refactor m’a ouvert une porte.

Après ça, je ne regardais plus mes projets de la même façon.

Je ne cherchais plus juste à “faire fonctionner”.

Je commençais à me demander :

“est-ce que je vais comprendre ça dans 2 semaines ?”
“est-ce que quelqu’un d’autre peut lire ça facilement ?”
“est-ce que je suis en train de créer du chaos sans m’en rendre compte ?”

Et c’est là que tout commence vraiment

Pas quand tu sais coder une API.

Pas quand tu sais utiliser un ORM.

Mais quand tu commences à ressentir ton propre code.

Quand tu sais, instinctivement, qu’un projet va devenir lourd… avant même qu’il le devienne.

👉 Dans le prochain article, on parlera d’un truc encore plus vicieux :

les routes Express qui deviennent illisibles sans qu’on s’en rende compte.

Comment structurer une API simple avec Go pour plus de clarté

Rodolphe D. — Tue, 26 May 2026 08:15:00 +0000

Quand on apprend à construire des backends, on a souvent le même réflexe : ajouter des couches.

Frameworks, abstractions, middlewares, services…

Et petit à petit, on finit parfois par perdre de vue quelque chose de très simple :

ce que fait réellement une API.

🧠 Revenir à l’essentiel

Go m’a forcé à revenir à cette base.

Pas parce qu’il est “magique” ou “révolutionnaire”.

Mais parce qu’il est explicite.

Tout est plus direct :

une requête arrive
elle est traitée par une fonction
une réponse est renvoyée

Et c’est tout.

🔁 Le cycle réel d’une requête HTTP

Si on simplifie au maximum, une API fonctionne toujours de la même manière :

Une requête HTTP arrive sur le serveur
Elle est dirigée vers un handler
Le handler exécute une logique métier
Une réponse est renvoyée au format JSON

Ce schéma ne change jamais.

Ce qui change, c’est la manière dont on le rend complexe.

🧩 Le rôle du handler en Go

En Go, un handler est juste une fonction.

Pas une couche abstraite.

Pas un système caché.

Juste une fonction qui :

reçoit une requête
traite une logique
retourne une réponse

Ce découpage impose une discipline naturelle :

peu de magie
peu d’indirection
beaucoup de lisibilité

⚙️ Ce que ça change dans ta manière de coder

Quand tu commences à structurer tes backends en Go, tu observes un changement progressif :

tu penses en flux (request → process → response)
tu réduis les couches inutiles
tu rends les responsabilités plus claires

Et surtout, tu réalises quelque chose :

la complexité ne vient pas du langage, mais de la manière dont on structure les choses.

📌 Ce qu’il faut retenir

Go ne rend pas le backend “plus simple”.

Il le rend plus lisible.

Et cette lisibilité change tout :

tu comprends ce que tu fais
tu maintiens plus facilement
tu évites les sur-architectures inutiles

🧭 Conclusion

Si tu viens d’un écosystème comme Node.js, PHP ou Ruby, cette approche peut sembler un peu plus stricte au début.

Mais cette “rigidité” est souvent ce qui manque pour retrouver de la clarté.

Go n’ajoute pas de complexité.

Il en enlève.

Et parfois, c’est exactement ce dont on a besoin pour construire des systèmes plus sains.

Common backend mistakes I keep seeing from students

Rodolphe D. — Thu, 21 May 2026 17:30:57 +0000

TL;DR

Most beginner backend issues come down to 5 things:

messy APIs that don’t scale
weak SQL habits
security added too late
no code structure
bad error handling

Fix these early and you’ll already be ahead of most juniors.

When you start backend dev, the goal is simple: make it work.

And honestly, that’s fine at the beginning.

But after reviewing a lot of student projects, you start noticing the same patterns over and over again.

Here are the most common ones.

🧵 APIs that “work”, but don’t scale

Most beginners build APIs that return everything, everywhere, all the time.

You’ll see things like:

endpoints that dump full database objects
no pagination at all
multiple DB calls for simple requests

It’s not a problem… until traffic grows or data increases.

Then everything slows down, and nobody understands why.

🧵 SQL used without thinking

SQL is usually learned fast, then ignored in practice.

Common patterns:

SELECT * everywhere
no indexes
joins stacked without thinking about cost
“it works on my machine” queries

It’s fine for small projects, but it doesn’t scale.

🧵 Security added at the end (if at all)

A lot of projects treat security like a final step.

That leads to:

plain text passwords
no validation on inputs
weak or incorrect JWT handling
no rate limiting

Security should be part of the design, not a patch.

🧵 No real structure in the code

Everything ends up inside controllers.

At first it feels fast.

Then:

logic gets duplicated
nothing is reusable
testing becomes painful
adding features starts breaking things

That’s usually the moment people discover “clean architecture” exists.

🧵 Error handling that doesn’t help

This one is very common.

everything returns 500
no logs
useless error messages
no distinction between client and server errors

When something breaks in production, debugging becomes guesswork.

💬 Final thoughts

None of this is dramatic. Everyone goes through it.

The real issue is staying in that phase too long.

If you fix even half of these early, you’ll already be ahead of most junior backend devs.

🤝 Let’s build better backend habits together

I’m trying to collect real-world mistakes and patterns from devs at all levels.

If you’ve seen other common backend mistakes (or made some yourself 😅), drop them in the comments.

Let’s build a list that actually helps juniors improve.

Once upon a time there was web development

Rodolphe D. — Fri, 10 Jan 2020 13:25:42 +0000

Hello everyone, it's okay, I finally decided to write a post...
I'm a bit anxious because usually I still think I have nothing interesting to say. But I'm forced to admit that some of the people I work with on a daily basis are happy to hear my adventures.( So i come from France excuse my English)
So I'm going to talk subjectively here about certain subjects.
To begin with, we'll talk about learning.
Learning something new can be exciting, but it can also be difficult. We expected that we would spend some time each day or each week learning something about a specific topic. We all aspire to some mastery of the subject we choose. If you're like me, you'll feel frustrated when your study time doesn't allow you to learn as much as the day before, but that's natural and it's part of the process. Learning is not linear.

Learning by repetition

Some things we learn simply by doing them over and over again. I'd be willing to bet you can add 2 and 3 in your head without even thinking about it. But why is that? It's because you've done it so much in your life that you don't even have to think about it. That's kind of the way you have to code. If you go on long enough, through repetition, you'll begin to be able to do things easily that you've had to make a concerted effort to do before. If you don't, you probably won't be able to pinpoint the exact time when it made sense to you. One way or another, over the course of rehearsals, it does.

Cliff Climbing

On the other hand, some ideas are more abstract. There will probably be a time in your learning when you notice that things will become much more difficult. These situations tend to occur when concepts come into play. You've learned the basics, but now you have to put them together to design a solution to a problem. In my experience, it's a bit like standing at the bottom of a cliff. This is where I felt the most frustration in my learning process.
But there is good news. It can be overcome, and you can climb that cliff! I have personally experienced situations where I simply couldn't grasp a concept. I may have heard twenty explanations and seen twenty examples on the same subject. For some unknown reason, perhaps it is the twenty-first explanation and the twenty-first example that enlightens me. In most cases, there is nothing very different between this example and those I have already seen. I have sat in my office and said, "Oh, when it finally hits me and the concept crystallizes like never before. The good thing about those moments is that once you understand the idea, it's hard to forget it.
When you understand a concept, your learning is not so much a curve as a vertical jump.

The thing we should unlearn

Humans are not born believing that they can never get smarter. This is something we learn in our lifetime, and it is something we should all unlearn. If you've ever seen a child tackle a puzzle, you'll have an idea of what I mean. A child will get bored with an easy problem, but will deal with a difficult one. On the other hand, an adult is likely to raise his or her hands in frustration and walk away from the problem. The instinct we are born with is that we can get the solution with enough time, effort and resources.
Alfred Binet, the inventor of the first practical IQ test, believed that intelligence was changeable. In his book, we can find this quote: "Some modern philosophers assert that the intelligence of an individual is a fixed quantity, a quantity that cannot be increased. We must protest and react against this brutal pessimism... With practice, training, and above all method, we can increase our attention, memory, judgment and literally become more intelligent than before."
You may be working on a piece of code or an idea that you haven't fully grasped yet. You might be thinking to yourself, "I'm not smart enough to do this". I always think that when I'm stuck. I take comfort in knowing that my inability to solve the problem is probably not permanent. It's something that can change with time, effort and resources.

Memorizing is mostly wasteful

People have repeatedly asked me what I think are the most important things to remember when learning to program. My answer: practically nothing. Anything that might be important enough to be memorized will naturally occur by repetition, as mentioned above. If you don't use a particular thing in your programs often enough to learn it by repetition, it's not worth the effort to memorize it either.
Coming back to my mathematical example, you have probably memorized 2 + 3. I'm assuming you didn't memorize 29,083,983 + 3,497,267. And why is that? It's because you get the idea behind the addition. You know how addition works as a concept, so you can use it on any number you are given. This is an example of wasted memorization.
Programmers, in general, do not rely on memorizing every construction, every parameter, every object, method and class. Instead, we use our resources combined with the concepts we have learned to produce the result. That's why documentation is so valuable, and you'll hear programmers talk about it a lot. I bet very few people memorize all the recipes in a cookbook. If we want to cook something else, we read the cookbook. It's the same idea. If a programmer had to memorize everything in one language, we wouldn't have programmers.

Keep moving forward

Don't stop learning. Even if you've been stuck on a problem or project for weeks, don't stop learning. You may need to go back and review some of your basics. You may need another source to change your pace. Try reading an explanation on Medium or search for something on YouTube. Maybe even do some generic Googling. You might even try to learn something else about the language/platform/IDE and get back to where you were stuck. Keep pushing against that wall. Eventually, you'll have a breakthrough, and it will probably be something you won't easily forget. It's worth the time and effort, even if you don't get immediate results.
Programming can be hard to learn, but it can also be incredibly fun and more creative than non-programmers understand. If you are interested and dedicated enough, you will see progress. The next step may be your breaking point, but you'll never know if you don't take that step.

DEV Community: Rodolphe D.

Handler / service / repository expliqué à un dev Express

Pourquoi tes routes Express deviennent illisibles (et le seul geste qui les sauve)

1. Le problème après le premier geste

2. Les trois rôles, en français de café

3. Le même register, découpé

Repository — la base, rien d'autre

Service — les règles du produit

Handler — le traducteur HTTP

4. Ce que ça change concrètement

5. Et en Go, c'est la même carte

6. Quand ne pas faire ça

7. Ce qu'il faut retenir

Ce que Go t'oblige à faire que Node te laissait éviter : les erreurs explicites

De Node à Go : le même POST /register, côte à côte

1. Ce que Node te laisse faire (et que tu fais)

2. Ce que Go refuse

3. Le même register, vu par les erreurs

4. errors.Is, wrapping, et pourquoi fmt.Errorf("%w")

5. La traduction mentale Node → Go

6. Et le bruit dans le code ?

7. Mini-exercice : le piège du _

8. Ce qu'il faut retenir

« J'ai fini le tuto Node, et là je suis bloqué » — le mur dont personne ne parle

1. Le piège n'est pas le tuto, c'est ce qu'il te cache

2. Pourquoi « un tuto de plus » ne réglera rien

3. La sortie : le plus petit projet qui décide à ta place de rien

4. La règle qui garde le muscle en vie : jamais copier sans décider

5. Ce qu'il faut retenir

From Node to Go - the same POST /register, side by side

1. The Express version, for reference

2. The same endpoint, in Go

3. What jumps out

4. The proof it runs

5. What's next

De Node à Go : le même POST /register, côte à côte

1. La version Express, pour mémoire

2. Le même endpoint, en Go

3. Ce qui saute aux yeux

4. La preuve que ça tourne

5. Pour la suite

Pourquoi tes routes Express deviennent illisibles (et le seul geste qui les sauve)

1. Ce fichier que tu n'oses plus ouvrir

2. Le vrai coupable (spoiler : ce n'est pas Express)

3. Le code, tel qu'il est aujourd'hui

4. Le geste : sortir la logique du handler

5. Pourquoi c'est mieux

6. La suite, et ce qu'il faut retenir

Le projet qui fonctionnait… mais que je détestais modifier

“Ça marche” n’est pas une victoire

Le vrai problème n’était pas le code

Jusqu’au jour où j’ai voulu modifier un truc simple

Le moment un peu bizarre où tu réalises que tu subis ton propre code

Le premier déclic : arrêter de tout mettre au même endroit

Le changement n’était pas spectaculaire

Mais le vrai changement est venu après

Ce que j’ai compris à ce moment-là

Et pourtant… ce projet fonctionnait parfaitement

La suite a changé ma façon de coder

Et c’est là que tout commence vraiment

Comment structurer une API simple avec Go pour plus de clarté

🧠 Revenir à l’essentiel

🔁 Le cycle réel d’une requête HTTP

🧩 Le rôle du handler en Go

⚙️ Ce que ça change dans ta manière de coder

📌 Ce qu’il faut retenir

🧭 Conclusion

Common backend mistakes I keep seeing from students

TL;DR

🧵 APIs that “work”, but don’t scale

🧵 SQL used without thinking

🧵 Security added at the end (if at all)

🧵 No real structure in the code

🧵 Error handling that doesn’t help

💬 Final thoughts

🤝 Let’s build better backend habits together

Once upon a time there was web development

Learning by repetition

Cliff Climbing

The thing we should unlearn

4. `errors.Is`, wrapping, et pourquoi `fmt.Errorf("%w")`

7. Mini-exercice : le piège du `_`