Salut !

Aller pour le moment je vais vous laisser respirer loin des tutoriels sur Firebase. Changeons de sujet (mais pas trop non plus). Le 6 Juin 2018 est arrivée la version 10.5.0 de NodeJS et avec un module plutôt interessant : les Worker Threads. Maintenant que le module est stable (depuis la v12 LTS de la fin d’année 2019), je souhaiterais revenir dessus afin d’expliquer un peu le pourquoi du comment et éclairer sur cette bizarrerie les personnes n’ayant pas encore eu l’occasion ou le temps de s’y interesser.

Javascript et son thread "forever alone"

Avant d’entamer les Worker Threads, revenons tranquillement quelques années en arrière lors de la conception et l’avènement du Javascript. Nous sommes en décembre 1995 lorsque Sun Microsystem et Netscape annoncent le langage officiellement. D’ailleurs juste pour la culture personnelle, Javascript s’appelait à la base LiveScript mais comme Sun Microsystem et Netscape étaient partenaires et que La JVM de Sun Microsystem était de plus en plus populaire, les deux gaillards ont décidé de changer le nom en Javascript.

Bref, le Javascript a été conçu pour rendre à l’époque les pages web du navigateur dynamiques et faire de la validation de formulaires. On clique sur un bouton, il se passe des trucs. On scroll, une animation se déclenche et j’en passe. En fait, rien de suffisament méchant pour qu’il y ait besoin de concevoir un langage multithreadé avec toute la complexité que cela implique. Donc le JS fût développé comme un langage de programmation mono-threadé. Cela veut dire qu’une instruction à la fois s’éxécute sur le même processus.

Jusque là, le Javascript était tout de même peu populaire et vu comme un langage brouillon, un peu batard, sans avenir, sous la pluie, seul. Pour cause, niveau performance ce n’était vraiment pas la folie. Cela a duré jusqu’en 2008 quand Google a sorti le moteur V8 (non cher lecteur, pas comme celui de Clément Ader en 1903. Celui là n’avait que 24ch) directement câblé dans Google Chrome, tout nouveau à l’époque.

Pour expliquer de manière brève, le V8 utilise la compilation Just-In-Time en compilant le Javascript en Assembleur au moment de l’éxécution. Cela a fait littéralement exploser les performances du Javascript et par conséquent permis l’apparition des navigateurs web modernes, bien plus puissants qu’à l’origine. Grâce à cela, non seulement la popularité du Javascript est montée de manière exponentielle mais on a vu apparaître des technologies comme NodeJS.

D’ailleurs le but de Ryan Dahl (créateur de NodeJS) était d’implémenter une plateforme basée sur l’asynchrone. Par conséquent, il n’y avait pas besoin de plusieurs threads. Le souci du mono-threading étant le partage mémoire pouvant causer de gros problèmes liés aux accès concurrentiels.

NodeJS étant la plateforme évenementielle Javascript, il est basé sur une architecture non bloquante. Node va donc invoquer les fonctions sans bloquer l’exécution du reste du code. Via la callback, Node est averti que le job est terminé en revoie le résultat. Comme Javascript est rapide et que les tâches ne sont jamais très importantes et en général bien découpées, nous ne remarquons pas la différence.

…sauf quand il s’agit d’une tâche intensive synchrone. Là Node commence à ramer et tout le code se bloque. Pour l’exemple extrême, essayez donc de lancer un while(true) {} dans un script JS. Tout le navigateur tire la tronche. En fait non, n’essayez pas ça à la maison…

On pourrait plus concrètement imaginer un retour de requêtage en base de données qu’il y a besoin de hautement chiffrer/déchiffrer avant de l’utiliser dans l’application. Donc dans le .then({ /**...**/ }) de la promesse, on écrit la série d’instructions permettant de chiffrer/déchiffrer ces données. Nous sommes alors face à un code procédural lourd à la place des bouts de code en général suffisament léger et rapide à exécuter. Dans tous les cas, voilà un exemple qui pourrait occuper le mono-thread de Javascript pour un certain temps, empêchant toute autre instruction d’être prise en charge.

Bref, la popularité de Node ne cesse de grandir, beaucoup d’entreprises commencent à migrer vers cette plateforme et évidemment peuvent rencontrer des problèmes avec ce satané mono-thread.

Et là paf ! Les Worker Threads, on fait du multi-threading en NodeJS c’est cool non ?

