web-dev-qa-db-fra.com

Structuration d'une application Node.js et AngularJS

Je suis sur le point d’essayer mon premier projet AngularJS, et il est logique d’utiliser Node.js pour le back-end, même si cela implique d’apprendre à la fois AngularJS et Node.js.

La première chose que j'essaie de comprendre est une bonne structure de fichiers. Jusqu'à présent, mon modèle HTML/CSS pur a la structure de répertoires suivante ...

_site/
Fonts/
Javascript/
SASS/
Stylesheets/
Index.html

(_site est un répertoire de travail pour les PSD, etc.)

J'ai trouvé un exemple de structure de répertoire pour une application Node.js/AngularJS ici ....

... qui suggère la structure de répertoire suivante.

app.js              --> Application configuration
package.json        --> For npm
public/             --> All of the files to be used in on the client side
  css/              --> CSS files
    app.css         --> Default stylesheet
  img/              --> Image files
  js/               --> JavaScript files
    app.js          --> Declare top-level application module
    controllers.js  --> Application controllers
    directives.js   --> Custom AngularJS directives
    filters.js      --> Custom AngularJS  filters
    services.js     --> Custom AngularJS services
    lib/            --> AngularJS  and third-party JavaScript libraries
      angular/
        angular.js            --> The latest AngularJS
        angular.min.js        --> The latest minified AngularJS
        angular-*.js          --> AngularJS add-on modules
        version.txt           --> Version number
routes/
  api.js            --> Route for serving JSON
  index.js          --> Route for serving HTML pages and partials
views/
  index.jade        --> Main page for the application
  layout.jade       --> Doctype, title, head boilerplate
  partials/         --> AngularJS view partials (partial jade templates)
    partial1.jade
    partial2.jade

Donc, cela me semble plutôt bon (à part le fait que je n'utiliserais pas Jade).

J'ai encore les questions suivantes ...

  1. Je veux que tous les fichiers front-end et back-end soient séparés. Cette solution place tous les fichiers frontaux dans le répertoire public /, ce qui est logique car la plupart doivent être publics, mais est-il judicieux de placer les dossiers SASS et _site ici? Je pourrais simplement les garder là-bas, mais pas les télécharger quand je les mets en production, mais cela semble faux, car ils ne devraient pas être publics. Ils n'appartiennent pas non plus au niveau racine avec tous les éléments d’arrière-plan.

  2. Ne serait-il pas préférable de charger AngularJS depuis un CDN ?

  3. Étant donné que le serveur n’aura besoin que de fournir un modèle (le modèle principal de l’application) et que tous les autres codes HTML seront construits sur le serveur frontal, il serait plus logique de conserver le fichier index.html statique, de supprimer le dossier Views et créer un dossier/partials sous public/comme l’application d’AngularJS Seed originale?

Je me rends compte que tout cela est une question d’opinion et que je pourrais techniquement les placer où je veux, mais j’espère que quelqu'un de plus expérimenté que moi pourrait me renseigner sur les pièges des différentes structures de répertoires.

javascriptangularjsnode.js
77
jonhobbs

1) Il est généralement logique de rendre publics les fichiers saas/less car vous pouvez utiliser la conversion less-> css côté client lors du débogage (less.js le fait). Vous ne savez pas ce que contient votre _site cependant (au fait, vous devriez utiliser des dossiers en minuscules pour votre projet, en particulier pour les éléments publics).

2) Il est généralement recommandé de charger AngularJS à partir du CDN Google en production. Si vous utilisez uniquement une version locale pour le développement, vous pouvez disposer de deux présentations distinctes en fonction de votre environnement.

3) Même si le rendu côté client est la voie à suivre, vous pouvez conserver le rendu disposition/vues côté serveur, vous en aurez probablement besoin à un moment donné (accès administrateur, rendu du courrier électronique, etc.). Toutefois, il peut être utile d’utiliser le nom partials de AngularJS dans le dossier public pour éviter toute confusion entre views côté serveur et partials côté client.

Vous devriez clairement choisir ce qui semble être la chose la plus logique à faire à l’heure actuelle: vous allez probablement déplacer les choses à mesure que vous vous familiariserez avec Express.

Vous devriez vérifier le cadre express existant pour voir comment ils structurent leur application. Par exemple, TowerJS a un dossier config assez propre, mais ils mélangent les codes côté serveur et côté client, ce que je n’aime pas personnellement.

Vérifiez cette comparaison des frameworks NodeJS MVC pour voir comment les autres font les choses. Cependant, je commencerais clairement par le code Vanilla Express afin d’être en mesure de tout contrôler et de comprendre le fonctionnement avant d’engager des efforts excessifs dans l’un ou l’autre de ces cadres.

20
Olivier

Les choses deviennent plus faciles avec le temps. J'ai utilisé Yeoman pour le front-end AngularJS, et cela rend la vie beaucoup plus facile: http://yeoman.io/

Option 1, MEAN.io

MEAN est un acronyme génial! Je préfère la structure de répertoire de pile MEAN. Utilisons les gens de convention! Utilisez simplement la structure de répertoires de mean.io . MEAN est pratique aussi car il contient toutes les friandises comme Grunt , Bower , etc.

Enter image description here

Option 2, angular-seed + Express.js

