Discussion :

[Invité]

Concernant le back, node c'est tout simplement une tuerie niveau performance

Dans quelles situations ? 20% des cas d'utilisation ? :sifflote:

[Spartacusply]

Dans quelles situations ? 20% des cas d'utilisation ? :sifflote:

Quasiment dans... tous les cas. En fait c'est simple dès qu'il y a au moins 2 tâches concurrentes, c'est forcément plus rapide et plus efficace que tous les autres languages qui ne sont pas multithreadés (dont PHP).

PS : Je précise que je sais bien que Node n'est pas multithreadé, mais justement il est tellement optimisé en monothread que le seul moyen d'essayer de le concurrencer en terme de performance est le multithread (et ce n'est pas gagné pour autant d'avance).

[blbird]

Juste faire attention aux termes : Javascript n'est pas multi-thread au sens qu'il ne profite pas de multiples processeurs ou multiples coeurs des processeurs dans les navigateurs, Javascript n'a qu'un seul thread d'exécution.

Par contre, Javascript gère très bien nativement l'arrêt et la relance de tâches sur ce thread principal.

A noter qu'il existe des frameworks ou projets pour avoir du vrai mutlithread processeurs dans JS : Worker threads, http://www.hamsters.io/ et d'autres.

Informations complémentaires sur le multithread, l'asynchrone et autres exécution concurrentes : https://codewala.net/2015/07/29/conc...ing-explained/

[sekaijin]

Quasiment dans... tous les cas. En fait c'est simple dès qu'il y a au moins 2 tâches concurrentes, c'est forcément plus rapide et plus efficace que tous les autres languages qui ne sont pas multithreadés (dont PHP).

PS : Je précise que je sais bien que Node n'est pas multithreadé, mais justement il est tellement optimisé en monothread que le seul moyen d'essayer de le concurrencer en terme de performance est le multithread (et ce n'est pas gagné pour autant d'avance).

Heu il faudrait peut-être voir à regarder la réalité en face.
Oui on fait des chose très bien avec node mais c'est loin de couvrir "Quasiment tous les cas".

Pour ma part le back office est dimensionnée pour supporter une charge colossale avec des temps de réponses extrêmement bref. et pour y parvenir ce sont quelques milliers de de threads qui en temps normal se répartissent sur 2800% de CPU soit donc 28 Cœurs Itanium sur 36 dispo. le reste est pour supporter le monté en charge passagères.

node a beau être bien fait sans multiprocesseur il ne peux rivaliser.

Je ne veux surtout pas dénigrer node que je trouve très bien dans son domaine.

s'il vous plais évitez les phrases qui laissent à penser que c'est la solution universelle.
Si elle existait nous ne poserions pas la question de ce topic.

A+JYT

[Spartacusply]

Merci de lire plus qu'uniquement le message d'avant avant de s'emballer...

Surtout que ça ne fait que corroborer ma position précédente, le seul moyen de concurrencer c'est de multithreader.

[Marco46]

Pour ma part le back office est dimensionnée pour supporter une charge colossale avec des temps de réponses extrêmement bref. et pour y parvenir ce sont quelques milliers de de threads qui en temps normal se répartissent sur 2800% de CPU soit donc 28 Cœurs Itanium sur 36 dispo. le reste est pour supporter le monté en charge passagères.

node a beau être bien fait sans multiprocesseur il ne peux rivaliser.

Je ne veux surtout pas dénigrer node que je trouve très bien dans son domaine.

Son domaine c'est le temps réel et la montée en charge. Paypal par exemple est bâti sur node. La plupart des sites à fort trafic ont une couche node pour encaisser le nombre de requêtes et les fluctuations de charge.

En gros lorsqu'une requête nécessite beaucoup de ressources et de temps il faut la déléguer à quelque chose de plus adapté (un micro service java par exemple). C'est probablement ton cas d'usage, peu de requêtes mais qui consomment beaucoup. Là effectivement c'est certain que c'est pas fait pour ça.

Donc pour répondre à Artemix, je dirais ça dépend, si ton appli c'est 1000 personnels d'une entreprise connectés au max qui vont exécuter de bons gros traitements métiers c'est certain que le bon vieux Java J2EE sera plus adapté. Si le but c'est de faire du B2C sur le net avec des millions d'utilisateurs qui vont liker un message de 140 caractères node est probablement plus adapté.

Twitter fait par exemple de l'orchestration entre les fronts (applis, site web) et les backends plus lourd avec node au milieu.

[jacdeh]

Python pour le serveur, Transcrypt pour le navigateur.
C'est par j'aime utiliser la même langue sur le client et le serveur.
Et de préférence pas de JavaScript...

[Invité]

Python pour le serveur, Transcrypt pour le navigateur.
C'est par j'aime utiliser la même langue sur le client et le serveur.

C'est dommage... Ce projet (Transcrypt) n'avait pas l'air mal, mais on dirait qu'il impose javascript activé pour pouvoir charger, vu que je n'ai qu'une belle page blanche à l'accès au lien !

Du coup, baah plus qu'à oublier cet outil...