Ça n'existait pas déjà ?

Si, mais c’était pas aussi bien. Chapitre suivant.

Ce n’est pas un argument ? Bon, bien sûr qu’il existait déjà différentes solutions afin de palier à ce problème. Notez cependant qu’il s’agit en général de solutions pas entièrement satisfaisantes.

Utiliser par exemple setImmediate(callback) afin de spécifier à Node qu’il peut continuer directement à prendre en charge ce qui est présent de sa queue d’exécution, cela complique très vite les algorithmes et rend le code de moins en moins maintenable au fil de l’écriture et des évolutions.

De la même façon, il est possible de fork le processus. Cependant un fork est particulièrement gourmand en ressources. Ce n’est pas une solution viable à long terme, sans parler de la perte massive en performances.

Enfin il y a le module cluster. Le concept peut encore une fois paraître similaire. En réalité ce module crée plusieurs instances de Node (donc plusieurs processus) avec un processus principal à leur tête servant un peu de routeur pour les requêtes entrantes. Cela permet d’améliorer les performances en effet et de soulager le serveur. Cependant, il ne s’agit pas de multi-threading, vu que chaque processus possède un unique thread dans ce cas-ci. De plus, encore une fois, il n’y a pas de partage mémoire.

Ces solutions (pour ne pas toutes les citer) ne se rapprochent pas de l’ensemble des avantages du multi-threading. Typiquement, les Workers Threads restent plus léger à l’utilisation, partagent le même processus et leur mémoire. Bref du vrai multi-threading.

Les Worker Threads

Si je parle de tâches intensives depuis tout à l’heure, c’est parce que la documentation de NodeJS précise que

Workers (threads) are useful for performing CPU-intensive JavaScript operations.

Documentation officielle

Du coup quelle est la différence ?

A la base l’utilisation de NodeJS s’effectue via un seul processus disposant d’un thread forever alone, on l’a vu plus haut. Ensuite tout est mono instancié. Une instance du moteur V8 (avec libuv pour gérer l’asynchrone) est pris en charge par une unique event loop sur une unique instance de NodeJS.

Okay. Imaginons maintenant que les Worker Threads permettent d’accèder à plusieurs threads. Bien évidemment, tous ces threads sont sur le même processus. Chaque thread possède alors son instance de V8 couplé à libuv et sa propre event loop. Le tout fonctionnant sur une instance de NodeJS. Donc on aura une instance de NodeJS par threads.

Cependant, les-dits threads ne sont pas cloisonnés pour autant puisque le module permet de gérer les accès concurrentiels du code sur les threads.

Aller un schéma vaut mille mots :

Source : The NodeSourceBlog

Et cela donne quoi concrètement ?

Concrètement lorsque l’on déclare un nouveau thread dans le code, on l’associe avec un script JS “isolé” censé exécuter le traitement lourd. Vu comme ça, on pourrait presque comparer avec le fonctionnement d’une Cloud Function.

Mais niveau code voilà ce que ça donne :

index.js

const { Worker } = require('worker_threads')

/** 
* Crée un worker
* @param file On donne à l'objet Worker le chemin d'accès au fichier contenant la tâche à exécuter en parallèle.
*/
function executeWorker (file) {
  return new Promise((resolve, reject) => {
    const worker = new Worker(file)

    // Une fois le worker actif
    worker.on('online', () => { 
      console.log('DEBUT : Execution de la tâche intensive en parallèle') 
    })

    // Si un message est reçu du worker
    worker.on('message', workerMessage => {
      console.log(workerMessage)
      return resolve
    })

    worker.on('error', reject)
    worker.on('exit', code => {
      if (code !== 0) {
        reject(new Error(`Worker stopped with exit code ${code}`))
      }
    })
  })
}

/**
 * Le main écrit dans la console
 */
async function prog () {

  // Tâche principale
  setInterval( () => { console.log('Tâche principale: la tâche en parallèle peut s\'exécuter') }, 1000)

  // Tâche en parallèle
  await executeWorker('./worker.js')
}

prog()

worker.js

const { parentPort } = require('worker_threads')

let count = 0
for (let i = 0; i < 10000000000; i++) {
  count += 1
}
console.log(`FIN: ${count}`)
const message = `Tâche intensive terminée, total : ${count}`

