7 clés pour structurer votre application Node.js

Rahul Mhatre est architecte technique chez Built.io.

Node.js rattrape rapidement Java, Ruby, Python et .Net en tant que langage préféré pour le développement de nouvelles applications Web. L'équipe Node.js rend le temps d'exécution JavaScript meilleur, plus rapide et plus solide chaque jour. Et la communauté d'utilisateurs se développe à un rythme rapide.

Alors que l'adoption continue d'augmenter, de plus en plus de développeurs graviront la courbe d'apprentissage de Node.js, confrontés à des problèmes similaires et codant des fonctionnalités similaires. Heureusement, la communauté Node.js est venue à la rescousse avec des frameworks et des modèles de conception qui non seulement résolvent les problèmes courants, mais aident également à structurer les applications.

Les frameworks implémentent généralement des modèles MV tels que MVC (model-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presenter) ou simplement MV. Ils vous indiquent également où doit se trouver le code des modèles, des vues et des contrôleurs, où doivent se trouver vos routes et où vous devez ajouter vos configurations. De nombreux jeunes développeurs et passionnés de Node.js ne comprennent pas vraiment comment les modèles de conception ou les diagrammes OOP (Object Oriented Programming) correspondent aux lignes ou à la structure du code de leur application.

C'est là qu'interviennent les frameworks Node.js comme Express.js et Sails.js. Ceux-ci et bien d'autres sont disponibles pour aider à démarrer le développement d'applications Web. Quel que soit le cadre que vous utilisez, vous voudrez garder certaines considérations à l'esprit lors de la structuration de votre application.

Voici les sept points clés que je contemple avant de cartographier une application Node.js.

1. La bonne structure de répertoires pour l'application

Lorsque vous décidez de la structure de répertoire de votre application, vous devez tenir compte du modèle de conception que vous avez choisi. Cela vous aidera à intégrer, trouver du code et isoler les problèmes plus rapidement. Personnellement, je préfère utiliser un modèle MVC lors de la conception d'une application Node.js. Cela m'aide à développer plus rapidement, offre la flexibilité de créer plusieurs vues pour les mêmes données et permet une communication asynchrone et une isolation entre les composants MVC, pour n'en nommer que quelques-uns.

J'aime suivre la structure des répertoires ci-dessus, qui est basée sur une combinaison de Ruby on Rails et Express.js.

Vidéo connexe: trucs et astuces Node.js

Dans cette vidéo explicative, découvrez plusieurs techniques qui peuvent améliorer votre expérience de développement de nœuds.

2. Mappage des diagrammes ER aux modèles

Tel que défini dans Techopedia, «Un diagramme entité-relation (ERD) est une technique de modélisation de données qui illustre graphiquement les entités d'un système d'information et les relations entre ces entités.» Un diagramme ER décrit les différentes entités qui participeront à notre système et définit toutes les interactions entre elles telles que:

  • Tout ce qui est une «chose» abstraite ou physique devient une entité dans un modèle
  • Un modèle correspond à une table dans notre base de données
  • Un attribut ou une propriété d'une entité se traduit par un attribut d'un modèle, qui est à son tour une colonne à l'intérieur d'une table

Par exemple, si votre entité est un utilisateur, le modèle correspondant serait un «utilisateur» avec des attributs tels que prénom, nom et adresse à l'intérieur de la base de données, ainsi qu'une table et des colonnes correspondantes.

L'utilisation d'une architecture de données simple facilite le suivi de la croissance de votre base de données et de vos fichiers à chaque fois qu'un nouveau schéma est créé.

3. Utilisation du modèle MVP

La mise en œuvre de MVC ne signifie pas simplement créer des dossiers pour les contrôleurs, les vues et les modèles. Vous devez également diviser votre code et votre logique en fonction de MVC. Le code à l'intérieur de vos modèles doit être strictement limité aux définitions de schéma de base de données. Les développeurs oublient généralement que les modèles auront également du code qui effectuera des opérations CRUD. En outre, toute fonction ou opération spécifique à ce modèle doit être présente dans ce fichier. La plupart de la logique métier liée à un modèle doit se trouver dans ce fichier.

Une erreur courante consiste à transférer toute la logique métier dans les contrôleurs. Les contrôleurs doivent uniquement appeler des fonctions à partir de modèles ou d'autres composants, transférer des données entre des composants et contrôler le flux de la demande, tandis que le dossier de vue ne doit contenir que du code pour convertir les objets sous une forme lisible par l'homme. Aucune logique telle que le formatage des données ou le tri ou le filtrage ne doit être effectuée dans la vue. Garder les vues propres fournira non seulement une meilleure expérience utilisateur, mais vous aidera également à changer les vues sans modifier aucun autre composant.

4. Décomposition de la logique en modules

