Dart backend : benchmarks et problèmes de mémoire

# Dart côté serveur : pourquoi il a craqué sous charge de production

Un développeur SaaS a remplacé Node.js par Dart pour réduire la consommation mémoire. Attentes : 10 Mo au démarrage contre 80 Mo, compilation AOT et typage statique. Réalité : deux semaines de dev, un framework maison et des benchmarks montrant une perf pire. Leçon : toujours tester des benchmarks bruts sur charges de prod avant migration.

Le service d'auth (OAuth2, ORM Redis) était le terrain d'essai. Node.js montait à 500 Mo mais libérait la mémoire. Des centaines d'instances à 80 Mo au démarrage, voilà le vrai problème.

Écosystème : aucun outil backend en vue

Dart est fait pour Flutter. Pas d'équivalents à NestJS, peu de clients Redis au niveau d'ioredis. Shelf est un routeur basique, Serverpod vise les apps full-stack Flutter.

Obligé de construire un framework de zéro :

• DI arborescente comme Angular.
• Scoping des requêtes via Zone.
• CLI avec codegen pour AOT.

Porté ts-oauth2-server et ioredis (4 500 lignes Dart vs. 23 500 TS). L'IA s'en est chargée, mais au prix fort : flag expérimental --enable-experiment=enhanced-parts, part 'file.g.dart' partout, commits en sheets ou génération CI.

La réflexion a disparu en AOT. Type est un stub, pas d'appels statiques. DI sans mirrors nécessite CLI en JIT → mirrors → codegen. En TS/Java/C#, c'est trois lignes de réflexion.

Langage : syntaxe sympa, cauchemar pour la métaprogrammation

Syntaxe logique, erreurs à la compilation. Mais pas de for...in sur objets, pas de réflexion. Le codegen est un enfer : références .g.dart qui polluent les sources.

L'IA a porté ioredis mécaniquement. Résultat : +5 % RPS sur le meilleur client pub.dev. RIP écosystème backend — personne n'écrit du code serveur en Dart.

Benchmarks : latence et mémoire le tuent

Scénario : 3 endpoints, Postgres, Redis. HTTP brut, sans frameworks. 100m CPU, 500 VUS.

| Métrique | Dart AOT | Node.js | Go |

|---------|----------|---------|----|

| RSS démarrage | 3 Mo | 18 Mo | - |

| p95 latence | 9,5 s | 5 s | 2,9 s |

| RPS | 2x pire que Node | - | Meilleur global |

| RSS pic | 39-47 Mo | 37 Mo | - |

Dart :

• Ne rend pas la mémoire à l'OS (>5 % après pic).
• GC sous pression : pauses tunées pour 60 fps (Flutter), pas RSS pour K8s.
• Sous throttling, gonfle à 47 Mo ; Node se rétracte.

Flags GC (--dontneed_on_sweep, --use_compactor) n'ont rien changé. Par design : VM pour mobile. K8s voit 40 Mo/pod constant, HPA ne peut pas packer serré. Économies au démarrage bouffées par surprovisionnement.

Sur Cloud Run : Dart coûte plus cher que Node — plus lent + garde la mémoire.

Leçons clés :

• p95 latence 9,5 s vs. 5 s Node = pannes en prod.
• Mémoire non libérée : scaling surcoûté.
• Écosystème mort hors Flutter.
• Benchmarks dans le repo : manifests K8s, profils CPU, Dockerfiles.

Verdict : la niche de Dart, c'est Flutter seulement

Deux semaines perdues en framework, ports, tests. Dart brille pour du code simple, mais serveur = fiasco. Pas de réflexion, VM pas prête cloud, codegen infernal. Les promesses officielles "APIs scalables pour Cloud Run" tombent à plat.

Rejeté Go à cause de err != nil et context.Context. Node.js gagne : libère mémoire, meilleure latence.

— Editorial Team