// On renvoie un message depuis le worker récupérer lors du worker.on('message'...)
parentPort.postMessage(message)

Et voilà ! Nous avons bien ici un unique processus mais deux threads bien séparés.

Conclusion

Ce nouveau module de l’API de Node semble vraiment pratique et plutôt puissant mais il est peut être un peu tôt pour dire si oui ou non cela sera une feature incontournable de Node.

Les Worker Threads permettent d’installer du multi-threading assez facilement sous Node et ainsi de largement améliorer les performances CPU de la plateforme. Nous pouvons à priori imaginer une ouverture prochaine de NodeJS dans des domaines demandant de la performance CPU comme l’intelligence artificielle par exemple.

Pour donner mon avis personnel, je trouverais super que la plateforme s’ouvre à de nouvelles utilisations mais je souhaite contraster un peu cela. Il faut noter qu’ils ne font pas de miracles particuliers. Le blog NodeSource précise lui même que :

• Don’t think Workers make everything magically faster, in some cases is better to use Worker pool
• Don’t use Workers for parallelizing I/O operations.
• Don’t think spawning Workers is cheap

Il n’y a donc pas de magie. Il reste à considérer l’arrivée (éventuelle) de Deno qui, si il continue sur sa lancée, pourrait peut être compléter voir remplacer NodeJS. Le débat est ouvert, à creuser.

Sur ce il est déjà temps de vous laisser. J’espère que cet article vous aura plu !

Happy coding !

Bien à vous,

Pophip

Bonjour à tous,

Je vous propose un petit tuto, on aime bien les petits tutos mais avant de commencer je vais le remettre dans son contexte initial.

Dans un précédent article posté sur le site lesveilleursdenuit.fr, je parlais de faire un projet perso pour sortir la tête de l’eau ? Eh bien oui, j’en ai lancé un et m’y suis cassé les dents (dans le sens positif du terme).

Outre la montée en compétence significative que cela m’a offert, je me suis surtout rendu compte d’une chose: il est définitivement essentiel de définir et redéfinir son besoin exact pour pouvoir choisir l’environnement technique. Etre capable de mettre au propre votre concept et le CDC fonctionnel de votre application est déjà un travail assez long et rigoureux. La partie technique elle…demande autre chose : être clairvoyant et prévoyant, voir sur le long terme.

C’est-à-dire Pophip ? C’est à dire que les technos nous réservent souvent des surprises. Elles ont des limites, des spécificités plus ou moins adaptées à vos problématiques. En tant que dev l’envie nous vient souvent d’utiliser une techno par curiosité, par interêt ou parce qu’on nous l’a fortement conseillée. Nous devrions choisir une technologie parce qu’elle correspond à ce dont on a besoin considérant également le contexte et la maintenabilité.

C’est comme ça que je me suis retrouvé avec un environnement technique applicatif trop puissant limite usine à gaz, et un ORM à l’état embryonnaire. Joli combo qui m’a valu quelques mois de : “j’en ai marre de c’te projet”.

De manière plus explicite : j’ai lancé un projet avec Nuxt.js en front et du Sails.js en back. Le tout relié à une base MongoDB et hébergé pour 7 balles le mois sous Heroku.

Nuxt c’est cool. C’est un framework SSR (Server Side Rendering) construit sur VueJS, rapide, pratique, efficace. Je ferai sûrement un article rien que pour ses beaux yeux. Je ne peux que vous conseillez d’au moins y jeter un oeil.

Sails c’est… c’est pas si mal. Si vous ne connaissez pas je vous invite à également voir leur site web.

C’est un framework NodeJS MVC (modèle vue contrôleur) inspiré de Rails (en ruby tout ça…) et qui a adopté le principe de “convention plutôt que configuration” (le fameux convention over configuration). Il permet de créer assez rapidement des APIs REST, des Single Page Applications et des applications en temps réel. Globalement il aide le développeur à écrire moins de code, et je reconnais qu’il est plutôt pratique.

Mais alors, quel est le problème ?

Le problème est que Sails a une documentation lacunaire, une communauté assez restreinte et un ORM suffisament à l’état d’embryon pour ne pas prendre en charge le deep populate. En se baladant sur le web on nous conseille de changer d’ORM, d’importer 36 libs bref on nous conseille de changer de techno.

