Le livre «Développement Web avec Node et Express. Utilisation complète de la pile JavaScript. 2e édition "

Bonjour les Habitants! Créez des applications Web dynamiques à l'aide d'Express, un composant clé de la pile de développement Node / JavaScript. Ethan Brown décrit comment travailler avec Express 5 en créant une application complète. Le livre couvre toutes les étapes et tous les composants - du rendu du serveur au développement d'API pour travailler avec des applications à page unique (SPA). Express est le juste milieu entre un cadre bien établi et aucun cadre du tout, il vous laisse donc une certaine liberté dans vos choix architecturaux. Ce livre fournira les meilleures solutions pour les développeurs front-end et back-end utilisant Express. Apprenez à regarder le développement Web sous un nouvel angle! - Créez un système de modèles pour afficher des données dynamiques. En savoir plus sur les objets de demande et de réponse, le middleware et le routage d'URL.- Créez une simulation de l'environnement de production et testez-y. - Apprenez le stockage à long terme des informations dans les bases de données de documents à l'aide de MongoDB et dans les bases de données relationnelles à l'aide de PostgreSQL. - Partagez vos ressources avec d'autres programmes grâce à l'API. - Créez des applications sécurisées en utilisant l'authentification, l'autorisation et HTTPS. - Intégrez-vous aux réseaux sociaux, activez la géolocalisation et bien plus encore. - Mettre en place un plan pour lancer et maintenir votre application. - Maîtrisez les compétences de débogage critiques.- Créez des applications sécurisées en utilisant l'authentification, l'autorisation et HTTPS. - Intégrez-vous aux réseaux sociaux, activez la géolocalisation et bien plus encore. - Mettre en place un plan pour lancer et maintenir votre application. - Maîtrisez les compétences de débogage critiques.- Créez des applications sécurisées en utilisant l'authentification, l'autorisation et HTTPS. - Intégrez-vous aux réseaux sociaux, activez la géolocalisation et bien plus encore. - Mettre en place un plan pour lancer et maintenir votre application. - Maîtrisez les compétences de débogage critiques.

Réseaux de diffusion de contenu

