Qu’est-ce que le pipeline d’actifs

BY admin
|

Objectifs

  1. Comprendre les 4 principales caractéristiques du pipeline d’actifs.
  2. Identifier les chemins d’actifs
  3. Savoir comment les manifestes d’actifs fournissent la concaténation de CSS et de JS.
  4. Utilisez des langages de prétraitement tels que SASS ou CoffeeScript
  5. Define Asset Fingerprinting

Outline

Pendant longtemps, nous avons traité JavaScript et CSS comme une réflexion après coup dans le développement d’applications Web. Tout notre code d’actifs — des éléments tels que des images, des feuilles de style et des JavaScripts — a été conservé dans un dossier massif appelé public et servi en dehors du contexte de notre application Rails. À mesure que le Web évoluait, cela n’avait plus de sens.

Le pipeline d’actifs est la réponse de Rails à la gestion des feuilles de style, des JavaScripts et des images.

Chemins d’actifs

Beaucoup de fichiers entrent dans la création d’applications Web. Les fichiers CSS et JavaScript seuls peuvent être difficiles à organiser. Quels dossiers créons-nous ? Quels fichiers vont où? Le pipeline d’actifs fournit une réponse à ce problème. Nous devons garder les choses très organisées dans notre application, mais, en gardant des fichiers et des dossiers séparés pour chaque concept ou unité de code, nous avons 2 problèmes.

  1. Comment Rails sait-il où se trouvent les choses? Le fichier JS du calendrier est-il en app/assets/javascripts/calendar.js ou vendor/javascripts/calendar.js?
  2. Nous ne voulons pas servir chaque fichier séparément car cela ralentira le chargement de notre page. Il est logique pour nous de conserver des petits fichiers séparés pour la lisibilité et l’organisation, mais, pour le navigateur, nous préférons écraser tous ces petits fichiers ensemble et charger 1 fichier JS et 1 fichier CSS. Ce processus est appelé concaténation.

Parlons de notre premier problème: comment les Rails savent-ils où chercher? Le pipeline d’actifs a un concept appelé Chemins d’actifs pour gérer cela. Tout comme dans BASH où nous avons une variable d’environnement PATH qui est une combinaison de chemins de dossiers, le chemin de l’actif est une combinaison de chemins de dossiers dans lesquels les Rails recherchent des actifs. Jetons un coup d’œil à un exemple de la configuration de notre chemin d’actifs.

Rails.application.config.assets.paths =>

Si nous mettons un actif dans l’un de ces dossiers, nous pouvons y accéder via l’URL ‘/assets’ dans notre application. Si vous avez des dossiers supplémentaires à rechercher pour Rails, vous pouvez ajouter les dossiers au chemin d’accès de l’actif. Cela se fait dans le fichier config/initializers/assets.rb.

Rails.application.config.assets.paths << "New Path"

Nous pouvons placer des actifs n’importe où, configurer notre chemin d’accès aux actifs et y accéder via une seule URL ‘/assets’.

Manifestes et concaténation

Maintenant que nous pouvons mettre des fichiers n’importe où, comment les faire inclure dans nos pages Web? Le pipeline d’actifs utilise un fichier manifeste pour indiquer à Rails quoi charger. Ce fichier manifeste est un emplacement central où nous pouvons lister tous les fichiers CSS et JS dont notre application a besoin. Ce n’est pas une fonctionnalité de JS ou CSS mais plutôt le pipeline d’actifs. Voici un exemple de ce à quoi ressemble notre fichier manifeste JS:

Fichier: app/assets/javascripts/application.js 

//= require jquery//= require calendar

Lorsque vous incluez le fichier manifeste dans votre mise en page avec le javascript_include_tag, le pipeline d’actifs recherchera tous les fichiers répertoriés dans le chemin d’accès à l’actif. Remarquez comment nous avons besoin de calendrier. Ce fichier vit dans app/assets/javascripts/calendar.js, mais nous n’avons spécifié que le nom et non le chemin complet. Le pipeline d’actifs recherchera tous les chemins configurés pour un fichier avec le nom que nous avons fourni.

Maintenant que nous avons résolu la question de la découvrabilité, parlons de la concaténation. Comme nous en avons discuté précédemment, nous ne voulons pas charger nos fichiers dans le navigateur un par un. Il vaut mieux effectuer un téléchargement qu’un tas de petits téléchargements à partir de notre navigateur. Les fichiers manifestes que nous configurons dans Rails concaténeront automatiquement les fichiers qui y sont répertoriés en un seul fichier en production. Ce n’est peut-être pas la meilleure option lorsque nous développons notre application car cela peut rendre le débogage difficile. Cependant, Rails servira en fait chaque fichier séparément lorsque nous fonctionnerons en mode développement. Pas besoin de faire quoi que ce soit.

Enfin, les directives de pignon qui alimentent nos manifestes d’actifs seront traitées en détail plus tard.

Prétraitement

La possibilité de combiner des fichiers et de les charger à partir d’un ensemble d’emplacements prédéfinis dans notre application est un grand avantage du pipeline d’actifs. Ce n’est que le début. Parce que nous chargeons des ressources via Rails, nous pouvons prétraiter les fichiers en utilisant des langages populaires comme SCSS pour écrire de meilleurs CSS et Coffeescript pour un JS plus propre. Si vous créez un actif nommé thème.CSS.SCSS, vous dites au pipeline d’actifs d’exécuter le fichier via le préprocesseur SCSS avant de servir le thème.css au navigateur. Le préprocesseur SCSS compile le fichier en CSS. La seule chose que nous devions faire était de fournir l’extension de fichier correcte, .scss, au fichier et le pipeline d’actifs sait l’exécuter via le préprocesseur SCSS.

Empreintes digitales

Le dernier avantage dont nous parlerons est l’empreinte digitale, mais parlons d’abord du problème qu’elle nous aide à résoudre. Lorsque nous servons des fichiers au navigateur, ils sont susceptibles d’être mis en cache pour éviter de les télécharger à nouveau à l’avenir. Qu’est-ce que la mise en cache vous pourriez demander?

Mettre en cache quelque chose signifie conserver localement une copie d’une opération fastidieuse afin que vous n’ayez pas à refaire l’opération coûteuse si les entrées et les sorties seront exactement les mêmes. Les caches sont généralement des magasins de valeurs clés, où la valeur est la réponse à l’opération coûteuse et la clé est quelque chose qui est unique à cet élément. Si vous demandez une page au serveur, puis que vous demandez à nouveau la même page au serveur, le moyen le plus rapide d’obtenir cette demande est de conserver une copie de ce que vous avez obtenu la dernière fois localement. Les navigateurs mettent en cache de nombreuses réponses qu’ils obtiennent aux demandes qu’ils ont faites en utilisant les en-têtes envoyés avec la réponse. Les en-têtes indiquent au navigateur combien de temps la page reste « fraîche » avant son « expiration ».’Une fois la page expirée, le navigateur fera une nouvelle demande pour que la page rafraîchisse son cache. Nous disons que la demande la plus rapide est celle qui n’est pas faite. On dit aussi souvent que l’invalidation du cache est l’un des deux problèmes difficiles en informatique, alors réfléchissez bien lorsque vous commencez à mettre en cache des choses! La mise en cache économise de la bande passante pour nous et augmente la vitesse pour l’utilisateur. C’est génial jusqu’à ce que vous changiez le fichier et que vous souhaitiez que tous vos utilisateurs obtiennent le nouveau au lieu de l’ancienne version qu’ils ont stockée dans le cache de leur navigateur. Mais comment faire savoir au navigateur que nous avons modifié le fichier? Si la nouvelle version porte le même nom que l’ancienne version, le navigateur continuera à utiliser l’ancien fichier de son cache. Nous avons besoin d’un moyen de changer le nom du fichier lorsque le contenu change afin que les navigateurs ne continuent pas à servir l’ancien fichier.

De l’amorce Rails Guides

« L’empreinte digitale est une technique qui rend le nom d’un nom de fichier dépendant du contenu du fichier. Lorsque le contenu du fichier change, le nom du fichier est également modifié. Pour le contenu statique ou rarement modifié, cela permet de savoir facilement si deux versions d’un fichier sont identiques, même sur des serveurs ou des dates de déploiement différents.

Lorsqu’un nom de fichier est unique et basé sur son contenu, les en-têtes HTTP peuvent être définis pour encourager les caches partout (que ce soit sur les CDN, chez les FAI, dans les équipements réseau ou dans les navigateurs Web) à conserver leur propre copie du contenu. Lorsque le contenu est mis à jour, l’empreinte digitale change. Cela obligera les clients distants à demander une nouvelle copie du contenu. C’est ce qu’on appelle la destruction du cache.

La technique utilisée par sprockets pour la prise d’empreintes digitales consiste à ajouter un hachage du contenu à la fin du nom de fichier. Par exemple, prenez un fichier CSS nommé global.css. Les pignons ajouteront le hachage 908e25f4bf641868d8683022a5b62f54 à la fin du nom de fichier comme ceci:

global-908e25f4bf641868d8683022a5b62f54.css

Si vous utilisez une ancienne version de Rails (Rails 2.x), la stratégie consistait à ajouter une chaîne de requête basée sur la date à chaque actif lié à un assistant intégré. Cela ressemblait à ceci:

global.css?1309495796

La stratégie de chaîne de requête présente plusieurs inconvénients:

  • Tous les caches ne mettent pas en cache de manière fiable le contenu où le nom de fichier ne diffère que par les paramètres de requête.
    • Steve Souders recommande « d’éviter une chaîne de requête pour les ressources pouvant être mises en cache. » 5 à 20% de vos demandes ne seront pas mises en cache. Les chaînes de requête en particulier ne fonctionnent pas du tout avec certains CDN pour l’invalidation du cache.
  • Le nom du fichier peut changer entre les nœuds dans les environnements multi-serveurs.
    • La chaîne de requête par défaut dans Rails 2.x est basé sur le temps de modification des fichiers. Lorsque des ressources sont déployées sur un cluster, il n’y a aucune garantie que les horodatages seront les mêmes, ce qui entraîne l’utilisation de valeurs différentes en fonction du serveur qui gère la demande.
  • Trop d’invalidation du cache.
    • Lorsque des actifs statiques sont déployés à chaque nouvelle version de code, le mtime (heure de la dernière modification) de tous ces fichiers change, forçant tous les clients distants à les récupérer à nouveau, même si le contenu de ces actifs n’a pas changé.

L’empreinte digitale résout tous ces problèmes en veillant à ce que les noms de fichiers soient cohérents en fonction de leur contenu.

L’empreinte digitale est activée par défaut pour la production et désactivée pour tous les autres environnements. Vous pouvez l’activer ou le désactiver dans votre configuration via l’option config.assets.digest. »

Conclusion

Le pipeline d’actifs est nettement plus complexe que de simplement servir des actifs à partir d’un dossier public et il peut être difficile à déboguer. Apprendre à l’utiliser sera payant à long terme en nous faisant gagner du temps et des maux de tête. Il suffit de penser à tous les problèmes qu’il résout pour nous.

  1. Chemins d’actifs
  2. Manifestes et concaténation
  3. Prétraitement
  4. Empreintes digitales

Enfin, consultez définitivement la keynote où DHH introduit le pipeline d’actifs.