Réaction à "Le défaut des frameworks: tout dans le même langage"

[Sephi-Chan]

Hello,

Je souhaitais réagir à l'article Le défaut des frameworks: tout dans le même langage du blog de Xenos (il me semblait que tu avais fait un bouton dédié pour ça !).

A mon sens, router depuis le serveur n'a pas d'intérêt particulier. Déjà, parce que l'utilisation du .htaccess est propre à Apache, il n'y a pas d'équivalent sur Nginx, par exemple. Dès lors, le faire avec un autre outil complexifie les déploiements en ajoutant plusieurs sources d'autorité.

Si on considère le jeu comme une application, son composant "application Web" n'est qu'un petit bout (il y a sûrement une base de données, des jobs qui tournent, peut-être un daemon, un serveur de push, un message broker, etc.). Dès lors, rien de choquant à ce que le serveur Web délègue une partie du travail à l'application : il traite une partie des URL et laisse les autres à la discrétion de l'application.

Si on veut déléguer à un autre endpoint — par exemple un script appelé très souvent et pour lequel on ne veut pas passer par toute la stack — il est cette fois tout à fait adapté de l'inscrire dans la configuration du serveur Web.


Concernant le choix des outils, certains préfèrent garder le moins possibles de technologies différentes. Si les tâches de fond tournent en Java, l'appli Web en PHP, etc. tu dois te taper la maintenance de beaucoup de paquets, tu ne peux pas réutiliser de code, etc. Le discours qu'on entend parfois sur "le bon outil pour le travail" est souvent une source affreuse de complexité que personne ne veut s'infliger.

Dans l'absolu, on pourrait utiliser un message broker (comme RabbitMQ) en guise d'interface unifié entre plusieurs composants potentiellement écrits dans des langages différents : l'appli Web en PHP, le système de pathfinding en C, etc. Sauf que la communication pose problème (surtout si elle est asynchrone) et la complexité engendrée augmente ta dette technologique : ça ne vaut généralement pas le coût/coup.

En somme, dans bien des cas, c'est très beau philosophiquement, mais ce n'est pas du tout pratique. Et ça, ça compte énormément.

Selon moi, la conclusion est donc terriblement erronée :

Les frameworks tendent à vouloir tout faire dans un même langage (rootage, logique métier, modèle, template, etc). Or, chaque langage a ses spécificités qui le rende adapté à un type de tâches précises: vouloir tout lui faire faire est risqué et complexe.

Je dirais plutôt :

Les frameworks tendent à vouloir tout faire dans un même langage (rootage, logique métier, modèle, template, etc). Or, chaque outil a ses spécificités qui le rende adapté à un type de tâches précises: vouloir tout lui faire faire est très simple (pour le développeur et l'administrateur système) mais peut être moins performant.

[Xenos]

Hey,

Justement, je trouve l'argument du "htaccess, c'est spécifique à Apache" peu cohérent. C'est du même ressort que "Je ne fais pas de procédures MySQL car c'est pas compatible Postgre ou Mongo DB". Du coup, cela revient à se limiter non pas à ce qu'Apache permet (ou ce que MySQL permet), mais à ce que l'intersection Nginx∩Tomcat∩Apache∩Autre permet, qui se réduit drastiquement... D'ailleurs, je ne serai pas étonné qu'on ait des procédures pour basculer un .htaccess en l'équivalent de rootage Nginx.
Et surtout, l'argument s'invalide tout seul: si on balance tout dans le PHP (par exemple), on aura exactement les mêmes problèmes quand on voudra passer le PHP à Java...

Cela crée en fait des applications très monolithiques, qui sont du type de celles de nos "concurrents" au taff. Notre archi est justement hyper-fragmentée (type micro-service), et on a donc une grande souplesse pour gérer tout ce bazar. Ok, on dépense des ressources pour faire communiquer chaque composant (chaque serveur), mais au bout du compte, c'est gérable. Alors qu'une énorme appli monolithique "avec tout dedans" serait juste ingérable, et s'effondrerait sous son propre poids.


Note que l'argument de performance, je m'en tamponne l'oreille avec une babouche (désolé, la lecture aléatoire de VLC est en train de lire l'ep. 30 de Naheulbeuk!), et tout le monde devrait en faire autant: le temps de la machine, on s'en fiche complètement (tant qu'il reste "calculable"). C'est le temps des développeurs qui compte.
"Vouloir tout lui faire faire est très simple", oui, si tu veux, mais cela ne tient pas dans le temps (la quantité de moyens humains pour le faire tenir explose vite), d'où le risque, et c'est complexe car on se retrouve à utiliser des langages qui ont une philosophie pas du tout adaptée à ce qu'on veut faire. Par exemple, sortir du HTML avec PHP, finalement, c'est plus subtil que de bêtes "echo". Sortir du HTML avec du XSL, c'est très simple. Sortir du HTML avec du MySQL, c'est juste misérable.



