Les server sent events sont l'option la moins chère quand le trafic ne va que du serveur vers le client : du HTTP simple, une reconnexion automatique, et ils passent la plupart des proxys. Les WebSockets justifient leur coût d'exploitation quand il vous faut de la messagerie bidirectionnelle ou à haute fréquence, comme un chat ou de l'édition collaborative. Le polling convient quand les mises à jour sont rares et que quelques secondes de retard sont acceptables, et il survit à tous les réseaux et load balancers qui existent.
Pourquoi les recruteurs posent cette question
Le temps réel, c'est là que les développeurs dégainent d'abord l'option la plus complexe. Le recruteur veut vous voir accorder le transport au vrai motif de trafic et réfléchir à ce qui se passe à l'échelle : connexions collantes, mise à l'échelle horizontale, reconnexion, et messages ratés pendant qu'un client était hors ligne. Choisir le polling pour la bonne raison est un signal fort, parce que ça montre que vous pesez le coût d'exploitation au lieu de courir après la réponse impressionnante.
Comment structurer votre réponse
- Associez chaque option au sens et à la fréquence du trafic qui lui convient.
- Nommez le coût d'exploitation des connexions persistantes.
- Couvrez la reconnexion et les messages ratés.
- Recommandez-en une pour le scénario qu'on vous a donné.
Exemple de réponse
La première question, c'est de savoir si le client doit renvoyer quelque chose sur le même canal. Notifications, compteurs en direct, barre de progression d'un job, un fil d'actualité : tout ça est à sens unique, et les server sent events gèrent ça sur du HTTP ordinaire avec reconnexion intégrée et un en-tête last event id pour reprendre là où le client a décroché. Cette dernière partie est sous-estimée. Les WebSockets sont le bon choix pour un chat, la présence, ou tout ce qui est collaboratif où les clients poussent souvent et où la latence compte. Le coût est réel cela dit : les connexions ont un état, donc dépasser une seule instance veut dire une couche pub sub comme Redis pour diffuser les messages entre noeuds, plus des health checks, de la contre-pression et de l'authentification sur la poignée de main initiale. Et le polling n'est pas une réponse pour rire. Sur un tableau de bord d'administration que j'ai construit, les mises à jour comptaient peut-être une fois par minute, donc un poll au retour du focus sur la fenêtre avec un ETag faisait une quinzaine de lignes de code, ne coûtait rien à exploiter, et n'a jamais réveillé personne la nuit. Je préfère dépenser le budget de complexité là où les utilisateurs le ressentent vraiment.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Comment feriez-vous passer à l'échelle des connexions WebSocket sur plusieurs serveurs ?
- Comment livrez-vous les messages qu'un client a ratés pendant sa déconnexion ?
- Comment authentifiez-vous et autorisez-vous une connexion socket ?
Autres questions pour Développeur full stack
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions