Accueil > Web > Paris Web 2015 : webperfs, CSP et microservices

Paris Web 2015 : webperfs, CSP et microservices

Paris Web

Ceci est la suite de mon compte rendu sur Paris Web. Lisez la première partie en cliquant ici.

Dans ce second article, nous allons parler des sujets Webperf 2.0, Content Security Policy, et microservices, abordés par certains orateurs.

Webperf 2.0

Stéphane Rios nous présente dans sa conférence un état des lieux des performances web, essentiellement du point de vue du chargement des pages web. Son conseil principal est le suivant : il faut sans cesse se tenir informé, car les règles en matière de web performance peuvent changer radicalement et rapidement.

Les conseils ont parfois l'allure de commandements intemporels...

Les conseils ont parfois l’allure de commandements intemporels…

Et son exemple principal fait mouche, puisqu’il s’agit de la concaténation des fichiers, une pratique bien ancrée dans nos projets actuellement ! Si cela semblait une évidence pour l’optimisation de nos sites web – cela permet en effet de réduire le nombre de requêtes HTTP – il nous prouve qu’aujourd’hui la question se pose de nouveaux. En effet, un seul fichier très long peut ralentir le chargement de la page, alors qu’aujourd’hui les navigateurs sont capables de paralléliser le téléchargement des fichiers. Cela devient d’autant plus vrai avec HTTP/2. Il faut donc rester prudent et ne pas concaténer à outrance et privilégier les tests pour trouver le meilleur compromis. Dans la même veine, il considère que la minification des fichiers a peu d’intérêt, l’essentiel du temps de chargement étant dû à la requête HTTP elle-même, et non à la taille du fichier qui varie “peu” une fois minifié.

Alors comment optimiser un site aujourd’hui ? Stéphane Rios parle sans surprise du chargement progressif, grande tendance actuellement dans le monde du web. Il faut charger immédiatement tout ce qui est nécessaire au premier rendu de la page, puis charger ensuite progressivement ce qui manque. Pour cela, on peut ainsi faire du lazy-loading sur les images en-dessous de la ligne de flottaison, charger nos scripts par modules seulement lorsque ceux-ci sont utilisés, charger nos polices de façon asynchrones… Pour charger rapidement les éléments essentiels, il ne faut pas hésiter à inliner le CSS, les images et les scripts, selon ce que Stéphane Rios nomme le inline first view. Plus couramment, on trouve sur internet des articles sur le critical rendering path. Je vous conseille d’ailleurs cette excellente vidéo d’Addy Osmani et de Paul Kinlan sur leur outil PageSpeed Insight.

La gestion du cache doit également être une priorité du développeur. Côté serveur évidemment, en définissant précisément la granularité de nos caches. On peut également mettre en cache des versions cookieless de nos pages, en partant de ce constat très simple : tous les visiteurs sans cookies ne sont pas authentifiés et on donc accès exactement au même contenu. On peut donc mettre en cache cette version des pages pour la servir plus rapidement. Mais aujourd’hui, il est aussi possible de gérer le cache directement en front avec les services workers. Ceux-ci sont des composants agissant comme un proxy dans le navigateur de l’utilisateur, ayant un contrôle absolu sur les ressources téléchargées et la mise en cache de celles-ci. En poussant plus loin son concept, on peut se retrouver ainsi avec des sites offline first qui, passés le premier chargement, sont mises en cache et donc capables de s’exécuter sans la moindre connexion internet !

CSP : Content Security Policy

Nicolas Hoffmann nous présente dans cette conférence une technologie permettant de sécuriser très simplement et très efficacement son front-end. Il s’agit de Content Security Policy, dont la première spécification est plutôt bien supportée par les navigateurs actuels (avec quelques précautions pour IE 10-11). Pour les navigateurs ne la supportant pas, cela ne pose cependant aucun inconvénient puisque ceux-ci ignorent simplement les directives qu’on leur envoie. Cette conférence a été pour moi une vraie découverte, car je n’avais jamais entendu parler de ce sujet auparavant.

Mais en quoi consiste cette technologie ? Il s’agit tout simplement d’envoyer via les headers HTTP des directives au navigateur pour lui indiquer strictement ce qu’il est autorisé de faire. Attention, on ne peut pas seulement refuser ce qui ne nous convient pas, il faut autoriser tout ce dont a besoin notre front-end sous peine de se le voir interdire ! Cela peut paraître contraignant, mais c’est la seule façon d’être certain de ne pas oublier des restrictions, ce qui serait potentiellement dangereux.

Mais de quoi nous protège CSP ? Il permet principalement d’éviter les failles cross-site scripting (XSS), c’est-à-dire l’inclusion et l’exécution d’un code malveillant dans notre page. Pour cela, on peut décider de n’autoriser que les scripts ou contenus issus du même nom de domaine que notre site, ou bien interdire les scripts dits inline pouvant être ajoutés dans des contenus utilisateurs, … Les directives sont à insérer dans le header HTTP Content-Security-Policy: et se présentent par exemple sous cette forme : script-src 'self' 'unsafe-inline' ;

