Structurer une application NodeJS et Angular JS

Question

Je suis sur le point de tenter mon premier projet Angular JS et il est logique d'utiliser Node JS pour le back-end, même si cela signifie apprendre Angular et Node à partir de zéro en même temps.

La première chose que j'essaie de comprendre, c'est une bonne structure de fichiers. Pour l'instant, mon modèle Pure HTML/CSS a la structure de répertoire suivante : ....

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

( _site est un répertoire de travail pour les PSDs etc)

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

https://github.com/btford/angular-express-seed

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

app.js              --> app config
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 app module
    controllers.js  --> application controllers
    directives.js   --> custom angular directives
    filters.js      --> custom angular filters
    services.js     --> custom angular services
    lib/            --> angular and 3rd party JavaScript libraries
      angular/
        angular.js            --> the latest angular js
        angular.min.js        --> the latest minified angular js
        angular-*.js          --> angular 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 app
  layout.jade       --> doctype, title, head boilerplate
  partials/         --> angular view partials (partial jade templates)
    partial1.jade
    partial2.jade

Donc, cela me semble très bien (sauf que je n'utiliserais pas Jade).

J'ai encore les questions suivantes...

1) Je veux garder tous les fichiers frontaux et dorsaux 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à et ne pas les télécharger lorsque je les mets en production, mais cela ne semble pas correct car ils ne devraient pas être publics. Ils n'ont pas non plus leur place au niveau de la racine avec tous les éléments du back-end.

2) Ne serait-il pas préférable de charger Angular à partir d'un CDN ?

3) Étant donné que le serveur n'aura besoin de fournir qu'un seul modèle (le modèle de l'application principale) et que tout le reste du HTML sera construit sur le front-end, ne serait-il pas plus logique de garder le fichier index.html statique, de supprimer le dossier views et de créer un dossier partials/ sous public/ comme le fait l'application Angular Seed originale ?

Je réalise que tout ceci n'est qu'une question d'opinion et que je pourrais techniquement les mettre où je veux, mais j'espère que quelqu'un de plus expérimenté que moi pourra me conseiller sur les pièges des différentes structures de répertoire.

Comme vous pouvez le voir, c'est nouveau pour moi. Toute aide serait vraiment appréciée.

Answer 1

Je pense que c'est une excellente question.

Option 1, MEAN.io

MEAN est un acronyme génial ! J'ai récemment modifié cette réponse pour préférer la structure de répertoire de la pile MEAN. Utilisons les conventions ! Utilisez simplement la structure de répertoire de mean.io . MEAN est également pratique car il intègre toutes les fonctionnalités comme grunt, bower, etc.

Option 2, Angular-seed + Express

J'ai cherché sur Github des projets node/angular (probablement pas assez) et je n'ai rien vu de vraiment génial pour une structure de répertoire de départ. Donc ce que j'ai fait, c'est fusionner le node express (Running express depuis la ligne de commande n'utilisant ni ejs ni jade) squelette avec le projet angular-seed ( clonez-le depuis gitub ). Puis j'ai déplacé une tonne de choses. Voilà ce que j'ai trouvé :

---

• developer - Des trucs que seul le ou les développeurs utiliseront. Il n'est pas nécessaire de les déployer.
  • config - les fichiers de configuration du karma et autres.
  • scripts - développeur scripts (build/test/deploy)
  • test - e2e et les tests unitaires.
• logs
• node_modules - une question SO séparée recommandée pour mettre ceci dans git
• public - Cela vient presque directement du dossier de l'application angular-seed.
  • css , img , js , lib , partials - C'est assez évident, agréable et court.
• routes - les itinéraires des nœuds.
• server - programmes de nœuds côté serveur, démons, programmes cron, etc.
• server.js - renommé app.js pour qu'il soit plus évident qu'il s'agit du côté serveur.

---

---

Si vous avez des suggestions ou de meilleures idées, veuillez laisser un commentaire. Merci !

Answer 2

1) En général, cela a du sens de faire saas/less car vous pourriez vouloir utiliser la conversion less->css côté client lors du débogage (less.js le fait). Je ne suis pas sûr de ce que votre _site contient toutefois (en fait, vous devriez utiliser des dossiers en minuscules pour votre projet, surtout pour les documents publics). .

2) C'est généralement une bonne pratique de charger AngularJS à partir du CDN de Google lorsqu'on est en production, en utilisant uniquement une version locale pour le développement, vous pourriez avoir deux mises en page distinctes en fonction de votre environnement.

