28-10-2016, 01:11 AM
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 !
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 !