Blend Web Mix v2017
Il y a quelques jours, s’est tenue la conférence Blend Web Mix version 2017. C’était la première fois que j’y participais, vu de ma fenêtre, l’organisation était au top 👍. La seule ombre au tableau, à mon sens, sont les conférences techniques courtes (15 minutes). Je n’en ai pas compris l’intérêt, mis à part avoir un nombre de talks plus important, c’était frustrant.
Ci-dessous, vous trouverez mes retours sur les talks que j’ai vus et appréciés. Au moment où j’écris ce billet, les vidéos des talks ne sont pas encore diffusées par l’équipe du @blendwebmix. Je les ajouterai dès que cela sera possible !!
CSS In JS by Thomas Zilliox
Ce que j’ai apprécié avant tout, c’est le parti pris. Ok écrire du CSS dans un fichier JavaScript n’est pas du tout standard. La séparation du style (CSS), du DOM (HTML) et des manipulations dynamiques (JS) est une bonne pratique qui nous est enseignée depuis un moment dans le cadre d’une application web et nos outils y sont adaptés (IDE, Outils de développements, coloration syntaxique, auto-complétion, …).
L’arrivée de React.js notamment, a remis en question ce paradigme, que ce soit pour les intégrateurs et les développeurs. Avec philosophie, Thomas nous a transmis son analyse sur les points positifs et négatifs de cette approche.
Positifs:
- Style CSS isolé par composant
- Rapprochement avec les équipes de développeurs
- Si l’approche se généralise, les outils de développements seront développés par la communauté
- Avec l’arrivée de React Native, il est désormais possible de styliser une application mobile via du CSS
Négatifs:
- À date, les outils de développements ne sont pas optimisés, adaptés
- Ce n’est pas un standard
- Il n’est pas possible d’utiliser des processeurs (Saas, Less, …)
Au final, Thomas a appelé les intégrateurs à être ouverts d’esprit sur cette approche qui semble avoir ses détracteurs. Des nouveaux outils, des nouvelles pratiques peuvent émerger selon lui.
N’étant pas intégrateur, j’aurai aimé, afin que le talk soit plus complet, un comparatif avec les standards, notamment les “futurs” standards tels que les web components. Surtout que ceux-ci sont supportés par Angular, qui prône une approche à l’opposé de React.
Les slides de Thomas :
GraphQL, l’avenir du REST by François Zaninotto
La présentation de François était très pragmatique. Dans un premier temps, il a évoqué les points faibles des API REST, à savoir :
- Les performances. Les routes étant découpées par ressources, il y aura autant d’appels réseaux que de ressources pour alimenter une page. Certaines ressources dépendent d’autres ressources. Ce qui va provoquer une latence qui dégrade l’expérience utilisateur.
- Pas de contrat d’interface avec l’API Rest. Des outils annexes (Swagger, …) existent mais cela n’est pas standard et dépend de l’équipe qui développe l’API.
- Le versioning d’API.
- Le client ne peut pas choisir les champs dont il a besoin, il ne peut récupérer qu’une ressource. De fait, un nombre important de champs transite sur le réseau alors qu’ils ne seront pas utilisés dans l’application cliente.
- Plus adapté au besoin actuel
Pour être complet, avant de présenter GraphQL, il est revenu sur d’autres alternatives:
- Super API REST => choix des champs en query parameter
- SQL over HTTP
- Protocol Buffer
- Falcor => librairie open source by Netflix
Nous étions maintenant tout ouïe pour la présentation de GraphQL. François nous a donc présenté ce qu’était GraphQL, comment écrire une requête, créer un serveur, aggrégér des ressources, sélectionner uniquement les champs utiles, ….
Je vous redirige vers la série d’articles qu’il a rédigé sur le blog de @marmelab . C’est vraiment mieux que tout ce que je pourrai faire comme retour.
La vraie plus value de son talk était la dernière partie consacrée au retour d’expérience. Il est revenu objectivement sur l’outil, sa communauté grandissante, les articles de blog, tutoriaux qui ne sont plus à jour, la jeunesse de l’outil, les difficultés pour monitorer les serveurs, … Malgré cela, les forces de l’outil prenaient le pas sur les inconvénients. Il a aussi précisé que le bénéfice de GraphQL dépendait surtout du contexte projet / SI.
Encore une fois, je vais vous diriger vers son article de blog dédié à ce sujet. Je n’ai pas encore joué avec GraphQL, il m’a donné envie d’essayer, bien joué 👍.
API en Protobuf : 3 fois mieux que le JSON by Pascal Corpet
Pascal a été formé aux Protocol Buffer chez Google qui développe ce langage de description d’interface. Convaincu par l’outil, il l’utilise aussi sur son projet actuel chez Bayes Impact. Avec une présentation très technique, il nous a présenté ce que sont les Protocol Buffer :
- Définition du schéma d’interface, création des fichiers .proto
- Représentation des payloads dans les fichiers .proto
- Comment générer via
protocles objets définis dans l’interface ? Le compilateur prend en charge certains langages comme Java, JavaScript, C++, C# qui sont maintenus par les équipes de Google. D’autres langages tel Swift, Erlang sont eux maintenus par la communauté.
Maintenant que l’interface permet de générer les objets qu’elle définit dans un langage donné, il est désormais possible de stocker, transférer (ex: une application cliente qui appelle une API) les objets sous différents formats, Text, JSON, Binaire, Pb JS, … L’interface étant connue des différents partis, il est tout à fait possible d’avoir un format d’échange pour optimiser le plus possible les données que l’on stocke ou que l’on fait transiter.
De mon point de vue l’optimisation est vraiment conséquente, c’est toute la force de l’outil. Il faut toutefois définir une stratégie de partage de ces interfaces entre les différents projets au sein d’un SI. Pour régler cette problématique, Pascal utilise la même que celle de Google: tous les projets sont dans le même repository. Pas sur que ce soit une approche aisée à mettre en place chez les clients.
Encore une fois, ça m’a donné envie d’essayer 👍.
Les slides de Pascal:
Voyage au centre du cerveau humain ou comment manipuler des données binaires en JavaScript by Thomas Jarrand
Je souhaite aussi mentionner le talk de Thomas que j’ai fortement apprécié. Un retour d’expérience plus que pertinent dans une conférence telle que Blend Web Mix.
Thomas nous a présenté la problématique à laquelle son équipe et lui ont été confrontés sur un projet web. Ils devaient afficher dans une interface web, des images produites par résonance magnétique (IRM). Les fichiers produits par l’IRM étant en binaire, il nous a donc fait réviser les bases du binaire en JavaScript, ça faisait longtemps pour ma part 😅. Je vous recommande vivement de regarder son talk lorsqu’il sera disponible.
Les slides de Thomas:
Objectif rempli pour @blendwebmix v2017, j’ai pu assister à des conférences sur des sujets que je ne maîtrisais pas ou mal, et qui m’ont donné envie de les tester. Une petite frustration sur les talks en format court et sur les talks qui étaient complets et donc auxquels je n’ai pas pu assister. En même temps, j’avais qu’à prévoir un peu plus de marge pour être sur d’avoir une place. Mais bon, on discute, on rencontre des gens, que l’on connait ou pas, mais avec qui nous avons des échanges souvent passionnés et des fois passionnants 🙂. Hâte de connaitre la programmation de l’année prochaine !!!
“Remember - BEWIZYU, always”…
