Quels langages pour ce développement?

bohwaz · Juillet 30, 2024, 9:01

Je répond juste à ça pour le moment : c’est faux. PHP est très performant. En conditions équivalentes (mode asynchrone avec Swoole par exemple) il est 30% plus rapide que NodeJS et équivalent à Go.

J’ai bossé sur l’ex plus gros réseau social européen, avec des dizaines de millions d’utilisateurs, et notre code était en PHP, avec quelques dizaines de serveurs seulement : PHP fait très bien le taf en conditions réelles

NextCloud n’a pas fait l’erreur d’utiliser PHP, mais l’erreur de développer en accumulant les fonctionnalités sans jamais remettre à plat leur code, qui est un véritable plat de spaghetti. Les perfs de NextCloud sont effroyables non pas à cause du langage mais du style de développement, et de l’absence totale d’objectifs d’efficacité dans leur mode de développement. Sur les même fonctionnalités que NextCloud (gestion de fichiers), Paheko est 13 fois plus rapide et sert 41 fois plus de requêtes simultanées, et je ne suis même pas hyper attentif aux perfs quand je code ^^

Enfin, NextCloud n’est pas un daemon donc pas trop de rapport.

Fin du HS

sekil · Juillet 30, 2024, 10:34

Attention, je ne cherche pas à basher PHP, d’autant que ça reste un de mes langages de prédilection, je dis juste que chaque langage a son(es) usages(s). Tout le monde dit que PHP8 a grandement amélioré les performances, je n’ai pas eu l’occasion de faire une comparaison donc je leur fait confiance sur ce point. Tu remarqueras donc que je n’ai jamais parlé de performances.

PHP est un langage adapté à des usages stateless pour répondre à des requêtes HTTP (on l’intègre très souvent en CGI/FastCGI/FPM, plus rarement en CLI) :

Je reçois une requête HTTP
L’agent PHP (CGI/FPM) reconstruit le contexte à partir des cookies et des sessions, si nécessaire avec une BDD ou un cache mémoire
Il doit traiter la requête en moins de 30 secondes, et idéalement en quelques dizaines de ms
Il renvoie la requête et supprime le contexte

Si j’ai cité Nextcloud, c’est qu’il y a de très nombreuses features d’un cas d’usage gestion de fichiers qui ne marche pas en stateless :

Faire des opérations de nettoyage en tâche de fond, tu dois configurer un cron ou un webcron pour le faire, parce qu’il n’y a pas de service en tâche de fond.
Renvoyer un fichier de plusieurs Go en WebDAV, Nextcloud est logiquement obligé de le diviser en chunks et ne peut pas nativement garder un contexte (notamment un descripteur de fichier ouvert).
Monitorer des modifications sur des fichiers
Gérer des timeout sur des partages supérieurs à 30 secondes (j’ai eu le cas sur des partages FTP)

Ce type d’opérations, même si elles sont pour la plupart basées sur des requêtes HTTP, requièrent l’exécution d’un démon.

Bien entendu, tu peux exécuter PHP via PHP-CLI et spawner des threads pour répondre aux requêtes ou faire toute opération arbitraire, mais je maintiens que PHP n’a pas été fait pour ça. De la même manière, je ne coderais pas un site Web en C, même si j’aime beaucoup le C et que je sais que c’est possible.

En bref :

PHP est super pour répondre à de très nombreuses requêtes simples et/ou nécessitant un contexte limité
PHP n’est pas adapté pour répondre à un faible nombre de requêtes très complexes et nécessitant le maintien d’un contexte ou une interaction système

bohwaz · Juillet 30, 2024, 10:50

PHP a un usage stateless par défaut dans les serveurs web, mais c’est pas du tout obligé.

PHP dispose d’excellents modules permettant d’intégrer le serveur web, via Swoole ou ReactPHP par exemple. Dans ce cas c’est ton appli qui gère le serveur HTTP, et donc tu peux avoir des descripteurs ouverts et partagés entre les requêtes. La même chose qu’en NodeJS par exemple. Mais c’est un genre de programmation très différent, et ça ne fonctionne pas en mutualisé. C’est bien quand tu as un serveur dédié, mais là où PHP excelle c’est de pouvoir héberger des milliers d’applis différentes sur le même serveur.