J'ai cherché dans GitHub des projets Node.js/AngularJS (probablement pas assez fort) et je n'ai rien vu de vraiment génial pour une structure de répertoire de départ. J'ai donc fusionné le squelette Node.js Express.js (exécutant Express.js à partir de la ligne de commande sans l'aide de EJS ni Jade/Pug ) avec le projet angular-seed ( le cloner depuis GitHub ). Ensuite, j'ai déplacé une tonne de choses. Voici ce que je suis venu avec:

  • developer - remplit uniquement le ou les développeurs. Ne nécessite pas d'être déployé .
    • config - fichiers de configuration de karma et autres.
    • scripts - scripts de développeur (construction, test et déploiement)
    • test - e2e et tests unitaires.
  • logs
  • node_modules - cette réponse au débordement de pile il est recommandé de la mettre dans Git. Cependant, cela peut maintenant être obsolète.
  • public - Cela vient presque directement du dossier de l'application angular-seed .
    • css, img, js, lib, partials - assez évident et agréable et court.
  • routes - itinéraires Node.js.
  • server - programmes "Shebang" Node.js côté serveur, démons, programmes cron, peu importe.
  • server.js - renommé depuis app.js pour que ce soit plus évident, ceci est côté serveur.

Enter image description here

36
Jess

Comme suggéré, cela dépend principalement des préférences personnelles et de ce qui fonctionne pour le projet sur lequel vous travaillez à ce moment-là. Toutes les personnes à qui vous parlez ont des idées différentes et chaque projet a sa propre conception. Ce qui fonctionne pour l'un ne fonctionne pas pour l'autre. Je m'attends à ce que vous essayiez plusieurs structures différentes et que vous en trouviez bientôt une qui soit la plus confortable, mais cela évoluera avec le temps.

J'ai trouvé que la structure angulaire Seed était la plus propre, mais encore une fois, c'est une préférence personnelle (cependant, le fait qu'elle soit conçue par l'équipe angulaire aide).

Vous pouvez également envisager de regarder Yeoman pour générer des squelettes de projet.

Yeoman est un ensemble d'outils, de bibliothèques et de fichiers .__ robustes et motivés. flux de travail qui peut aider les développeurs à créer rapidement de belles, convaincantes applications Web.

C'est un excellent outil pour amorcer et gérer des projets (comme Rails) et crée une structure de répertoires et des fichiers squelettes sur lesquels vous pourrez vous appuyer. Brian Ford a écrit un excellent post sur l'utilisation de Yeoman avec Angular.

Je suggère également de regarder les enregistrements de rendez-vous angulaires sur leur chaîne YouTube. J'ai récemment assisté à une réunion à Mountain View où ces questions ont été soulevées. Miško a recommandé Angular Seed et Yeoman (au moins comme bon point de départ.)

Pour répondre à vos questions individuelles:

  1. Tous les fichiers compilés côté serveur doivent être conservés en dehors de votre dossier public Je suggérerais de ne pas conserver les fichiers maître PSD, maquettes ou tout autre fichier non destiné à la consommation publique (Par navigateur ou par utilisateur) dans des dossiers publics. 

  2. Il est toujours bon de servir des ressources statiques (JS, images, CSS) à partir d'un fichier CDN si vous vous attendez à un trafic important. Ce n'est pas très important pour les sites moins visités, mais c'est quand même une bonne idée. Je commencerais par Servir les fichiers localement pour le développement initial. Laissez la ressource Optimisation pour quand vous approchez de votre date de direct. Lorsque ce moment arrivera, vous voudrez également que votre mise en cache soit bien configurée ... par exemple, Yeoman constitue un bon moyen de la gestion de la version de vos actifs. Ceci vous donne l'avantage de posséder des caches à vie longue. mais vous autorisantà envoyer les mises à jour des fichiers aux clients.

  3. Si votre fichier d'index ne nécessite aucun rendu côté serveur, Le sert de manière statique. J'aime garder mon backend découplé du backend Autant que possible avec des applications angulaires. Cela aide à maintenir la séparation des préoccupations; lors du développement des fichiers client, vous n'avez pas besoin de penser au backend (angular est génial pour cela.)

Vraiment, il vous suffit de jouer; Essayez différentes choses, lisez des articles de blog, obtenez des idées, posez des questions (comme vous l'avez fait ici et sur la page de communauté Angular Google+), visionnez des vidéos et, si vous le pouvez, participez à des rencontres - les Meetups sont vraiment intéressants.

5
Berry Phillips

Je ne suis pas d'accord avec tous les posts précédents. Ils sont soit collés d'un autre endroit ou n'avaient pas leur propre esprit. D'après mes expériences, il est préférable d'aplanir vos codes côté client. Je veux dire que le code dans votre répertoire client devrait être dans votre répertoire racine.

Pourquoi est-ce que je suggère cette façon? Parce que si vous voulez changer votre projet JavaScript full-stack pour celui sans backend, mais inclure uniquement le front-end, c'est beaucoup plus facile. Je veux dire que la plupart des projets écrits avec JavaScript sont centrés sur l'interface. 

Il est préférable de placer votre code backend dans un répertoire du type "serveur" au même niveau que "css", "image" ... L'avantage est que lorsque vous avez besoin ou non d'un backend, ajoutez ou supprimez le répertoire "serveur", sans que cela affecte la structure du projet Origin.

Comme ça:

 Enter image description here

2
胡亚雄

Voir ce squelette

https://github.com/Giancarlo1974/SailsAngular

Il intègre Angular 4 + Bootstrap 4 pour le client et Node Sails JS pour le serveur.

Un des points forts de cette solution est: 1) Automatisation des tâches 2) Agnosticisme de base de données

0
Janka

J'enquêtais sur la même chose.

Mes pensées initiales étaient orientées vers l’utilisation de Express Generator et Angular Seed .

Ensuite, j'ai trouvé une solution beaucoup plus agréable:

L'un des générateurs yeoman les plus populaires vous fournit une structure pour les applications Node.js et AngularJS.

Je crois au pouvoir de la normalisation et les nouvelles personnes qui rejoindront le projet apprécieront la structure unifiée.

0
Michal Stefanow