Développer un Frontal Web : Google Web Starter Kit & Material Design Lite & React

Parlons un peu de développement Web histoire de se changer les idées car dernièrement dans mes derniers projets professionnels je n'ai pas trop tâté du Web. Je suis côté cœur de SI : services métier, médiation, stockage des données... Mais de temps en temps il faut bien se replonger dans le développement Web car c'est un monde qui bouge beaucoup... et un peu trop vite, c'est quasiment impossible d'être à jour, le temps de réaliser un projet et déjà de nouvelles normes, de nouveaux frameworks... Personnellement j'ai raté pas mal d'étapes et c'est temps mieux, je me suis arrêté à Ext-JS (maintenant Sancha, quand c'était gratuit...) et à JQuery, JQueryUI. Bon tout ça existe toujours mais ils ont moins le vent en poupe. Et du coup j'ai sauté la période Bootstrap / AngularJS (qui va surement se relancer avec la version 2) et qui restent à la pointe et s'améliorent.

Donc je m'attaque au développement Web avec Material Design Lite (porté par les standard de Google) mixé avec React (le framework de Facebook), oui les deux mastodontes d'internet, pourquoi s'en priver c'est gratuit. Et je ne me lance pas dans un développement complexe qui pourrait nécessiter un Backbone.js mais à terme pourquoi pas c'est l’intérêt de React : ça ne ferme pas les portes. Et puis pour cadre tout ça le Google Web Starter Kit.

Material Design Lite

Commençons pas présenter MDL qui implémente le Material Design de Google, c'est très léger : du CSS et un javascript. Cela donne un cadre pour réaliser une interface web, c'est très pratique pour les ingénieurs comme moi qui sont très loin d'être des web designer, ici, on a qu'a choisir la couleur (oui c'est assez restrictif mais ça évite de faire un site qui pique les yeux), un template (ou pas) et les composants. Après ce framework n'est pas très complet aujourd'hui et il manque pas mal de composants, j'attend la version suivante !

React JS

React JS c'est un framework de génération de DOM HTML utilisant le syntaxe JSX qui permet d'écrire cela simplement. React promet simplicité et performance.

Bon c'est pas si simple car on perd les bases du déroulement de la page html et de son chargement. Bref il faut utiliser des astuces pour réaliser lancer les petits scripts nécessaires à MDL pour décorer les composants.

Google Web Starter Kit

Peut de développement dans ce kit, juste le packaging d'outils basés sur node.js pour avoir un platforme de développement web qui est vraiment efficace. On peut modifier le gulpfile.js pour prendre en charge le JSX avec Babel et le tour est joué.

Conclusion

Ces outils marchent PRESQUE ensemble out-of-the-box. C'est React (normal c'est l’intrus) qui fou la grouille.

Voila la solution pour MDL avec React :

var Header = React.createClass({

  componentDidUpdate: function() {

      // Décore tous les composant avec 'mdl-js-* class

      componentHandler.upgradeDom();

  },

Sans oublier l’utilisation d'un require(../material.min.js) pour être sur d'avoir la méthode accessible que browserify gérera...

Et pour le Web Starter Kit une petite modification du gulpfile.js pour prendre en compte JSX (mais je pense que dans la prochaine version ce sera inclus) : 

gulp.task('scripts', function () {

  return gulp.src('app/scripts/monApp.jsx')

  .pipe(babel())

  .pipe(browserify())

  .pipe(gulp.dest('app/scripts/'));

});

[...] 

// Build production files, the default task

gulp.task('default', ['clean'], function (cb) {

  runSequence('styles', ['scripts', 'jshint', 'html', 'images', 'fonts', 'copy'], cb);

});

Mise à jour 02/11/2015 :

Bon quelques soucis j'ai l'impression que le componentHandler.upgradeDom(); fait sauter les événements enregistrés par React... du coup j'ai ajouté react-native-listener. Je ne sais pas si c'est LA solution mais ça marche...

Mise à jour 05/11/2015 :

Pour le même problème que précédemment une solution est d'enregistrer l’événement à la suite :

componentHandler.upgradeDom();  

document.getElementById('myButton').addEventListener("click", this.props.handleClick);

Mise à jour 01/01/2016 :

Suite à la mise à jour de material design lite à la version v1.0.6 je n'ai pas plus besoin de react-native-listener pour la plupart des événements. Cela s'améliore de jour en jour.

Considération sur l'Architecture en Microservices

Voila la nouvelle voie de l'architecture applicative ! Les microservices vont révolutionner votre SI et diminuer drastiquement les coûts, réduire les temps de développements bref que du bonheur. Mouais faut relativiser, c'est comme tout, faut-il encore bien le faire. Par ce que bon depuis le temps, je suis pas certain que nous les "nouvelles technologie" aient permis de retrouver la productivité, la performance et la fiabilité des bon vieux Mainframe !

Enfin bon moi je suis dans la nouvelle tech alors parlons un peu des microservices. Un petit tour sur Wikipedia et divers sources et on retient :

• L'architecture en microservice est une architecture applicative que l'on peut rapprocher d'une architecture n-tiers.  
• Elle n'est pas en concurrence avec une approche SOA car orienté application et non système d'information : seuls les microservice de "haut niveau" sont exposés au SI et ceci dans le respect des règles de la SOA.

Une telle architecture permettrait de donner de la flexibilité non plus au niveau d'un SI (où règne la SOA) mais au niveau d'un applicatif. Ainsi si une fonctionnalité est très consommatrice en ressource pourquoi ne pas la coder dans un technologie plus efficiente comme en GO ou en C ou encore clusteriser le service...  Cette flexibilité technologique aussi de construire un composant  de l'application avec par exemple une application NodeJS existante (genre NodeRed).

Côté humain, pour que cela fonctionne il vous faut une équipe de superman multi techno, et puis côté production c'est la panique alors une alternative est de passer le tout sous Docker... donc ça veut dire qu'en fin de développement une bonne part du travail de l'exploitation est réalisé. Alors là va falloir soit briser les barrières entre les développeurs et les exploitants, ce qui n'est pas évident... entre les uns qui subissent les bugs des autres, les autres disent que les uns veulent juste presser UN bouton... c'est pas gagné. OK ce qu'il vous faut c'est une équipe de super DevOps comme on dit, mouais va falloir les trouver les petits gars, piquer quelques ressource chez OVH et Google et c'est parti. C'est fou comme tout de suite ça devient moins réaliste.

Côté infrastructure, au lieu d'avoir un découpage par API au sein d'une application on a un découpage de service, de services exposés sur le réseau. Cela sous entend qu'ajouter un passage sur le réseau n'est pas un problème pour vous, bande passante démesurée et latence faible... bon aujourd'hui ça se trouve facilement. En suite vous aurez un surconsommation de mémoire et de CPU par rapport à une application monolithique :

• Le passage par le réseau va nécessiter une sérialisation et dé-sérialisation (CPU) ce qui grosso-modo entraîne un pique x4 de la trace mémoire qui sera absorbé par les garbage collector ou autre gestionnaire de mémoire (CPU).
• Mutualisation des API tiers dans un application monolithique et du serveur d'application (Jboss ou autre). 
  

Après une réalité économique est que les coûts du CPU, de la mémoire, du le réseau diminuent rapidement avec le temps alors que le coût de la main d'œuvre augmente (j'aimerais qu'il augmente un peu plus). Donc l'architecture en microservices a du sens. Bien utilisé certains pensent même que cela pourrait mettre à défaut la loi de Brooks, ce dont je doute mais c'est le rêve de tout chef de projet, parfois ils rêvent éveillés, mais attention au réveil le bilan est souvent lourd...