Enfiler des longjohns en amiante ...
Hier, mon titre avec Packt Publications, Programmation réactive avec JavaScript . Ce n'est pas vraiment un titre centré sur Node.js; les premiers chapitres sont destinés à couvrir la théorie, et les chapitres ultérieurs à code élevé couvrent la pratique. Parce que je ne pensais pas vraiment qu'il serait approprié de ne pas donner aux lecteurs un serveur Web, Node.js semblait de loin le choix évident. L'affaire a été classée avant même son ouverture.
J'aurais pu donner une vue très positive de mon expérience avec Node.js. Au lieu de cela, j'étais honnête au sujet des bons et des mauvais points que j'ai rencontrés.
Permettez-moi d'inclure quelques citations pertinentes ici:
Attention: Node.js et son écosystème sont chauds - assez chaud pour vous brûler gravement!
Lorsque j'étais assistant enseignant en mathématiques, l'une des suggestions non évidentes qui m'avaient été suggérées était de ne pas dire à un étudiant que quelque chose était «facile». La raison était quelque peu évidente rétrospectivement: si vous dites aux gens que quelque chose est facile, quelqu'un qui ne voit pas de solution peut finir par se sentir (encore plus) stupide, car non seulement ils ne savent pas comment résoudre le problème, mais le problème ils sont trop stupides pour comprendre que c'est facile!
Il y a des pièges qui n'ennuient pas seulement les gens venant de Python / Django, qui rechargent immédiatement la source si vous changez quelque chose. Avec Node.js, le comportement par défaut est que si vous apportez une modification, l'ancienne version continue d'être active jusqu'à la fin des temps ou jusqu'à ce que vous arrêtiez et redémarriez manuellement le serveur. Ce comportement inapproprié ne dérange pas seulement les Pythonistas; cela irrite également les utilisateurs natifs de Node.js qui proposent diverses solutions de contournement. La question StackOverflow «Rechargement automatique des fichiers dans Node.js» a, au moment de la rédaction de ce document, plus de 200 votes positifs et 19 réponses; une modification dirige l'utilisateur vers un script de nounou, node-supervisor, avec une page d'accueil à http://tinyurl.com/reactjs-node-supervisor. Ce problème offre aux nouveaux utilisateurs une grande opportunité de se sentir stupides car ils pensaient avoir résolu le problème, mais l'ancien comportement buggé est complètement inchangé. Et il est facile d'oublier de faire rebondir le serveur; Je l'ai fait plusieurs fois. Et le message que je voudrais donner est: «Non, vous n'êtes pas stupide parce que ce comportement de Node.js vous a mordu le dos; c'est juste que les concepteurs de Node.js n'ont vu aucune raison de fournir un comportement approprié ici. Essayez d'y faire face, peut-être en prenant un peu d'aide du superviseur de noeud ou d'une autre solution, mais s'il vous plaît ne vous éloignez pas en vous sentant stupide. Ce n'est pas vous qui avez le problème; le problème est dans le comportement par défaut de Node.js. "
Cette section, après un débat, a été laissée, précisément parce que je ne veux pas donner une impression de «c'est facile». Je me suis coupé les mains à plusieurs reprises tout en faisant fonctionner les choses, et je ne veux pas atténuer les difficultés et vous faire croire que le bon fonctionnement de Node.js et de son écosystème est une question simple et si ce n'est pas simple pour vous aussi , vous ne savez pas ce que vous faites. Si vous ne rencontrez pas de difficultés odieuses en utilisant Node.js, c'est merveilleux. Si vous le faites, j'espère que vous ne vous en éloignerez pas en vous disant: "Je suis stupide - il doit y avoir quelque chose qui ne va pas avec moi." Vous n'êtes pas stupide si vous rencontrez de mauvaises surprises face à Node.js. Ce n'est pas toi! C'est Node.js et son écosystème!
L'annexe, que je ne voulais pas vraiment après la montée du crescendo dans les derniers chapitres et la conclusion, parle de ce que j'ai pu trouver dans l'écosystème et a fourni une solution de contournement au littéralisme débile:
Une autre base de données qui semblait être un ajustement parfait, et qui peut encore être utilisée, est une implémentation côté serveur du magasin de valeurs-clés HTML5. Cette approche a l'avantage cardinal d'une API que la plupart des bons développeurs frontaux comprennent assez bien. D'ailleurs, c'est aussi une API que la plupart des développeurs frontaux pas si bons comprennent assez bien. Mais avec le package node-localstorage, bien que l'accès à la syntaxe du dictionnaire ne soit pas proposé (vous voulez utiliser localStorage.setItem (clé, valeur) ou localStorage.getItem (clé), pas localStorage [clé]), la sémantique localeStorage complète est implémentée , y compris un quota de 5 Mo par défaut - POURQUOI?Les développeurs JavaScript côté serveur doivent-ils être protégés d'eux-mêmes?
Pour les capacités de base de données côté client, un quota de 5 Mo par site Web est vraiment une marge de manœuvre généreuse et utile pour permettre aux développeurs de travailler avec. Vous pouvez définir un quota beaucoup plus bas et offrir aux développeurs une amélioration incommensurable par rapport à la boiterie avec la gestion des cookies. Une limite de 5 Mo ne se prête pas très rapidement au traitement côté client Big Data, mais il y a une allocation vraiment assez généreuse que les développeurs ingénieux peuvent utiliser pour faire beaucoup. Mais d'un autre côté, 5 Mo ne représentent pas une part particulièrement importante de la plupart des disques achetés récemment, ce qui signifie que si vous et un site Web êtes en désaccord sur l'utilisation raisonnable de l'espace disque, ou si un site est tout simplement lourd, cela ne coûte pas vraiment vous beaucoup et vous n'êtes pas en danger d'un disque dur submergé à moins que votre disque dur était déjà trop plein.
Cependant, il peut être doucement souligné que lorsque vous êtes le seul à écrire du code pour votre serveur, vous n'avez pas besoin de protection supplémentaire contre la taille de votre base de données supérieure à 5 Mo tolérable. La plupart des développeurs n'auront ni besoin ni envie d'outils agissant comme un nounou et les protégeant du stockage de plus de 5 Mo de données côté serveur. Et le quota de 5 Mo qui est un acte d'équilibrage d'or côté client est plutôt stupide sur un serveur Node.js. (Et, pour une base de données pour plusieurs utilisateurs telle que celle couverte dans cette annexe, il peut être souligné, légèrement douloureusement, que ce n'est pas 5 Mo par compte d'utilisateur, sauf si vous créez une base de données distincte sur le disque pour chaque compte d'utilisateur; c'est 5 Mo partagés entre tous les comptes d'utilisateurs ensemble. Cela pourrait douloureuxsi vous devenez viral!) La documentation indique que le quota est personnalisable, mais un e-mail il y a une semaine au développeur demandant comment changer le quota est sans réponse, tout comme la question de StackOverflow le demandant. La seule réponse que j'ai pu trouver est dans la source Github CoffeeScript, où il est répertorié comme un deuxième argument entier facultatif pour un constructeur. C'est donc assez simple, et vous pouvez spécifier un quota égal à la taille d'un disque ou d'une partition. Mais en plus de porter une fonctionnalité qui n'a pas de sens, l'auteur de l'outil n'a pas complètement suivi une convention très standard d'interprétation de 0 comme signifiant «illimité» pour une variable ou une fonction où un entier doit spécifier une limite maximale pour une certaine utilisation des ressources. La meilleure chose à faire avec cette erreur est probablement de spécifier que le quota est Infinity:
if (typeof localStorage === 'undefined' || localStorage === null)
{
var LocalStorage = require('node-localstorage').LocalStorage;
localStorage = new LocalStorage(__dirname + '/localStorage',
Infinity);
}
Échanger deux commentaires dans l'ordre:
Les gens se sont inutilement tirés dans le pied en utilisant constamment JavaScript dans son ensemble, et une partie du langage JavaScript étant respectable était un Douglas Crockford disant en substance: «JavaScript en tant que langage a de très bonnes et de très mauvaises parties. Voici les bonnes parties. Oubliez juste que tout le reste est là. » Peut-être que l'écosystème chaud de Node.js développera son propre «Douglas Crockford», qui dira: «L'écosystème de Node.js est un Far West codant, mais il y a de vrais joyaux à trouver. Voici une feuille de route. Voici les domaines à éviter à tout prix. Voici les zones avec certains des plus riches chèques de paie que l'on puisse trouver dans N'IMPORTE QUELLE langue ou environnement. »
Peut-être que quelqu'un d'autre peut prendre ces mots comme un défi, suivre l'exemple de Crockford et rédiger «les bonnes parties» et / ou «les meilleures parties» pour Node.js et son écosystème. J'achèterais une copie!
Et compte tenu du degré d'enthousiasme et des heures de travail sur tous les projets, il peut être justifié dans un an, deux ou trois, de tempérer fortement toutes les remarques sur un écosystème immature faites au moment de la rédaction de cet article. Cela peut vraiment avoir du sens dans cinq ans de dire: «L'écosystème Node.js 2015 avait plusieurs champs de mines. L'écosystème 2020 Node.js a plusieurs paradis. »