La génération des applications prend de plus en plus de place dans la pratique de développement aujourd'hui. Le principe repose sur l'idée que les applications de même type (si on suppose qu'une catégorisation efficace peut être proposer pour regrouper les applications de même type) partage assez d'éléments pour justifier la génération de ces éléments d'une manière automatique.
Personnellement, je suis contre une utilisation massive ou sans une prise en compte de risque de cette approche. Le risque principal réside dans la possibilité d'imposer des trop de contraintes techniques sur l'application par la plateforme alors que la situation naturelle est bien l'inverse.
Le deuxième risque majeure est le nombre très élevé des dépendances sur lesquelles la génération et, par conséquent, l'application sont basées. Une justification illustrée est citée sur l'article de discussion.
Dans cet article, je vais donner un exemple sur la génération d'une application avec une partie du code. Ainsi, je ne vais pas faire appel à Grails, Ruby on Rails ou même Maven. Je vais compter sur Yeoman. Un générateur d'applications web. Et lorsqu'on dit une application web ces jours là, alors, on veut dire Node.
Ainsi, l'installation se fait par une commande npm :
Il faut installer le générateur à utiliser parce que le package par défaut ne vient pas avec un :
Cela est bien dit dans la documentation officielle. Ce qu'on ne trouve pas si les détails sur les droits ad'accès et le lieu d'installation. En d'autres termes, ils supposent que l'utilisateur metrise bien Node et npm. L'installation prend un moment puisque, encore une fois, le système installe ces paquets et leurs dépendances.
Par la suite, la génération ne pose pas problème :
Attendez, j'ai dit "pas de problème" ? Bien sûr que non, le système se lance à nouveau dans une procédure de téléchargement des plug in et des paquets. Le problème principale se pose encore une fois parce que les packages principaux de Node sont installés avec des droits d'accès supérieurs alors
qu'on est entrain de créer une application par et pour un utilisateur simple. Apparemment, ce problème est très fréquent au point où un message qui recommande l'exécution avec des droits supérieurs est affiché par défaut. L'enfer n'est pas signalé dans la documentation et vous allez vous trouver avec des
Pour éviter de trop vous casser la tête.
Par la suite, on trouve que l'application générée dépend sur Gulp, un outil de gestion des dépendances et de construction des projets JS. Si j'ai rien contre Gulp, le fait d'être obligé de l'avoir comme une dépendance en tant qu'outil (et non pas seulement une bibliothèque) me dérange énormément.
Encode une fois, on doit faire appel à npm :
Les mêmes remarques concernant les droits d'accès et les permissions se répètent.
Enfin, l'exécution avec Gulp :
La console :
L'application générée (dossiers) :
L'application générée (résultat) :
La supervision de l'application (intégrée automatiquement et sur un port différent grâce à Browsersync) :
On voit clairement le nombre de clients actuels et les différentes informations pour une meilleure supervision.
Et malgré ce résultat final, je garde mes réserves contre cette approches, surtout lorsque je voit le nombre de fichiers créés et le nombre de dépendances Node intégrées (2689 directories, 20207 files).
Cela ne représente qu'un exemple. Yeoman lui même est une dépendance pour des systèmes de génération plus complexes et qui se basent sur plusieurs couches. JHipster en est un exemple.
Personnellement, je suis contre une utilisation massive ou sans une prise en compte de risque de cette approche. Le risque principal réside dans la possibilité d'imposer des trop de contraintes techniques sur l'application par la plateforme alors que la situation naturelle est bien l'inverse.
Le deuxième risque majeure est le nombre très élevé des dépendances sur lesquelles la génération et, par conséquent, l'application sont basées. Une justification illustrée est citée sur l'article de discussion.
Dans cet article, je vais donner un exemple sur la génération d'une application avec une partie du code. Ainsi, je ne vais pas faire appel à Grails, Ruby on Rails ou même Maven. Je vais compter sur Yeoman. Un générateur d'applications web. Et lorsqu'on dit une application web ces jours là, alors, on veut dire Node.
Ainsi, l'installation se fait par une commande npm :
npm install -g yo
Il faut installer le générateur à utiliser parce que le package par défaut ne vient pas avec un :
npm install -g generator-webapp
Cela est bien dit dans la documentation officielle. Ce qu'on ne trouve pas si les détails sur les droits ad'accès et le lieu d'installation. En d'autres termes, ils supposent que l'utilisateur metrise bien Node et npm. L'installation prend un moment puisque, encore une fois, le système installe ces paquets et leurs dépendances.
Par la suite, la génération ne pose pas problème :
yo webapp
Et l'application est créée.Attendez, j'ai dit "pas de problème" ? Bien sûr que non, le système se lance à nouveau dans une procédure de téléchargement des plug in et des paquets. Le problème principale se pose encore une fois parce que les packages principaux de Node sont installés avec des droits d'accès supérieurs alors
qu'on est entrain de créer une application par et pour un utilisateur simple. Apparemment, ce problème est très fréquent au point où un message qui recommande l'exécution avec des droits supérieurs est affiché par défaut. L'enfer n'est pas signalé dans la documentation et vous allez vous trouver avec des
chmod 777 -R
Pour éviter de trop vous casser la tête.
Par la suite, on trouve que l'application générée dépend sur Gulp, un outil de gestion des dépendances et de construction des projets JS. Si j'ai rien contre Gulp, le fait d'être obligé de l'avoir comme une dépendance en tant qu'outil (et non pas seulement une bibliothèque) me dérange énormément.
Encode une fois, on doit faire appel à npm :
npm install -g gulp-cli
Les mêmes remarques concernant les droits d'accès et les permissions se répètent.
Enfin, l'exécution avec Gulp :
gulp serve
La console :
L'application générée (dossiers) :
L'application générée (résultat) :
La supervision de l'application (intégrée automatiquement et sur un port différent grâce à Browsersync) :
On voit clairement le nombre de clients actuels et les différentes informations pour une meilleure supervision.
Et malgré ce résultat final, je garde mes réserves contre cette approches, surtout lorsque je voit le nombre de fichiers créés et le nombre de dépendances Node intégrées (2689 directories, 20207 files).
Cela ne représente qu'un exemple. Yeoman lui même est une dépendance pour des systèmes de génération plus complexes et qui se basent sur plusieurs couches. JHipster en est un exemple.