De par son expérience, Nicolas Hoffmann nous recommande cependant d’être prudent sur la mise en place en utilisant deux headers supplémentaires. Le premier, Content-Security-Policy-Report-URI, permet de spécifier une adresse sur laquelle le navigateur pourra envoyer des alertes pour chaque contenu bloqué. Cela permet ainsi au webmaster de suivre très exactement ce qui est bloqué et donc de pouvoir repérer facilement des autorisations oubliées. La seconde, Content-Security-Policy-Report-Only, permet d’indiquer au navigateur de seulement simuler les directives, c’est-à-dire de ne pas bloquer effectivement les contenus, mais de soulever quand même des alertes. Cela permet donc d’effectuer ses tests en toute sérénité sans que l’utilisateur en pâtisse.

Un exemple de notifications reçues

Un exemple des notifications reçues

Découper son application monolithique : Pourquoi ? Comment ?

Benjamin Fraud et Olivier Dolbeau nous font ici un retour sur la mise en place d’une architecture micro-services chez Blablacar. Avant cela, leur site web était une application monolithique, c’est-à-dire une grosse application rassemblant tous les services REST et toutes les couches métiers de l’écosystème Blablacar. Tant que celui restait relativement petit, cette organisation fonctionnait très bien, mais avec l’augmentation de la base de code, de nombreux problèmes ont fini par se poser.

Pour commencer, avec leur processus de déploiement continu, leur workflow de livraison prenait une vingtaine de minutes, voire parfois bien plus. Malheureusement pour beaucoup, cela peut sembler peu, mais lorsqu’un problème se pose en production, vingt minutes représente de très nombreuses pertes pour Blablacar ! Et pour certains développeurs, ce sont aussi 20 bonnes minutes de stress (« Passera ? Passera pas ? Je suis sûr que tout va planter…« ) !

De même, une application monolithique se révélait très compliquée à scaler facilement et à répliquer pour permettre de cibler les utilisateurs géographiquement.

Au niveau de la developper experience, la base de code était devenue trop importante pour s’y retrouver facilement. L’interdépendance des modules provoquait des effets boule de neige lorsqu’on ne vérifiait pas assez les conséquences de certains changements ; un effet qu’Olivier résume par “With minor changes comes major bugs.” Au niveau de la gestion de version, il fallait régler de nombreux conflits : plusieurs personnes intervenant régulièrement sur les mêmes parties du code, cela entraînait des rebase conséquents et pénibles.

Pour toutes ces raisons, Blablacar a donc choisi de s’orienter sur une architecture en micro-services : un ensemble de projets spécialisés chacun sur une seule brique métier. L’un prend par exemple en charge les utilisateurs, un autre la modération, un troisième les réservations… Tous ces services communiquent via un broker de messages.

Exemple des différents services chez Blablacar

Chez Blablacar la règle est simple : un service ne peut en aucune cas demander à un autre service d’effectuer des actions métier. Il peut uniquement demander les données qui lui sont nécessaires pour ses traitements. Par contre, un service peut émettre des évènements lorsqu’il réalise certaines opérations pour notifier d’autres services.

Les avantages sont nombreux. Avec ce système, les livraisons en production sont très rapides et surtout ciblées. Une déficience d’un service ne peut pas faire tomber les autres. L’application est plus facilement scalable et plus rapidement au moment des pics de charge. La base de code reste raisonnable car répartie entre de nombreux projets. Enfin, le nombre de conflits entre codeurs durant le développement a beaucoup diminué. Mais comme le précise les deux speakers, les micro-services ne sont pas une solution miracle, et apportent leur lot d’inconvénients.

En effet, l’initialisation d’une nouvelle brique métier est beaucoup plus longue, même en ayant des pattern d’applications. De même, un projet a dû être spécifiquement créé pour gérer la configuration de tous ces projets. La durée d’apprentissage d’un nouveau développeur sur le projet est également beaucoup plus longue. Enfin, du côté devops, la gestion est devenue bien plus complexe.

Si pour Blablacar les avantages surpassent de loin les inconvénients, les deux intervenants nous enjoignent donc à réfléchir très sérieusement avant de choisir de faire évoluer son architecture.

Un dernier mot…

Je n’ai malheureusement pas pu présenter ici toutes les conférences tant cette édition fut riche en contenu. Je tiens à remercier ici toutes les personnes impliquées dans l’organisation de cet évènement, auquel je n’hésiterai pas à participer de nouveau l’année prochaine. Et si vous souhaitez discuter davantage de la conférence avec ceux qui étaient présents, vous les reconnaîtrez à ce signe distinctif : ils auront les yeux qui brillent en parlant du web !