NextCloud fait des chunks non pas parce qu’il ne peut pas garder un contexte, mais parce que les transferts venant des clients peuvent échouer, et donc c’est plus simple de recommencer l’upload d’un chunk de 10 Mo que d’un fichier de 2 Go. Ça n’a rien à voir, c’est une bonne pratique pour gérer les connexions instables.

PHP sait aussi très bien faire des timeouts de plus de 30 secondes, j’ai déjà testé avec succès l’envoi de fichier sur Paheko sur une connexion EDGE, en plus de 2 heures ça roule

Je ne suis pas d’accord, PHP est très bien adapté aussi à maintenir un contexte, c’est juste que tu n’utilise pas les mêmes outils c’est tout. J’ai déjà codé des daemons en PHP (sans Swoole ni ReactPHP), ça marche très bien

ppom · Septembre 10, 2024, 9:44

C’est vrai qu’aujourd’hui PHP est orienté objet, modulaire, performant. C’est le cas de plein de langages de programmation.
Outre que le langage en lui-même, je pense que c’est intéressant de se pencher sur l’écosystème autour du langage : pour quoi il est majoritairement utilisé (et donc pour quoi on trouvera de l’aide en ligne), et quel écosystème de librairies existent.
Quand viendra le moment, il sera sûrement pertinent de faire une liste de voeux pour les librairies voulues (smtp, queues, bdd, etc, je sais pas), et de chercher un langage qui a des librairies propres et bien maintenues pour notre cas d’usage.

bohwaz · Septembre 10, 2024, 2:54

Perso j’aurais bien vu du Go mais j’y connais pas grand chose à part quelques bidouilles, et j’aime pas du tout la dépendance à Google.

L’avantage de PHP que j’aime bien, c’est le fait que la standard library (les fonctionnalités de base) sont très étendues, et contrairement à Rust/Go par exemple, y’a pas besoin d’installer des dizaines (/centaines) de dépendances, dont on ne connaît pas le code, qui exposent à des soucis de sécurité potentiels, juste pour faire des trucs basiques (genre du chiffrement, du base64, etc.).

Par exemple pour le chiffrement, libsodium est intégré à PHP en standard, le binding est maintenu par l’auteur de libsodium, et c’est donc packagé aussi sur Debian. Sur Go, c’est une lib gérée par un inconnu, qui est téléchargée pour chaque personne (non packagé debian). Il me semble plus difficile de compromettre la première solution, que la seconde.

C’est un exemple, mais perso moins j’ai de code à auditer, mieux je me porte Et oui parce que je lis et essaye de comprendre le code de tout ce qui n’est pas packagé par Debian, avant de l’intégrer à un projet. Du coup quand je fait un « composer install » et que le répertoire « vendor » fait 200 Mo, heu ben je vais voir ailleurs

Après je pense au fond que la question n’est pas trop le langage, que la spécification du logiciel : ce qu’il doit faire et comment. Par exemple si on spécifique le logiciel doit être léger en ressources, et avoir le moins de dépendances possible, une API simple et lisible, d’avoir une interface web sans librairie javascript type react, mais au maximum en natif JS, etc. ben le langage derrière importe peu, c’est plutôt la logique qui compte.

Et pour moi à partir du moment où on spécifie une API de communication entre relais (et aussi une API pour les logs, les stats, etc. d’un point de vue admin/utilisateur) qui soit claire, simple et interopérable, on s’en fiche un peu du langage car il pourra y avoir une autre implémentation compatible théoriquement

sekil · Octobre 3, 2024, 8:36

2 messages ont été scindés en un nouveau sujet : SM2TP - Librairie Sisimai

n-peugnet · Septembre 18, 2024, 3:32

