Discussion :

[barcelonais59]

Bonjour,

Je suis actuellement sur le développement d'un site en NodeJS. Les fonctionnalités de l'application impliquent que les requêtes venant du client provoquent de longs traitements côté serveur. Ces traitements produisent des résultats qui sont renvoyés au client.
Afin d'éviter que l'utilisateur se lasse de l'attente ou que le navigateur plante en indiquant qu'il n'a pas reçu de réponse, je pensais rendre une vue au client avant le début du traitement côté serveur. Des requêtes fetch seraient ensuite lancées au serveur toutes les deux secondes pour vérifier que le traitement est fini. Je poste ce message pour savoir ce que vous pensez de l'idée et si vous en avez d'autres pour la mettre en place (par exemple, où stocker le résultat côté serveur ? Dans une variable de session ?).

[Marco46]

Quelle est ta stack exacte et quelle est ton architecture ?

Je ne comprends ce que c'est qu'un "site en Node.js". Tu sous-entends que ton Node va générer le html renvoyé au client ? Vous n'avez pas un frontend (Vue, React, Angular, whatever) séparé ?

Qu'entends-tu par "longs traitements côté serveur" ? S'agit d'appels à une base de données ? Ou de calculs réalisés par ton appli node ?

[barcelonais59]

Bonsoir Marco46,

Oui c'est ça j'ai un serveur Node qui génère le code client.
Non il ne s'agit pas d'appels à une base de données mais de traitement NodeJS.

[Marco46]

Node.js est très efficace pour gérer un très grand nombre de requêtes qui entrainent de tous petits traitements.

C'est un mauvais choix dès lors qu'il y a beaucoup de traitements à effectuer côté serveur (calcul CPU). De plus, générer le front côté serveur, outre que cette architecture est obsolète, c'est aussi du temps de calcul CPU côté backend.

Du coup, compte tenu de ton architecture et de ce que tu dois faire, Node.js est probablement le pire choix que tu puisses faire.

Comme node n'a qu'un seul thread d'exécution (l'event loop), pendant qu'il va calculer un résultat ou un front pour un client donné il ne pourra rien faire du tout pour les autres.

Donc 2 solutions, changer l'architecture ou changer de techno. Pour info en terme d'ergo de nos jours un temps d'attente supérieur à 2 secondes est (perçu comme) inacceptable pour l'utilisateur.