Les logs sont la première chose qu'on vérifie quand un déploiement échoue. Si votre PaaS vous oblige à faire un SSH sur un serveur et lancer docker logs -f, vous avez déjà perdu dix secondes de contexte et la patience d'un développeur.
Depuis la Phase 12, sh0 dispose du streaming de logs en temps réel dans le navigateur. Ouvrez l'onglet Logs d'une application, et la sortie apparaît au fur et à mesure -- pas de rafraîchissement, pas de polling, pas d'attente.
Couche 1 : le endpoint WebSocket de logs
Nous avons choisi une approche de polling avec suivi des timestamps plutôt qu'un flux Docker persistant. Toutes les deux secondes, le handler appelle l'API de logs Docker avec since=<dernier_timestamp>, récupère les nouvelles lignes et les envoie via WebSocket. Si pas de nouvelles lignes, rien n'est envoyé.
Trois raisons pour le polling plutôt qu'un flux persistant : gestion des ressources (pas de connexion maintenue ouverte par utilisateur), simplicité de reconnexion, et déduplication par timestamp.
Couche 2 : authentification WebSocket
Les WebSockets des navigateurs ne supportent pas les headers HTTP personnalisés lors du handshake initial. Nous avons déplacé le jeton JWT vers le header Sec-WebSocket-Protocol -- un pattern bien connu utilisé par Hasura et Supabase.
Couche 3 : reconnexion automatique avec backoff exponentiel
La séquence de reconnexion : 1 s, 2 s, 4 s, 8 s, 16 s, 30 s, 30 s, 30 s... Le code de fermeture personnalisé 4001 distingue les échecs d'authentification des échecs réseau.
Couche 4 : le composant LogViewer
Le buffer de 1 000 lignes empêche la croissance mémoire. Le défilement automatique intelligent se désengage quand l'utilisateur fait défiler vers le haut pour lire les anciens logs, et se ré-engage quand il revient en bas (seuil de 50 pixels).
Prochain dans la série : i18n dès le premier jour : 5 langues sur 105 sessions.