En tant que développeurs, on nous dit toujours que nous devons organiser le code en fichiers et en modules. Cela ne veut pas dire que nous devons essayer de placer l'ensemble de l'application dans un seul fichier. Diviser votre code en fonction de la logique et des fonctionnalités est la meilleure approche. Le regroupement des fonctions liées à une seule entité ou objet dans un seul fichier et l'organisation de la structure de répertoire basée sur la logique présente de nombreux avantages. Premièrement, cela vous fera gagner beaucoup de temps pour déterminer quelle fonction toucher lorsqu'un bogue doit être corrigé. Deuxièmement, il aide à découpler tous les composants de l'architecture, facilitant le remplacement des fonctionnalités discrètes sans avoir besoin de modifier d'autres lignes de code. Troisièmement, cela aidera également à écrire des cas de test.

5. L'importance des cas de test

Il est très important de ne jamais couper les coins ronds lors de la création de cas de test - les tests sont les gardiens de votre base de code. Au fur et à mesure que votre application se développe, il devient plus difficile de se souvenir de tous les scénarios que vous devez couvrir pendant le codage. Les cas de test vous aident à maintenir votre base de code stable. Les tests empêchent la régression, économisant du temps et des efforts de développement précieux. Cela vous aide à vous assurer que les nouvelles fonctionnalités seront diffusées sans erreur. Il permet également d'améliorer la qualité du code en détectant les bogues avant qu'ils ne passent en production. Et surtout, les tests aident à donner l'assurance que le code ne plantera pas.

6. L'importance des journaux

Les journaux sont utiles pour déboguer et comprendre l'état de votre application. Ils fournissent des informations précieuses sur le comportement de l'application. Voici une liste rapide de choses à garder à l'esprit lors de l'exploitation des journaux:

  • Trouvez le bon équilibre en matière de journalisation. Avoir «trop d'informations» n'est jamais mauvais, mais la surexploitation ne fera que rendre votre travail plus difficile. Les aiguilles sont plus faciles à trouver dans les petites meules de foin. D'un autre côté, la sous-journalisation entraînera trop peu d'informations disponibles pour déboguer ou diagnostiquer.
  • Divisez vos journaux hors ligne et en ligne, les journaux les plus récents étant conservés pour une récupération et un traitement rapides, tandis que les journaux plus anciens sont archivés ou vidés dans des fichiers.
  • Tenez compte de la fréquence et de la durée de vos journaux, car cela aura un impact sur la quantité de stockage dont vous aurez besoin. La plupart du temps, la quantité de stockage dont vous avez besoin et le nombre de journaux dont vous disposez sont directement proportionnels.

Et n'oubliez pas de ne pas enregistrer les données sensibles telles que les identifiants de messagerie, les mots de passe, les informations de carte de crédit et les numéros de téléphone. Ce n'est pas seulement un risque de sécurité énorme, mais souvent illégal.

7. L'application évoluera-t-elle?

La pire approche du développement d'applications consiste à réfléchir à la manière de procéder à une mise à l'échelle après avoir gagné du trafic. Au lieu de cela, vous devez créer une architecture capable de se développer depuis le début pour gagner du temps et augmenter la productivité.

La mise en rotation des serveurs n'évolue pas; la répartition de la charge entre les ressources est. Cela ne signifie pas que vous ne devriez pas créer de nouveaux serveurs lorsque la charge augmente. Tout d'abord, vous devez configurer l'équilibrage de charge dans vos ressources actuelles pour gérer l'augmentation de la charge. Lorsque l'équilibrage de charge ne peut pas gérer efficacement la charge de travail, il est temps de commencer la mise à l'échelle horizontale et de générer de nouveaux serveurs. Vous pouvez y parvenir via un processus sans état indépendant ou via des modules. Chaque processus ou module fonctionnera de manière isolée et indépendante. Cela aidera non seulement votre application à évoluer efficacement, mais rendra également votre système tolérant aux pannes et facile à récupérer.

La manière dont vous structurez une application Web est aussi importante que la sélection de la bonne technologie. Si les fondations sont défectueuses, l'application finira par se planter, ou refuser de se mettre à l'échelle, ou dans certains cas ne pas démarrer du tout. Ne vous précipitez jamais dans le développement de nouvelles fonctionnalités ou de nouvelles idées sans une planification et une architecture appropriées. Une mauvaise structure ou architecture est comme une bombe à retardement qui attend d'exploser.

Le New Tech Forum offre un lieu pour explorer et discuter des technologies d'entreprise émergentes avec une profondeur et une ampleur sans précédent. La sélection est subjective, basée sur notre choix des technologies que nous pensons importantes et qui intéressent le plus les lecteurs. n'accepte pas les supports marketing pour la publication et se réserve le droit de modifier tout le contenu fourni. Envoyez toutes vos demandes à [email protected]