À cela se rajoute la question de la pertinence de l’introduction de la philosophie Ruby sur du Javascript. Ce ne sont pas les mêmes modes de pensée.

De plus, je ne trouve pas normal qu’un framework back ait 3 failles critiques de sécurité (du genre injection de code en plus) à l’audit de npm sans chercher à les corriger.

Pour finir j’ai trouvé ironique que IBM développant LoopBack (donc concurrent à Sails) ait écrit une meilleur documentation sur Sails que… Sails.

On passe donc plus de temps à chercher de la documentation qu’à l’appliquer, c’est dommage pour un framework au final très bien construit. Pour aller un peu plus loin, je vous redirige vers un article traitant des soucis de sails plus en profondeur. Certes il date de 2015, mais il faut (vraiment) croire que les problématiques du framework restent globalement les mêmes (#balancetonframework).

L’autre problème vient de moi. J’étais curieux de découvrir un Ruby on Rails version JavaScript, je voulais absolument avoir un back pour au final une application qui ne faisait qu’un CRUD assez simple sans intégration particulière de systèmes externes. J’ai ainsi mal étudié mon besoin technique, je me suis mal renseigné sur mon cheval de bataille tout ça pour l’attrait que la technologie avait et le fait qu’il y a quelques temps c’était on the wave. Pophip, la tête de turque qui veut toujours faire du Rock’n Roll hein… On ne m’y reprendra plus.

Revenons à nos moutons

Quoi qu’il en soit, je me suis petit à petit retrouvé freiné à cause de l’ORM Waterline et frustré d’avoir l’impression de passer beaucoup de temps sur Sails pour pas grand chose en plus d’avoir un back à sécuriser.

Tout ça pour dire que suivant ton expérience dans le monde du dev tu apprends petit à petit à non seulement élaborer un concept fonctionnel selon un besoin mais également à choisir correctement un environnement technique. J’entends par “correctement” le terme adapté. C’est à mon sens particulièrement important pour mener à bien un projet avec en tête la pérénisation du produit.

Cela m’amène au sujet du tutoriel qui va suivre. Il n’est plus nécessaire de rappeler l’importance du Search Engine Optimisation (SEO) visant à optimiser la visibilité d’une page web dans les résultats de recherches. De son côté le SSR permet une meilleure indexation SEO. Et ô joie nous disposons grâce aux Chopin brothers de Nuxt.js fait pour ça et restant un framework intuitif et agréable malgré la complexité plus poussée d’un développement en SSR.

Mais qui dit SSR dit il est où le serveur ? Je prends quoi comme back ? Sails ? Nest ? Juste un Express ? Et si… et si il y avait plus simple ? Je fais un CRUD relativement standard donc je pourrais penser serverless. En plus j’aimerais centraliser les web services.

Là, Firebase entre en jeu.

Firebase est une plate-forme de développement d’applications mobiles et Web qui fournit aux développeurs une pléthore d’outils et de services pour les aider à développer des applications de haute qualité, à élargir leur base d’utilisateurs et à générer davantage de profits. Source - M.Chenot - 2018

Je vous propose de cliquer sur les deux liens ci-dessus si vous souhaitez en savoir plus sur Firebase.

Reprenons.

Techniquement il est possible de ne faire que du Vue au lieu de Nuxt mais on a dit que l’on veut du SSR. Donc non seulement je peux utiliser Firebase Hosting pour l’hébergement, Firebase Auth pour la gestion des utilisateurs et Firestore pour la base de données mais je peux également profiter des Cloud Functions for Firebase pour ce qui est du SSR.

On fait les comptes :

Suppression du backend
Centraliser la plupart des web services en un seul ainsi que la BDD
Déploiement au CLI en une ligne de commande
Cloud function pour le SSR
Scale automatique
Serverless
Meilleure indexation (SEO)
Les qualités de Nuxt en matière d’application (SPA, PWA etc…)
Hébergement gratuit
Cela me semble vraiment pas trop mal cette fois comme choix. Maintenant la question c’est: comment va-t-on s’y prendre pour mettre tout cela en place ?

Je vous donne donc maintenant rendez-vous dans la partie 2 pour voir comment on va pouvoir déployer une application SSR Nuxt sous Firebase.

On est d’accord c’est une grosse introduction, mais cela me tient à coeur de montrer un chemin de pensée qui mènerait à revoir son environnement technologique voir son infrastructure.

Bien à vous,