Le lien est bien sur les articles... https://toile.reinom.com/page-daccueil-e...ec-jeuweb/ Mais c'est un ajout en JS me semble-t-il (parce que je ne voulais pas taper sur les sources de Wordpress, faudrait que je fasse cela proprement quand même...!). Merci de ta réaction aussi, cela me permet de me savoir un peu lu

[Sephi-Chan]

L'argument du htaccess, c'est pour te dire que non, ce n'est pas forcément le rôle du serveur Web de router toutes les requêtes. C'est tout à fait acceptable et même très sain de déléguer des pans du routage. Ça permet de découper : les requêtes qui entrent sur api.endive.com sont gérées par l'appli Web dédiée à l'API (qui n'est pas forcément la même que celle qui va gérer le frontend), les ressources statiques (JS, CSS…) sont servies directement, etc.

Je suis tout à fait favorable aux micro services et j'avais plusieurs gros projets (au boulot) qui fonctionnaient (bien) ainsi, mais c'est complexe (outre l'éventuel partage du code, dès que tu veux des logs consolidés pour suivre une info sur plusieurs services, il te faut des outils, type Logstash, Kibana et donc ElasticSearch, et la stack techno double de volume) et donc coûteux en temps-développeur (je te rejoins : c'est le seul qui importe réellement).

Martin Fowler — pourtant partisan des micro services — le dit lui-même, il vaut mieux commencer par une architecture monolithique et découper ensuite selon les besoins.

Je mets ma tête au feu que — dans un projet de petite taille comme ceux qu'on a sur JeuWeb — l'architecture monolithique ne devient jamais ingérable, et surtout qu'on peut détacher facilement certains services. Dans un jeu Web, il suffit généralement d'une appli Web et d'un service de background job pour tout faire. Alors effectivement PHP est très mal loti en matière de background job, alors que Ruby — pourtant taillé pour des usages similaires à PHP — en a plusieurs excellents (Resque, Sidekiq…).

Concernant tes exemples, je ne me retrouve pas dedans (sauf en ce qui concerne sortir du HTML avec MySQL) : PHP est un langage de template, c'est taillé pour rendre du HTML ou du XML (si tu décides de rendre du XML à transformer par XSLT). D'ailleurs, la couche supplémentaire XSL ajoute encore de la complexité (malgré ses avantages). Et ce n'est pas parce qu'une fonctionnalité n'est pas dans la lib standard du langage que le langage n'est pas fait pour.


Je te lis de temps en temps, c'est souvent intéressant même si je ne suis pas toujours d'accord. Ici, ça m'a paru important de réagir !

[niahoo]

Je lis aussi le blog et je partage l'avis de Séphi sur ce point. D'autant plus que sur mes projets le serveur web et la base de données sont codées dans le même langage que mon jeu :p

[Xenos]

il te faut des outils, type Logstash, Kibana

C'est le cas :p

Partir du monolithe, en fait, c'est un peu... "biaisé" je dirai car au fond, j'm'en fous de l'apparence "monolithe", c'est le côté "indécoupable - tout intriqué" qui me pose soucis (j'aime les choses aux frontières nettes et précises). Le monolithe qu'on peut décomposer, en fait, ce n'est pas un monolithe: c'est une structure micro-service avec une façade (qui la rend monolithique de l'extérieur; c'est même sûrement le top je pense, car on a les avantages des deux archis). Et ce qui me gène avec des principes comme le routage dans le PHP, c'est que j'y trouve un genre d'intrication entre le serveur et l'appli, qui rend le scindage délicat et difficile [note que je parle du rootage "je passe la requête HTTP à mon appli PHP avec l'URI et celle-ci se démerde; je me sers donc du serveur web, Apache, pour faire l'interface et passer de l'URI extérieur visible au composant, la classe PHP ou le fichier statique ou un autre truc, qui y répondra].

Après, oui, la taille du projet compte clairement, mais c'était un élément que j'avais raté dans ce qui me déplaisait des framework (tout faire au même endroit). Perso, ça ne me dérange pas d'avoir des "bouts partout", car je trouve cela bien plus facile à gérer, surtout quand chaque bout, chaque composant, utilise des protocoles de communication standard (qui permettent d'aller le brancher à d'autres bouts).