Réduction de l’utilisation de la CPU sur un serveur nodejs

Merci de partager cet article – il est excellent (et très opportun pour moi).

Vous posez en fait deux questions: 1) comment charger des données pour rendre le côté client html sans interaction client et 2) comment envoyer un fichier statique à un navigateur lorsque l’utilisateur demande réellement un itinéraire.

Rendu de la page sans interaction de l’utilisateur et de mon ¢ 2 sur le client MVC

1) Vous devez exécuter tout le code d’initialisation / chargement de données / rendu pour restituer la page après le chargement de la page. Si vous utilisez jQuery dans le client (comme le font la plupart des applications Web):

$(document).ready(function(){ // Your code here }); 

Il vient d’être copié à partir de la documentation jQuery .

La plupart des gens utilisent backbone / underscore pour construire la couche MVC dans le client. Bien qu’il y ait beaucoup de frameworks côté client beaucoup plus sophistiqués (et apparemment plus puissants) à faire, ce couple vous donne juste assez de puissance sans limiter vos options ni réduire votre flexibilité dont vous aurez certainement besoin à un moment donné. Underscore (qui est de toute façon une dépendance du backbone), en plus de nombreuses fonctions très utiles (vous serez étonné du potentiel de JavaScript si vous passez une heure à lire tout le manuel d’une page) a ses propres modèles qui sont trompeusement simples et identiques. temps extrêmement puissant car ils exécutent tout le javascript à l’intérieur des modèles.

Bien que la logique de l’application dans les modèles soit généralement une mauvaise chose (contrairement aux moteurs de gabarit les plus sophistiqués et “les plus puissants”, le soulignement le permet), il est souvent très pratique et bien préférable d’append de la logique dans le modèle. Lorsque vous vous trouvez vous-même dans un coin restreint (comme vous le ferez souvent), vous devez redéfinir beaucoup de logique d’application ou append des modèles supplémentaires.

De plus, mon opinion est d’éviter d’utiliser require.js ou tout autre chargeur de module (jusqu’à ce que vous deviez vraiment les utiliser) comme je l’ai écrit ici .

Servir du HTML statique pour n’importe quelle route et nginx config pour node-as-api

2) Vous devez réécrire les demandes sur toutes les routes pour répondre avec le même fichier HTML statique (ou plusieurs fichiers HTML dépendant de la route). Selon vos préférences ou les exigences de l’application, il peut s’agir d’un fichier avec un corps vide (auquel cas les utilisateurs verront une page vierge jusqu’à ce que vos données soient chargées et la page rendue / insérée dans le corps), une page d’accueil ou même un modèle de page. au lieu de données, une roue en rotation est affichée.

La façon dont vous réécrivez les demandes dépend du serveur Web que vous utilisez pour gérer le contenu statique et les demandes proxy. Si vous utilisez Apache (un choix peu probable avec Node, car il est synchrone), vous devez utiliser des fichiers .htaccess. Si vous utilisez Nginx comme le font la plupart des utilisateurs de noeud, vous devez utiliser la directive rewrite à l’intérieur du bloc de serveur dans le fichier de configuration, comme dans l’exemple ci-dessous:

 server { listen 80; server_name example.com; root html/example; access_log logs/example.log; # location block below sends specific static assets from inside your app's # public directory when routes /img, /js, /css, /views are requested location ~ /(img|js|css|views)/ { rewrite ^(.*)$ /public/$1 break; } # location block below proxies all data requests (/api route) to your node app location /api { proxy_pass http://localhost:3000/; proxy_redirect http://localhost:3000/ http://example.com; proxy_connect_timeout 30s; proxy_read_timeout 30s; proxy_cookie_domain localhost example.com; #proxy_http_version 1.1; } # location block below rewrites all other routes to a specific html file # that is sent to the client and that is supposed to load all JS and # static assets to render a page location / { rewrite ^(.*)$ /public/app.html; } } 

La manière dont vous rendez le rendu de la page dans le client (et les données que vous demandez au serveur de le faire) dépendra de l’itinéraire demandé par l’utilisateur (auquel vous pouvez accéder / modifier en javascript et définir / accéder / modifier les cookies. ). Toute la navigation à l’intérieur de l’application (lorsque l’utilisateur clique sur des boutons ou des liens internes – vous devez intercepter tous les événements liés aux clics) se produit sans demandes supplémentaires de pages ou d’actifs statiques déjà chargés. Seules les demandes de données sont envoyées au serveur.

J’espère que ça aide.

Mise à jour SEO

La configuration suggérée pour nginx ne convient que si vous n’avez pas besoin de pages indexées par des robots et visibles pour les autres applications Web qui ont besoin de vos html statiques, tels que facebook, par exemple. Pour les pages que vous souhaitez indexer, vous devez append des conditions à routez les demandes des robots différemment (en fonction de $ http_user_agent) et restituez du code HTML statique pour ces routes. Mais il peut s’agir d’un code html purement sémantique différent (plus petit, sans images de conception, divs / classes de présentation, éléments d’interface utilisateur et javascript pour réduire les demandes de robots et d’applications Web).

Ce n’est pas l’approche la plus courante, mais c’est encore assez courant de nos jours. Il existe de nombreux frameworks Web ( angularjs de google, knockout , moustache , etc.) qui fonctionnent bien avec cette idée de modèles côté client.

Le modèle est demandé au serveur (c.-à-d. Json) et mappé dans une vue statique (modèle).

Je pense que cela convient parfaitement lorsque vous avez un serveur API fournissant des données JSON. De cette façon, vous ne pouvez développer qu’un autre client API, dans ce cas un client Web (RIA). Mais je ne pense pas que la raison principale derrière cette approche soit de sauver le processeur.