[jacdeh]

La page est écrite en Transcrypt, et cela génère du JavaScript, donc malheureusement ...

[alama32]

Adobe Muse parce que wysiwyg, je pense que l’avenir est à ce genre de programme, sinon, AS3, Java (que j'apprend).. Phyton (à voir).. Mais perso, ras le bol de ces changements continuels. et aucune de ces grosse société qui soit foutue de créer un langage simple et un vrai compilo Xplatefromes.

[Aizen64]

NodeJS répond bien à certains cas d'utilisation mais ça reste quand même limitant de ne pas pouvoir donner du traitement lourd, ça limite son utilisation.

Un gain de perf colossal ? La pupart de mes méthodes se résument à : valider de la donnée, une requête SQL, un traitement, et une insertion en BDD. Node peut lancer des choses en parallèle sauf qui va bien devoir attendre le retour de requête pour continuer son traitement, gain de perfs ? Non.

Après effectivement, pour certaines tâches, ça reste utile.

L'écosystème JS ? instable. Même des outils comme Webpack utilisé par FB et cie peuvent parfaitement avoir un comportement buggé après une MAJ. Donc au jour d'aujourd'hui l'écosystème JS ne m'inspire par du tout confiance et c'est pas le million de libs sur npm qui me rassure.

Récap :
- PHP : langage dégeulasse avec un écosystème mature,
- JS : langage dégeu aussi, juste, on est oubligé de se le tapper en front, qu'on l'aime ou non, il est incontournable,
- Java/C# : frameworks bien structurés, le hic de Microsoft est que .NET Core a encore du chemin avant d'être considéré comme stable, l'ORM ne fait pas forcément bien son travail dépendant de la base par exemple. Par contre ces 2 plateformes sont stables, fortement typés et ont des bases solides,
- Ruby : langage bien pensé et structuré mais perfs catastrophiques et avec une communauté très fermée, mets pas 4 espaces en indentation ou du camelCase en nom de variable sinon la "Communauté Ruby" va te dire une phrase de gourou : "La Communauté Ruby A Dit Que ...." [ masturbation collective sur le langage ]
- Python : propre, obligé d'indenter son code correctement ce qui n'est pas un mal

Allez mettons nous d'accord sur une chose, ce qui compte le plus, c'est pas tant le langage mais la rigueur du dev et les outils/structure de code utilisés qui comptent. Dans tous les cas, ils se piquent tous des idées. Django/Twig, Laravel est aussi basé sur Symfony etc... avec des dépendances en chaine.

Libsodium au quotidien en PHP ça change quoi ?

[Spartacusply]

Node peut lancer des choses en parallèle sauf qui va bien devoir attendre le retour de requête pour continuer son traitement, gain de perfs ? Non.

A partir du moment où tu as deux traitement qui peuvent se lancer simultanément (deux inserts, deux selects, un upload de deux fichiers, le résultat de l'un ne dépendant pas du résultat de l'autre..., me dis pas que ça t'arrive jamais), cela peut-être fait en parallèle avec Node et est forcément exécuté plus rapidement que n'importe quel langage synchrone. Si tous les résultats dépendent les uns des autres alors oui en effet tu n'auras aucun gain (de ce point de vue là en tout cas).

Libsodium au quotidien en PHP ça change quoi ?

"Au quotidien" c'est un bien grand mot mais en gros il y a moins de paramètre dans la fonction d'encryptage ce qui certifie de manière beaucoup plus certaine la qualité du cryptage produit.

[Invité]

A partir du moment où tu as deux traitement qui peuvent se lancer simultanément (deux inserts, deux selects, un upload de deux fichiers, le résultat de l'un ne dépendant pas du résultat de l'autre..., me dis pas que ça t'arrive jamais), cela peut-être fait en parallèle avec Node et est forcément exécuté plus rapidement que n'importe quel langage synchrone. Si tous les résultats dépendent les uns des autres alors oui en effet tu n'auras aucun gain (de ce point de vue là en tout cas).

Sauf qu'un langage synchrone n'a pas qu'un seul process. Apache spawn autant de processes que nécessaire et NGINX a une process pool limitée mais très rapide pour desservir des requêtes, par exemple.

"Au quotidien" c'est un bien grand mot mais en gros il y a moins de paramètre dans la fonction d'encryptage ce qui certifie de manière beaucoup plus certaine la qualité du cryptage produit.

Chiffrement*

https://chiffrer.info/

[Spartacusply]

Sauf qu'un langage synchrone n'a pas qu'un seul process. Apache spawn autant de processes que nécessaire et NGINX a une process pool limitée mais très rapide pour desservir des requêtes, par exemple.

Évidemment c'était par requête que j'entendais mes propos. Le serveur fait toujours son taf au niveau du dispatching des requêtes, ça ne change rien à ce niveau là.

Chiffrement*

https://chiffrer.info/

Oui pardon je sais. Enfin disons plutôt que je sais que je ne sais jamais, je confonds toujours entre les deux

Très sympa ce petit site chiffrer.info au passage...