3) Même si le rendu côté client est la voie à suivre, vous pouvez conserver le rendu de la mise en page/des vues côté serveur, vous en aurez probablement besoin à un moment ou à un autre (accès à l'administration, rendu des e-mails, etc.). Cependant, il peut être utile d'utiliser la fonction partials d'AngularJS dans le dossier public, afin d'éviter toute confusion entre les applications côté serveur et les applications côté client. views & côté client partials .

Il est clair que vous devez opter pour ce qui vous semble le plus logique à l'heure actuelle. Vous déplacerez probablement les choses au fur et à mesure que vous vous familiariserez avec l'express.

---

Vous devriez vérifier le framework express existant pour voir comment ils structurent leur application. Par exemple, TowerJS est assez propre config Cependant, ils mélangent le code côté serveur et le code côté client, ce que je n'aime pas personnellement.

Regardez cette comparaison de Cadres MVC NodeJS pour voir comment les autres font les choses. Cependant, je commencerais clairement avec du code vanilla express afin d'avoir un contrôle total et de comprendre comment les choses fonctionnent avant de m'engager sur l'un de ces frameworks.

Answer 3

Comme nous l'avons suggéré, il s'agit surtout de préférences personnelles et de ce qui fonctionne pour le projet sur lequel vous travaillez à ce moment-là. Chaque personne à qui vous parlez aura des idées différentes, et chaque projet a sa propre conception - ce qui fonctionne pour l'un peut ne pas fonctionner pour l'autre. Je m'attends à ce que vous essayiez plusieurs structures différentes et que vous trouviez rapidement celle qui est la plus confortable - mais cela évoluera encore avec le temps.

J'ai trouvé que la structure d'Angular Seed était la plus propre, mais là encore, il s'agit d'une préférence personnelle (même si le fait qu'elle soit conçue par l'équipe d'Angular aide).

Vous pouvez également envisager de consulter Yeoman pour générer des squelettes de projets.

Yeoman est un ensemble d'outils, de bibliothèques et d'un système de gestion de l'information. flux de travail qui peuvent aider les développeurs à construire rapidement de belles et convaincantes applications web.

Il s'agit d'un excellent outil pour amorcer et gérer des projets (de manière similaire à ce que fait Rails) et il créera une structure de répertoires et des fichiers squelettes sur lesquels vous pourrez vous appuyer. Brian Ford a écrit une excellent poste sur l'utilisation de Yeoman avec Angular.

Je vous suggère également de regarder les enregistrements des rencontres Angular sur leur chaîne YouTube. J'ai récemment participé à un meetup à 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 qui sont compilés côté serveur doivent être conservés en dehors de la section votre dossier public. Je suggère de ne pas conserver les fichiers master PSDs, mockups, ou tout autre fichier qui n'est pas destiné à la consommation publique public (que ce soit par le navigateur ou l'utilisateur) dans les dossiers publics.

2. Il est toujours bon de servir des actifs statiques (JS, images, CSS) à partir d'un CDN si vous prévoyez un trafic élevé. CDN si vous prévoyez un trafic important. Ce n'est pas aussi important pour les sites moins visités, mais c'est toujours une bonne idée. Je commencerais par servir les fichiers localement pour le développement initial. Laissez l'optimisation des ressources pour le moment où vous vous rapprochez de la date de mise en ligne. Lorsque ce Lorsque ce moment arrivera, vous devrez également configurer correctement votre cache. Yeoman, par exemple, offre un bon moyen de gérer les versions de vos ressources. Cela vous donne l'avantage d'avoir des caches de longue durée tout en vous permettant de de pousser les mises à jour des fichiers vers les clients.

3. Si votre fichier d'index ne nécessite pas de rendu côté serveur, servez-le de manière statique. J'aime garder mon back-end découplé du back-end backend autant que possible avec les applications Angular. Cela permet de maintenir séparation des préoccupations ; lors du développement des fichiers clients, vous n'avez pas à vous n'avez pas besoin de penser au backend (Angular est excellent pour cela).

En réalité, il suffit de jouer, d'essayer différentes choses, de lire des articles de blog, d'obtenir des idées des autres, de poser des questions (comme vous l'avez fait ici et sur la page de la communauté Angular Google+), de regarder des vidéos et, si vous le pouvez, de participer à des réunions - les réunions sont vraiment très utiles pour cela.

Answer 4

Ethan Garofolo dans ses nodecasts suggère une solution pratique pour structurer une application nodejs http://www.learnallthenodes.com/episodes/8-how-to-structure-a-node-app