Lorsque vous mettez votre site en production, les actifs statiques doivent être téléchargés quelque part sur Internet. Vous pouvez avoir l'habitude de les mettre sur le même serveur où tout votre HTML dynamique est généré. Jusqu'à présent, notre exemple a également utilisé cette approche: le serveur Node / Express, lancé par la commande node meadowlark.js, sert à la fois toutes sortes de ressources HTML et statiques. Cependant, si vous souhaitez optimiser les performances de votre site (ou le conserver à l'avenir), vous aurez besoin de la capacité d'héberger des ressources statiques sur un réseau de diffusion de contenu (CDN). CDN est un serveur optimisé pour fournir des ressources statiques. Il utilise des en-têtes spéciaux (sur lesquels nous en apprendrons plus tard) qui permettent la mise en cache du navigateur.



De plus, un CDN peut inclure une optimisation géographique (souvent appelée mise en cache périphérique), ce qui signifie que le contenu statique sera fourni à partir du serveur le plus proche de votre client. Bien qu'Internet soit très rapide (bien sûr, il ne fonctionne pas à la vitesse de la lumière, mais à proximité), les données seront livrées encore plus rapidement à une distance de centaines de kilomètres que de milliers. Le gain de temps est insignifiant dans chaque cas individuel, mais multiplié par le nombre d'utilisateurs, de demandes et de ressources, il devient rapidement impressionnant.



La plupart de vos ressources statiques seront référencées dans les vues HTML

 <link>   CSS-, <script> —   JavaScript,  <img>    ,      
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Il est courant d'avoir des liens statiques en CSS, généralement dans la propriété background-image. Enfin, les ressources statiques sont parfois référencées en JavaScript, par exemple le code JavaScript peut dynamiquement modifier ou insérer des balises.

<img>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

ou les propriétés de l'image d'arrière-plan.

Ne vous inquiétez pas du partage de ressources interdomaines (CORS) lorsque vous utilisez un CDN. Les ressources externes chargées en HTML ne sont pas soumises aux règles CORS: il suffit d'activer CORS pour les ressources chargées via Ajax (voir chapitre 15).

Conception d'un CDN La



façon dont vous utilisez un CDN dépend de l'architecture de votre site. La plupart des réseaux de diffusion de contenu vous permettent de définir des règles de routage pour déterminer où envoyer les demandes entrantes. Bien que vous puissiez définir des règles de routage assez complexes, cela se résume généralement à l'envoi de demandes de ressources statiques à un emplacement (généralement fourni par votre CDN) et de demandes de points de terminaison dynamiques (pages dynamiques ou points de terminaison d'API) à un autre.



Le choix et la configuration d'un CDN est un vaste sujet que je ne traiterai pas ici, mais je vais vous donner quelques informations de base pour vous aider à configurer votre CDN de choix.



L'approche la plus simple pour structurer votre application consiste à distinguer facilement les ressources dynamiques et statiques. Cela gardera vos règles de routage CDN aussi simples que possible. Bien que cela puisse être réalisé à l'aide de sous-domaines (par exemple, les ressources dynamiques sont servies à partir de meadowlark.com et les ressources statiques à partir de static.meadowlark.com), cette approche ajoute une complexité supplémentaire et complique le développement local. Un moyen plus simple est d'utiliser des chemins de requête: par exemple, tout ce qui commence par / public / est des ressources statiques, et tout le reste est dynamique. L'approche peut être différente si vous générez du contenu avec Express ou si vous utilisez Express pour fournir une API pour une application d'une seule page.



Site Web de rendu côté serveur



Si vous utilisez Express pour rendre du HTML dynamique (en d'autres termes, tout ce qui commence par / static /) est des ressources statiques, et tout le reste est dynamique. Avec cette approche, toutes vos URL (générées dynamiquement) seront telles que vous le souhaitez (à moins qu'elles ne commencent par / static /, bien sûr!), Et toutes vos ressources statiques seront préfixées par / static /:

<img src="/static/img/meadowlark-logo-1.png" alt="Meadowlark Logo">
   <a href="/about">Meadowlark Travel</a>.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Jusqu'à présent, dans ce livre, nous avons utilisé un middleware statique, comme si toutes les ressources statiques étaient disposées dans le répertoire racine. Ainsi, en plaçant la ressource statique foo.png dans le dossier public, nous y faisons référence au chemin de l'URL /foo.png, et non à /static/foo.png. Bien sûr, il est possible de créer un sous-répertoire statique dans le répertoire public existant et l'URL de /public/static/foo.png sera /static/foo.png, mais ce n'est pas très intelligent. Heureusement, le middleware statique nous permet d'éviter cela en spécifiant un chemin différent lors de l'appel de app.use:

app.use('/static', express.static('public'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Désormais, dans l'environnement de développement, nous pouvons utiliser la même structure d'URL que dans l'exploitation. Si le contenu du dossier public et du CDN est synchronisé, vous pouvez référencer des ressources statiques aux deux endroits et basculer de manière transparente entre le développement et la production.



Lors de la configuration du routage pour le CDN (vous devrez vous reporter à votre documentation CDN), le routage ressemblera à ceci.





Applications à page unique Les applications



à page unique sont généralement le contraire des sites Web rendus côté serveur: seule l'API sera transmise au serveur (par exemple, toute requête commençant par / api), tout le reste est passé au stockage de fichiers statiques.



Au chapitre 16, vous avez vu que vous pouvez créer un assembly pour faire fonctionner votre application qui inclura toutes les ressources statiques chargées dans le CDN. Ensuite, vous devez simplement vous assurer que la configuration de votre routage API est correcte. De cette façon, vous aurez le routage suivant.





Maintenant que nous avons appris à structurer une application pour une transition transparente du développement à la production, voyons ce qui se passe réellement dans la mise en cache et comment elle optimise les performances.



Mise en cache des ressources statiques



Que vous utilisiez Express ou CDN pour servir des ressources statiques, il vaut la peine de comprendre les en-têtes de requête HTTP que le navigateur utilise pour déterminer quand et comment mettre en cache les ressources statiques.



- Expire / Cache-Control. Ces deux en-têtes indiquent à votre navigateur la durée maximale pendant laquelle une ressource peut être mise en cache. Le navigateur les prend au sérieux: s'il lui dit de stocker quelque chose pendant un mois, il ne le téléchargera tout simplement pas pendant un mois, tant qu'il reste dans le cache. Il est important de comprendre que le navigateur peut supprimer une image du cache avant la date d'expiration pour des raisons que vous ne pouvez pas contrôler. Par exemple, l'utilisateur peut vider manuellement le cache ou le navigateur peut supprimer votre ressource pour faire de la place pour les ressources que l'utilisateur visite plus souvent. Vous n'avez besoin que d'un de ces en-têtes. Expires est plus largement pris en charge, il est donc préférable de l'utiliser. Si la ressource est dans le cache et n’a pas encore expiré,le navigateur n'exécutera pas du tout la demande GET, ce qui améliorera les performances, en particulier sur les appareils mobiles.



- Dernière modification / ETag. Fournissez une sorte de contrôle de version: si le navigateur a besoin d'extraire une ressource, il vérifiera ces balises avant de charger le contenu. La requête GET adressée au serveur sera toujours exécutée, mais si les valeurs renvoyées dans ces en-têtes démontrent au navigateur que la ressource n'a pas changé, le navigateur ne procèdera pas au téléchargement du fichier. Comme son nom l'indique, Last-Modified vous permet de définir la date de la dernière modification d'un actif. ETag vous permet d'utiliser une chaîne arbitraire, généralement une chaîne de version ou un hachage de contenu.



Lors de l'émission de ressources statiques, utilisez l'en-tête Expires et Last-Modified ou ETag. Le middleware statique intégré d'Express installe Cache-Control, mais ne traite ni Last-Modified ni ETag. Par conséquent, il convient au développement, mais pas au fonctionnement.



Si vous choisissez d'héberger vos ressources statiques sur un CDN, tel qu'Amazon CloudFront, Microsoft Azure, Fastly, Cloudflare, Akamai ou StackPath, vous obtenez un bonus: la plupart de ces détails seront traités pour vous. Vous pourrez effectuer des réglages fins, bien que les paramètres par défaut de l'un de ces services conviennent également.



Modifier le contenu statique



La mise en cache améliore considérablement les performances de votre site, mais non sans conséquences. En particulier, si l'une des ressources statiques change, les clients peuvent ne pas voir la modification tant que les versions mises en cache du navigateur n'ont pas expiré. Google recommande la mise en cache pendant un mois, de préférence un an. Imaginez un utilisateur qui visite votre site tous les jours via le même navigateur: il ne peut voir vos mises à jour qu'au bout d'un an!



Évidemment, ce n'est pas une situation souhaitable, mais vous ne pouvez pas dire à vos utilisateurs de vider le cache. La solution à ce problème consiste à désactiver le contournement du cache. Cette astuce vous donnera le contrôle sur le moment où le navigateur doit recharger la ressource. Cette méthode ajoute simplement des informations de version au nom du fichier. Lorsque vous mettez à jour une ressource, le nom de la ressource change et le navigateur sait la télécharger. En général, cela revient à contrôler les versions de la ressource (main.2.css ou main.css? Version = 2) ou à ajouter une sorte de hachage (main.e16b7e149dccfcc399e025e0c454bf77.css). Quelle que soit la méthode que vous utilisez, lorsque vous mettez à jour une ressource, son nom change et le navigateur sait la charger.



Vous pouvez faire de même avec les ressources multimédias. Prenons notre logo (/static/img/meadowlark_logo.png). Si nous le mettons sur un CDN pour maximiser les performances en définissant la période de rétention sur un an, puis en modifiant le logo, les utilisateurs risquent de ne pas voir le changement pendant un an. Cependant, si nous renommons le logo en /static/img/meadowlark_logo-1.png et reflétons ce changement dans le HTML, le navigateur devra le télécharger car il semble être une nouvelle ressource.



Si vous avez opté pour un framework d'application à page unique tel que create-react-app ou similaire, alors au stade de la construction, un assemblage de ressources prêtes à l'emploi sera créé avec des hachages ajoutés.



Si vous partez de zéro, vous voudrez probablement jeter un coup d'œil aux constructeurs (c'est ce qui se cache sous le capot des frameworks d'application d'une seule page). JavaScript, CSS et certains autres types de ressources statiques seront regroupés dans le moins d'assemblages possible et le résultat sera minimisé autant que possible. La personnalisation de build est un vaste sujet, mais heureusement, il y a beaucoup de bonne documentation à ce sujet. Voici les collectionneurs les plus populaires actuellement disponibles.



- Webpack (https://webpack.js.org/). L'un des premiers collectionneurs à réaliser de réels progrès. Il a encore de nombreux supporters. C'est très complexe et il y a un prix à payer pour cette complexité: la courbe d'apprentissage est raide. Cependant, ce packer est bon pour apprendre les bases.



- Colis (https://parceljs.org/). Apparu récemment et fait beaucoup de bruit. Il est extrêmement bien documenté, très rapide et, surtout, il a la courbe d'apprentissage la plus courte. Il convient si vous avez besoin de faire le travail rapidement et sans tracas.



- Rollup (https://rollupjs.org/). Il se situe quelque part entre Webpack et Parcel. Comme Webpack, il est robuste et riche en fonctionnalités. Il est cependant plus facile de démarrer que Webpack, mais pas aussi simple que Parcel.



Résumé



Malgré toute sa simplicité apparente, les ressources statiques sont très fastidieuses. Cependant, ils constituent l'essentiel des données transmises à vos visiteurs, de sorte que le temps passé à les optimiser sera rentable avec intérêt.



Une solution viable pour les ressources statiques, non mentionnée précédemment, consiste à exposer les ressources statiques à un CDN et à toujours utiliser l'URL complète de la ressource dans les vues et CSS. Cette approche a l'avantage d'être très simple, mais si jamais vous souhaitez organiser un hackathon d'une semaine dans une cabane forestière sans accès Internet, vous avez des ennuis!



L'assemblage et la minification soignés sont un autre domaine dans lequel vous pouvez gagner du temps si les gains de performances de votre application ne justifient pas l'effort. En particulier, si vous n'avez qu'un ou deux fichiers JavaScript sur votre site et que tout le CSS est dans le même fichier, vous pouvez ignorer complètement la construction, mais les applications du monde réel ont tendance à se développer avec le temps.



Quelle que soit la méthode que vous choisissez pour servir les ressources statiques, je vous conseille de les télécharger séparément, de préférence sur un CDN. S'il vous semble que c'est gênant, je vous assure: ce n'est pas du tout aussi difficile qu'il y paraît. Surtout si vous passez un peu de temps sur le système de déploiement au préalable afin que le déploiement des ressources statiques vers un emplacement et des applications vers un autre soit automatique.



Si vous êtes préoccupé par le coût de l'hébergement sur un CDN, je vous exhorte à jeter un œil aux montants que vous payez actuellement pour l'hébergement. La plupart des fournisseurs d'hébergement facturent beaucoup d'argent pour le trafic, même si vous ne le savez pas. Cependant, si soudainement votre site est répertorié sur Slashdot et que vous ressentez l'effet slashdot, vous pouvez recevoir une facture d'hébergement totalement inattendue. L'hébergement CDN est généralement configuré de telle manière que vous ne payez que ce que vous utilisez. Par exemple, le site que je dirige pour une entreprise de taille moyenne locale utilise environ 20 Go de trafic par mois, tandis que les frais d'hébergement statique (qui est un site très médiatique) ne sont que de quelques dollars par mois.



Les avantages de mettre des ressources statiques sur un CDN sont substantiels, et le coût et les inconvénients de le faire sont minimes, donc je vous conseille vivement de choisir cette voie.



Avec certaines astuces JavaScript dans le navigateur, vous pouvez utiliser LESS non compilé. Cependant, cette approche peut entraîner des conséquences négatives en termes de performances, je ne recommande donc pas de l'utiliser.



Plus de détails sur le livre peuvent être trouvés sur le site de la maison d'édition

» Table des matières

» Extrait



Pour Habitants une réduction de 25% sur le coupon - JavaScript



Lors du paiement de la version papier du livre, un e-book est envoyé par e- courrier.