Pourquoi Fastify v5 + SvelteKit 5 — nos choix de stack et retours après 6 mois

Retour d'expérience sur la stack Nodyx

Fastify v5 SvelteKit 5 PostgreSQL

Fastify v5

J'avais l'habitude d'Express mais Fastify a plusieurs avantages concrets :

• Schéma de validation JSON Schema natif → routes auto-documentées
• Performances supérieures sur les petits payloads (ce qu'on a en forum/chat)
• TypeScript first sans torsion

⚠️ La galère v5 : Socket.IO doit être attaché après server.listen(). Fastify v5 a changé le cycle de vie :

// ❌ Ne pas faire (Fastify v5)
await server.register(fastifySocketIO)

// ✅ Correct
await server.listen({ port: 3000 })
const io = new Server(server.server, { cors: { origin: FRONTEND_URL } })

SvelteKit 5 — les runes

Les runes ($state, $derived, $effect) ont transformé ma façon d'écrire les composants :

// Avant (Svelte 4) — stores verbeux
const voiceStore = writable({ active: false, peers: [] })
$: peers = $voiceStore.peers

// Après (Svelte 5) — réactivité fine-grained
const vs    = $derived($voiceStore)
const peers = $derived(vs.peers)
const level = $derived($inputLevel)

PostgreSQL + Redis

Technologie	Usage	Pourquoi pas autre chose
PostgreSQL 16	Persistance : forums, membres, assets	SQL direct avec pg — lisible, maîtrisable
Redis	Sessions JWT, présence en ligne	TTL natif pour les sessions — parfait
Pas d'ORM	—	Requêtes complexes (FTS, JSON, agrégats) → SQL direct

Le point sur Socket.IO post-listen dans Fastify v5 m'a sauvé il y a quelques semaines. Je cherchais depuis des heures pourquoi mes events n'arrivaient pas.

C'est un piège classique — la doc Fastify v5 le mentionne mais seulement dans une note de bas de page.

Les runes Svelte 5 c'est vraiment une autre dimension. J'ai réécrit VoicePanel avec et le code est deux fois plus court pour le même comportement.

La réactivité fine-grained évite aussi les re-renders inutiles — c'est sensible sur les composants qui écoutent des stores qui changent souvent (inputLevel, peerStatsStore...).

La contrainte "une instance = une communauté" c'est une décision forte mais cohérente avec la philosophie décentralisée.

Pas de compromis de performance pour le multi-tenant. Toutes les ressources de l'instance servent une seule communauté.