J’aime beaucoup PHP aussi, mais quand-même en terme de lib standard je le mettrais vraiment pas au dessus de Go. J’ai rarement vu une lib standard aussi large et flexible que celle de Go, pour une bonne partie des projets c’est dèjà suffisant pour commencer, je pense aussi à tous les outils qui vont autour. Parce que pour les tests unitaires en PHP tu as par exemple besoin de PHPUnit (ou autre mais je connais pas), qui d’ailleurs, passe son temps à déprécier et supprimer des fonctionnalités au fil des versions. Et c’est là pour moi que Go est très intéressant, avec son attachement à faire perdurer les interfaces existantes et à ne pas casser le code des gens d’une version à l’autre.

Je ne me rends pas compte ce qu’apporte libsodium par rapport au paquet crypto de la stdlib de Go ? crypto package - crypto - Go Packages

Après en vrai vous faites ce que vous voulez haha, j’ai juste tiqué sur l’argument de la lib standard. PHP avec les typehints et PHPStan c’est quasi aussi confort qu’un langage avec du typage statique.

bohwaz · Septembre 19, 2024, 2:11

libsodium est mon premier choix perso car :

dispo dans de nombreux langages
même interface, les données sont compatibles d’un langage à l’autre
pas besoin d’avoir à aller dans les détails des implémentations de crypto et donc risquer de faire des bêtises
j’ai bossé avec son dév et donc j’ai confiance dans ce qui est fait

Par exemple avec sodium tu peux chiffrer une donnée côté serveur (PHP) et la déchiffrer en JS, sans avoir à réinventer la roue, avec les même fonctions.

Go ne semble pas proposer en standard de la crypto aussi simple, mais je peux me tromper. Par contre comme tu le pointe, ça propose, via un module externe (donc non standard) le support des mêmes algos : https://pkg.go.dev/golang.org/x/crypto

Je suis d’accord pour PHPunit Je ne l’utilise pas, son usage en milieu pro m’a dégoûté. Après c’est un peu le souci de cette lib, pas de PHP lui-même.

Après voilà comme je l’ai dit, Go est sûrement très bien, je n’ai pas assez pratiqué pour juger, ce que je n’aime pas c’est les milliers de packages tiers dont on ne maîtrise pas le code

sekil · Septembre 20, 2024, 8:56

Normalement, s’agissant de crypto, les opérations que tu peux faire sont standardisées par les algos (une librairie qui s’écarterait des algos et schémas standardisés et prouvés serait à mon avis dangereuse d’un point de vue sécurité), donc c’est supposé être interopérable.

Dans la mesure où Go a été développé par google, je pense qu’on peut leur faire confiance sur l’implémentation de base.

Maintenant, si on veut une API plus simple, je comprend la réticence à aller chercher une librairie dans la communauté développée par random développeur.

Je ne vais pas dire que je suis fan des langages qui gèrent le chargement de leurs dépendances via un repository communautaire, mais bon c’est dans l’ère du temps pour de nombreux langages. Je ne suis pas sûr que ça fasse de Go un mauvais choix. Pour moi, Le problème (c’est peut-être ce que tu entendais par la maîtrise du code) est surtout de choisir une librairie provenant d’un développeur de confiance, et non random personne qui a publié son code sur Github.

sekil · Septembre 20, 2024, 8:58

Toujours est-il que pour ma part le principe le plus important à respecter c’est le principe du re-use. On ne perd pas du temps à ré-implémenter des composants logiciels déjà existants, mais on trouve le moyen de les intégrer.

Donc il faudra faire l’inventaire de l’existant (que tu as déjà commencé bohwaz avec la lib sisimai) et se poser la question pour chacun :

Est-ce que le contour fonctionnel du composant correspond bien au contour fonctionnel d’un des éléments que nous avons identifié ?
Est-ce que ça prend plus de temps de l’intégrer ou de le ré-implémenter ?
Est-ce que la complexité induite par l’intégration du composant est justifiée par rapport au temps de dev et de maintenance que cela nous fait gagner ?

C’est pour ces raisons que j’étais très critique à l’idée de redévelopper un serveur SMTP.