L'auteur du matériel, dont nous publions la traduction, a collecté 19 idées qui pourraient être utiles aux développeurs de Node.js qui souhaitent améliorer leur niveau professionnel en 2019. Le monde de JavaScript est immense, donc maîtriser tout ce qui sera discuté ici est tout simplement irréaliste. Il est peu probable qu'il y ait quelqu'un qui possède tout cela parfaitement. Cependant, quelque chose dans cette revue pourrait bien vous être utile.
1. Pensez à taper. Faites attention à TypeScript
Il est prouvé que la programmation en JavaScript, en utilisant l'approche de typage utilisée, conduit à une diminution de la productivité du travail et à l'apparition d'erreurs. Cela ne signifie pas que vous devez vous efforcer de vous assurer que tout le code est fortement tapé. Nous parlons plutôt du fait qu'il serait bien, lors du développement en JavaScript, de choisir une certaine approche pour travailler avec les types et de s'y tenir. De telles approches diffèrent, entre autres, par le niveau de restrictions associées aux types de données imposées au code. Par exemple, cela peut être quelque chose de très simple, quelque chose comme organiser des contrôles en utilisant le
paquet jsonschema (ou
joi ). Si vous sentez que vous avez besoin d'un contrôle de type plus strict, vous pouvez envisager d'utiliser des annotations de type dans le code JS normal (ici le
flux de Facebook vous aidera). Et si vous êtes prêt à écrire du code presque entièrement tapé, faites attention à
TypeScript .
Il convient de noter qu'en 2018, TypeScript a gagné en popularité, de plus, il y a le sentiment qu'il a toutes les conditions pour qu'il s'établisse solidement dans Node.js. Si vous regardez sérieusement TypeScript, vous devriez vous demander si vous ne pensez qu'à taper ou à d'autres fonctionnalités du langage. Le point ici est que travailler avec quelque chose comme des interfaces et des classes abstraites signifie que vous vous retrouverez dans un environnement dans lequel, en pensant principalement à la frappe, vous n'alliez guère y entrer.
2. Faites attention aux capacités de linter
Les lintres de nos jours sont considérées comme acquises. Après une configuration simple, vous avez à votre disposition un outil pour vous aider à trouver les erreurs dans le code. Il est révolu le temps où le peluchage du code signifiait principalement contrôler sa conception (quelque chose comme la présence ou l'absence de points-virgules). Désormais, les linters peuvent identifier des problèmes graves, tels que des erreurs qui ne sont pas gérées correctement, des promesses qui ne sont jamais résolues et d'autres problèmes similaires que personne n'inclura consciemment dans son code. Par conséquent, si vous n'utilisez pas encore le linter, c'est le moment de le faire, sans oublier sa configuration réfléchie. Voici, par exemple, un plugin pour
ESLint ,
eslint-plugin-chai-expect , qui peut détecter des tests composés par erreur. Voici le
plugin eslint-plugin-promise qui détecte les promesses non résolues (le code avec de telles promesses, sans raison apparente, s'arrête simplement). En utilisant le
plugin eslint-plugin-security, il est possible de trouver des expressions régulières dangereuses dans le code qui peuvent être utilisées par un attaquant pour mener des attaques DOS.
3. Approfondissez vos connaissances sur l'architecture des projets logiciels en adoptant quelque chose du monde Java et en oubliant beaucoup du monde Ruby
L'écosystème de Node.js soulève rarement le thème de l'architecture et de la conception des systèmes d'information. Donc, tout le monde parle de microservices, mais très peu parlent de leur structure interne. Par conséquent, la plupart des applications Node.js sont des exemples d'implémentation de concepts MVC et d'autres modèles douteux du monde Ruby. Qu'est-ce qui est si mauvais à ce sujet? Le modèle MVC, par exemple, a été créé pour rationaliser le travail avec les données, mais ce modèle n'est pas adapté à la conception de parties serveur fiables d'applications. Bob Martin, par exemple,
dit que MVC est un mécanisme pour fournir des données à un utilisateur, pas une architecture d'application. Est-il possible de décrire la logique métier d'une application de microservice, les règles de son fonctionnement, les caractéristiques de l'accès aux données, l'interaction avec d'autres microservices en utilisant seulement deux classes -
Controller et
Model ?
Il convient de noter que je ne veux absolument pas recommander d'utiliser des modèles Java / Spring dans Node.js ici (après tout, ce n'est pas un hasard si nous sommes passés à Node.js pour développer des programmes serveur?). Je vous conseille de n'emprunter que quelques idées qui, d'une part, peuvent avoir un effet bénéfique sur l'architecture des applications, et d'autre part, n'entraîneront pas leur complexité excessive.
Voici quelques lignes directrices pour ceux qui se soucient de l'architecture des projets Node.js:
- Lisez la première section de cet article sur l'architecture d'application Node.js.
- Essayez de ne pas mélanger la logique métier de l'application avec les objets Express, lisez les principes DDD ( Domain-Driven Design ) et l' architecture hexagonale .
- L'utilisation du modèle Active Record, très populaire parmi les développeurs utilisant Mongoose et Sequelize, conduit facilement à l'apparition d'objets surchargés difficiles à tester. Envisagez d'utiliser le modèle Data Mapper au lieu du modèle Active Record.
- Consultez le code de ce modèle Node.js bien conçu, doté d'une architecture de qualité qui met en œuvre les principes de DDD.
4. Réfléchissez à l'utilisation du nouveau Node.js-API async_hooks lorsque vous travaillez avec du code asynchrone
Le modèle d'exécution de code à thread unique utilisé en JavaScript présente un inconvénient majeur: les opérations asynchrones, par exemple les requêtes, perdent le contexte. Il n'est pas enregistré pendant le cycle de vie de la requête, car les opérations asynchrones sont impliquées dans leur exécution. Pourquoi est-ce mauvais? Par exemple, les développeurs cherchent souvent à inclure des identificateurs de requête uniques dans les entrées de journal, ce qui, lors de l'analyse de ces enregistrements, permet d'identifier ceux qui se rapportent à la même requête. Aujourd'hui, en 2018, ce n'est pas si facile. L'année prochaine, quelque chose de nouveau nous attend, à savoir, nous parlons de hooks asynchrones, l'API
async_hooks . Cela ne veut pas dire qu'il s'agit d'une opportunité complètement nouvelle, le fait est qu'elle devrait bientôt quitter le régime expérimental. En termes simples, les hooks asynchrones permettent à un développeur d'exécuter du code natif à certains moments du cycle de vie d'une opération asynchrone. Dans cet esprit, vous pouvez coordonner les actions effectuées par du code asynchrone et maintenir le contexte. Cette fonctionnalité jette les bases du développement de packages qui porteront Node.js à un nouveau niveau dans le suivi des opérations asynchrones et l'utilisation du contexte.
Par exemple, le package
cls-hooked vous permet d'organiser l'utilisation des variables et du contexte tout au long du cycle de vie d'une opération asynchrone. Le package
jaeger-client vous permet de visualiser le processus de transmission d'une demande via des systèmes, même via des microservices et des serveurs (la norme Javascript OpenTracing API 1.0 est implémentée ici).
Voici le matériel pour en savoir plus sur l'utilisation de l'API async_hooks.
5. Comprendre les dernières technologies «sans serveur» qui sont déjà tout à fait prêtes pour des projets sérieux et capables de tuer Kubernetes
Ici, nous utilisons les concepts de FaaS (Fonction en tant que service, fonction en tant que service) et «technologies sans serveur» comme synonymes, bien qu'ils ne signifient pas la même chose. En particulier, nous parlerons ci-dessous des services FaaS cloud.
Initialement, la technologie FaaS était destinée à développer des micro-tâches et non à créer des applications de "microservice" à part entière. La popularité croissante des plateformes FaaS a conduit à une augmentation de l'intérêt des fournisseurs de services cloud, les plateformes FaaS ont acquis de nouvelles fonctionnalités. En conséquence, bien que cela soit inattendu, on a le sentiment qu'en 2019, les plateformes FaaS peuvent devenir la base de projets sérieux. Ces plates-formes peuvent-elles rivaliser avec Kubernetes et être utilisées pour héberger de grandes applications? Certains voient dans l'informatique sans serveur et les technologies FaaS quelque chose de complètement nouveau, mais dans la pratique, chaque créateur d'une application cloud devra faire un choix entre les trois technologies en 2019. Ce choix est, littéralement, présenté sur les sites Web des fournisseurs de services cloud. À savoir, nous parlons de choisir l'une des trois options:
- Serveur cloud normal (par exemple VDS de RUVDS)
- Kubernetes
- FaaS
Par conséquent, à notre époque, il est très important de pouvoir comparer les capacités de Kubernetes avec FaaS et d'anticiper les conséquences du choix d'une technologie particulière.
6. Découvrez les innovations JavaScript qui seront bientôt disponibles en standard.
Je ne peux pas m'appeler partisan de la recherche et de l'utilisation des dernières fonctionnalités du langage, car leur utilisation nuit parfois à la simplicité et à l'intelligibilité du code. Mais de temps en temps, des fonctionnalités JavaScript très précieuses apparaissent (comme la construction async / wait il y a deux ans), il est donc utile de consulter
la liste d'offres
TC39 et la ressource
node.green afin de connaître à l'avance les nouvelles fonctionnalités qui pourraient vous convenir. Voici ce que j'ai trouvé intéressant ici:
- Les champs de classe sont maintenant au 3 (dernier) stade d'approbation, ils peuvent entrer dans la norme en 2019.
- Le type de données BigInt passe également par la dernière étape de la réconciliation. L'utilisation de nombres de ce type peut aider à organiser l'interaction avec des microservices ou tout autre système, au cours duquel des nombres énormes sont utilisés.
- Les itérateurs asynchrones et la méthode promise finalement () ont déjà été acceptés. Si vous n'y avez pas encore prêté attention, lisez-les.
7. Maîtrisez au moins une technologie pour créer une API. Faites attention à GraphQL
L'API REST est un excellent outil pour résoudre une certaine classe de tâches. À savoir, nous parlons de la gestion des requêtes et de la modification des enregistrements dans les bases de données. Votre système est-il axé sur l'utilisation de données financières? Probablement, pour assurer son fonctionnement, il est nécessaire de respecter les restrictions les plus strictes et d'utiliser un modèle de données soigneusement développé qui ne permet pas d'ambiguïtés. La technologie REST vous convient dans ce cas, mais elle ne se montre pas très bien dans d'autres situations très courantes, par exemple, lorsque l'exécution de la même demande peut conduire à la réception de différents ensembles de données. La même chose s'applique au travail dans des conditions de faibles vitesses de connexion, lorsqu'il est nécessaire que le moins de données possible soit transmis lors du travail avec une certaine API. De telles situations incluent les connexions entre ordinateurs, où la communication à haut débit prend le dessus. Vaut-il la peine dans de tels cas de passer à quelque chose de nouveau? Non, ça n'en vaut pas la peine. Il est préférable d'ajouter quelque chose de nouveau à ce qui est déjà utilisé. Une API n'est pas une architecture d'application. Il s'agit simplement d'un point d'accès à l'application, ce qui signifie que les API créées à l'aide de différents outils peuvent coexister. Même s'ils sont tous construits sur un seul framework Web comme Express.
Quelle technologie étudier? Probablement, dans les conditions actuelles, il vaut la peine de parier sur la technologie GraphQL, qui devient de plus en plus populaire. L'écosystème de cette technologie a mûri de manière significative, elle sert à certains scénarios de données très populaires - tels que la recherche dynamique et l'interaction avec des sources de données hiérarchiques. D'un autre côté, la technologie gRPC est toujours une solution hautement spécialisée qui est bien adaptée à la communication entre les serveurs dans des situations où, lors de l'échange de données, il est souhaitable de transférer le moins d'informations de service possible (par exemple, nous parlons de systèmes d'échange de données basés sur le « publisher-subscriber ", ou sur ceux où les messages et les files d'attente de messages sont utilisés). Voici quelques articles utiles à ce sujet:
- Comparaison de REST, GraphQL et gRPC
- Développement de serveur GraphQL basé sur Node.js et Express
- Vidéo YouTube de 11 minutes expliquant les bases de GraphQL
8. Utilisation de tests unitaires et d'intégration? Jetez un œil aux toutes nouvelles techniques de test.
Connaissez-vous déjà la pyramide des tests, avec les tests unitaires, d'intégration et de bout en bout? Si c'est le cas - super. Tout cela sous-tend des stratégies de test réussies. Cependant, il convient de noter qu'au cours des 10 dernières années, le monde du développement logiciel a changé très sérieusement et que les modèles de test sont restés les mêmes, ce qui nous pose des questions sur la façon de tester les microservices, les applications Internet riches, les systèmes sans serveur. Certaines approches modernes des tests complètent l'ensemble traditionnel de technologies, et certaines peuvent même le remplacer, améliorant ainsi la stratégie et les résultats des tests. Voici ce que vous pouvez lire et voir:
- Les systèmes de test basés sur le modèle des contrats axés sur le consommateur aident à éviter les défaillances des API de serveur utilisées par les microservices ou les clients.
- Les tests à l'aide d'instantanés peuvent être utilisés non seulement dans le frontend, mais également dans les projets de serveur.
- Le test des composants est une approche équilibrée pour tester les microservices.
- Voici une vidéo sur les approches modernes pour tester les projets Node.js.
9. Alignez votre système de surveillance des applications sur les meilleures pratiques SRE / DevOps
En 2019, même une application de taille moyenne peut comprendre des dizaines de composants. Afin d'assurer le bon fonctionnement de ces infrastructures, elles doivent être soigneusement surveillées. Malgré l'évidence de ce qui précède, la plupart des développeurs ne considèrent toujours pas important d'étudier et d'utiliser ces recommandations pour surveiller les applications et créer un système d'alertes sur les problèmes qui peuvent leur être transmis par les spécialistes responsables de la fiabilité des projets Web. Par exemple, les développeurs se concentrent souvent sur des indicateurs internes des performances du système, tels que la vitesse du processeur ou la RAM, plutôt que de se soucier des mesures qui affectent directement les utilisateurs finaux. En particulier, nous parlons de la fréquence des erreurs et des retards. C'est ce qu'on
appelle la «surveillance basée sur les symptômes». Ces indicateurs axés sur l'utilisateur sont parfois appelés «signaux d'or», et vous, éventuellement en introduisant un système de surveillance, décidez de commencer par introduire de telles mesures. Voici les documents associés:
10. Améliorez la sécurité des projets en les examinant du point de vue d'un attaquant, ainsi qu'en apprenant à mener des attaques et des outils de piratage
Si vous ne pouvez pas penser comme quelqu'un qui veut attaquer votre système, cela signifie que vous ne pouvez pas penser comme le ferait le défenseur de ce système. En 2019, vous ne devez ni transférer des tâches pour protéger des projets à des tiers, ni compter uniquement sur des analyseurs de sécurité statiques. Il existe aujourd'hui un grand nombre de types d'attaques (les dernières tendances dans ce domaine sont les
attaques sur l'infrastructure de développement et sur npm). Dans le même temps, les applications changent très, très rapidement - hier, le projet a été reconnu comme bien protégé, et demain ils peuvent ajouter plusieurs nouveaux services AWS, plusieurs nouveaux types de bases de données et un nouveau rôle IAM. Dans le même temps, il ne sera pas tôt pour analyser la sécurité du projet. Le résultat est que les développeurs présentent le plus grand risque de sécurité pour leurs propres projets. La solution à ce problème est leur formation. Cela signifie que chaque développeur de projets Web doit apporter la mise en œuvre des règles de sécurité presque à l'automatisme, et quoi qu'il fasse, se souvenir toujours de la sécurité.
Après avoir décidé d'aller dans cette direction, il s'avère que la prise en compte de la sécurité lors de l'exécution de tout travail n'est pas si effrayante. Par exemple, après vous être familiarisé avec les méthodes et outils courants d'attaque, dessinez un schéma de l'architecture de votre application et réfléchissez à la manière dont vous l'attaqueriez. Au fil du temps, sans même vous donner un rapport à ce sujet, vous commencerez à prendre en compte les problèmes de sécurité, en prenant chaque décision architecturale et en entrant chaque nouvelle ligne de code dans l'éditeur. Voici quelques idées pour gérer les problèmes de sécurité:
- Essayez OWASP ZAP - un outil multifonctionnel pour la recherche de systèmes et de piratage, qui permet même à un débutant d'apprendre le niveau de sécurité des applications.
- Consultez cette liste de recommandations de sécurité Node.js pour plus de deux douzaines d'idées d'attaque et des exemples de code JavaScript.
- Planifiez une réunion mensuelle d'analyse des menaces au cours de laquelle l'équipe de projet étudiera son architecture et proposera des attaques contre celle-ci. Si une telle idée vous semble ennuyeuse, vous pouvez gamifier de telles réunions. Disons que ceux qui trouvent la vulnérabilité peuvent être récompensés d'une manière ou d'une autre. Vous pouvez également, par exemple, diviser les participants à une telle réunion en deux équipes et organiser une compétition entre elles pour trouver les vulnérabilités.
11. Concevez et implémentez une stratégie de mise à jour du package npm. 2018 a montré que la précipitation lors de leur mise à jour est dangereuse
En règle générale, les équipes de développement adhèrent à l'une des deux «stratégies» de mise à jour des packages npm. Ils les mettent à jour le plus rapidement possible après la sortie de leurs nouvelles versions, parfois même en automatisant ce processus, ou n'ont pas du tout de stratégie de mise à jour des packages. Avec cette approche, les packages sont mis à jour de manière irrégulière et, à partir de ce processus, ils sont guidés par quelque chose comme une pensée soudaine: "Devrions-nous être mis à jour aujourd'hui?" Bien que la première de ces approches soit meilleure que la seconde, elle s'est révélée inopinément associée à un risque plus élevé en 2018 que la seconde. Des problèmes, comme celui qui s'est produit avec le paquet
flat-stream , ont été découverts par la communauté en quelques dizaines de jours, et ceux qui n'étaient pas pressés de mettre à jour étaient en sécurité.
Envisagez de formaliser la stratégie de mise à jour des packages dont dépend votre projet; envisagez d'utiliser des outils d'automatisation pour ce processus. Trouvez le juste milieu entre refuser les mises à jour et mettre à jour les packages trop souvent. Ici, le programme
npq peut
vous aider, qui vérifie les packages lors de l'installation et donne des recommandations. Vous pouvez jeter un oeil à des projets commerciaux comme
greenkeeper . L'inconvénient de telles solutions est qu'elles ne peuvent pas retarder l'installation jusqu'au moment où il sera absolument clair qu'un certain paquet est sûr.
12. Examinez de plus près le déploiement progressif des projets
Peut-être qu'en 2019, vous jugerez raisonnable de déployer des projets en production en utilisant un schéma en plusieurs phases, et non en envoyant instantanément tout ce qui était auparavant dans le processus de développement à un serveur de combat. Ce processus est appelé «déploiement canari», il offre un niveau de protection de projet plus élevé que le déploiement simultané de nouveau code. Il distingue généralement les trois étapes suivantes:
- Déploiement Le nouveau code est déployé dans un nouvel environnement de production isolé (sur le nouveau service Kubernetes, sur un nouveau serveur virtuel). À ce stade, le code ne sert à personne encore, par conséquent, ses échecs ne peuvent pas causer de préjudice.
- Test. Désormais, plusieurs spécialistes peuvent travailler avec le nouveau code dans des conditions aussi proches que possible des réelles, puisque le code est déployé en production.
- Relâchez Après que les tests ont montré l'opérabilité du nouveau code, il est progressivement donné accès à un nombre croissant d'utilisateurs, et après qu'il s'est avéré qu'il fonctionne de manière suffisamment fiable, son ancienne version est progressivement mise hors service.
Un point important à souligner ici est que faire des déploiements de canaris à grande échelle en 2019 sera toujours un plaisir très coûteux. Le fait est que cela nécessite une coordination du travail des éléments d'infrastructure du projet - tels que l'acheminement et la surveillance. Ainsi, si vous souhaitez appliquer une technique similaire, vous devez commencer par un déploiement canariaire simple et partiellement manuel. En particulier, cela consiste dans le fait qu'après la réussite des premiers tests, compte tenu des indicateurs de suivi, l'ajout manuel de serveurs avec une nouvelle version du logiciel au système est effectué. En savoir plus sur les sorties de canaris
ici . Si vous souhaitez automatiser le processus d'exécution de telles versions, faites attention à la plate-forme
Spinnaker .
13. Découvrez la technologie Kubernetes qui a conquis le monde.
Kubernetes (K8S) , . - . . Kubernetes , , 54% K8S-. —
. K8S — , :
, , Kubernetes, .
14. -,
- — . , .
15. , , ,
, — . , . . , (,
tensorflow.js brain.js , , ).
16.
, . , , . , — .
17. Linux, —
Linux- , , . — , ( — ), Docker, . , , , , , .
, Linux.
18. , Node.js
( Node.js): « . , ». , , ( ). , Node.js, , V8 libuv. , 2019 — , Node.js, , , libuv. , , , Node.js - , .
, .
, npm- C/C++.
Node.js.
Node.js RUVDS.
19. ,
, , . , , , , , . , , , , . JavaScript-, . , JavaScript, . , , TypeScript . flow , , . , - flow, , , , « , ». ? , , «
». , - . , , , — . . , - , , , . , . , 2019 , — .
.
, . — , , , , , , . , , , , , .
Résumé
19 , Node.js-, - , 2019 . , - , .
Chers lecteurs! Node.js- 2019 ?
