Strukturieren einer Node.js- und AngularJS-Anwendung

77

Ich bin im Begriff, mein erstes AngularJS-Projekt zu versuchen, und es ist sinnvoll, Node.js für das Back-End zu verwenden, obwohl dies bedeutet, dass AngularJS und Node.js gleichzeitig von Grund auf neu gelernt werden.

Das erste, was ich versuche, ist eine gute Dateistruktur. Bisher hat meine reine HTML / CSS-Vorlage die folgende Verzeichnisstruktur ...

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

(_site ist ein Arbeitsverzeichnis für PSDs usw.)

Ich habe hier eine Beispielverzeichnisstruktur für eine Node.js / AngularJS-App gefunden ....

... was die folgende Verzeichnisstruktur vorschlägt.

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

Das sieht für mich also ziemlich gut aus (abgesehen von der Tatsache, dass ich Jade nicht verwenden würde).

Ich habe noch folgende Fragen ...

  1. Ich möchte alle Front-End- und Back-End-Dateien getrennt halten. Diese Lösung legt alle Front-End-Dateien im Verzeichnis public / ab. Was ist sinnvoll, da die meisten öffentlich sein müssen? Ist es jedoch sinnvoll, die Ordner SASS und _site hier abzulegen? Ich könnte sie einfach dort lassen, aber nicht hochladen, wenn ich sie in Produktion bringe, aber es scheint falsch, weil sie nicht öffentlich sein sollten. Sie gehören auch nicht auf Root-Ebene mit all dem Back-End-Zeug.

  2. Wäre es nicht besser, AngularJS von einem CDN zu laden ?

  3. Da der Server nur eine Vorlage (die Hauptanwendungsvorlage) bereitstellen muss und der gesamte andere HTML-Code im Front-End erstellt wird, ist es nicht sinnvoller, die Datei index.html statisch zu halten, den Ordner views und zu löschen Erstellen Sie einen Partials / Ordner unter public / wie es die ursprüngliche AngularJS Seed-Anwendung tut?

Mir ist klar, dass dies alles Ansichtssache ist, und ich könnte sie technisch platzieren, wo immer ich will, aber ich hoffe, dass jemand, der erfahrener ist als ich, mich über die Fallstricke verschiedener Verzeichnisstrukturen informieren kann.

javascript  angularjs  node.js 
— Jonhobbs
quelle
Sie können diesen Link nützlich finden Angular Project Structure
— Dalorzo

Antworten:

20

1) Normalerweise ist es sinnvoll, saas/lessDateien öffentlich zu machen , da Sie beim Debuggen möglicherweise die clientseitige Konvertierung less-> css verwenden möchten (less.js macht das). Ich bin mir_site jedoch nicht sicher, was Sie enthalten (übrigens sollten Sie für Ihr Projekt Kleinbuchstaben verwenden, insbesondere für öffentliche Inhalte) .

2) In der Regel empfiehlt es sich, AngularJS von Google CDN zu laden, wenn in der Produktion nur eine lokale Version für die Entwicklung verwendet wird. Abhängig von Ihrer Umgebung können zwei separate Layouts vorhanden sein.

3) Auch wenn clientseitiges Rendern der richtige Weg ist, können Sie das serverseitige Layout- / Ansichts-Rendering beibehalten. Sie werden es wahrscheinlich irgendwann benötigen (Administratorzugriff, E-Mail-Rendering usw.). Es kann jedoch hilfreich sein, den partialsNamen von AngularJS im öffentlichen Ordner zu verwenden, um Verwechslungen zwischen Server- viewsund Client-Seite zu vermeiden partials.

Sie sollten sich eindeutig für das entscheiden, was derzeit am logischsten erscheint. Sie werden wahrscheinlich Dinge bewegen, wenn Sie sich mit Express vertraut machen.

Sie sollten das vorhandene Express-Framework überprüfen, um festzustellen, wie sie ihre App strukturieren. Zum Beispiel hat TowerJS einen ziemlich sauberen configOrdner, aber sie verwechseln serverseitigen und clientseitigen Code, den ich persönlich nicht mag.

Überprüfen Sie diesen Vergleich von NodeJS MVC-Frameworks, um zu sehen, wie andere Dinge tun. Ich würde jedoch eindeutig mit Vanilla Express-Code beginnen, um die volle Kontrolle zu haben und zu verstehen, wie die Dinge funktionieren, bevor ich mich zu sehr auf eines dieser Frameworks einlasse.

— Olivier
quelle
2
# 2 hat mich überrascht. Empfehlen Sie wirklich ein CDN für Produkte? Warum?
— Jess
12
weil eine von CDN gehostete Ressource viel schneller geladen wird (geografische Verteilung der Hosts) und große Chancen hat, bereits von Ihrem Browser zwischengespeichert zu werden (und daher sofort mit 304 Not Modified zu antworten), da es viele andere Websites gibt, die sie bereits verwenden. Sie sollten immer noch eine einzelne js-Datei mit Ihrem eigenen Code erstellen (ausgenommen cdn-libs)
— Olivier
Beeindruckend. Es ist toll zu lernen. Gute Zusammenfassung. Hier sind weitere Informationen: stackoverflow.com/questions/2180391/… und stackoverflow.com/questions/547384/…
— Jess
Wie erstellen Sie "separate Layouts je nach Umgebung"? Kennt jemand ein Projekt, das dies demonstriert? Ist dies auch der Hauptvorteil des Debuggens von .js-Dateien in der Entwicklung, aber des Bereitstellens von .min.js-Dateien in der Produktion?
— Rob
2
Ich bezweifle, dass von CDN gehostete Ressourcen schneller sind. Eine Produktions-Webanwendung verkettet normalerweise alle Herstellerdateien zu einer Datei. Der Client muss dabei nur eine http-Anfrage ausführen, um alle Hersteller-js-Dateien abzurufen. Gehostete JS-Dateien erfordern eine http-Anforderung pro Datei - zwischengespeichert oder nicht, sie benötigen viel mehr Zeit als Ihre eine Datei.
— Spock
36

Mit der Zeit wird es immer einfacher. Ich habe Yeoman für das AngularJS-Frontend verwendet und es macht das Leben viel einfacher: http://yeoman.io/

Option 1, MEAN.io

MEAN ist ein großartiges Akronym! Ich bevorzuge die MEAN-Stack-Verzeichnisstruktur. Lassen Sie uns Kongressleute verwenden! Verwenden Sie einfach die Verzeichnisstruktur von mean.io . MEAN ist auch praktisch, weil es alle Leckereien wie Grunt , Bower usw. einwirft .

Geben Sie hier die Bildbeschreibung ein

Option 2, Angular-Seed + Express.js

Ich habe GitHub nach Node.js / AngularJS-Projekten durchsucht (wahrscheinlich nicht schwer genug) und nichts wirklich Tolles für eine Startverzeichnisstruktur gesehen. Daher habe ich das Skelett Node.js Express.js (das Express.js über die Befehlszeile weder mit EJS noch mit Jade / Pug ausführt ) mit dem Angular-Seed-Projekt zusammengeführt ( von GitHub klonen ). Dann habe ich eine Menge Sachen herumbewegt. Folgendes habe ich mir ausgedacht:

  • developer- Sachen, die nur die Entwickler verwenden werden. Muss nicht bereitgestellt werden.
    • config - Karma-Konfigurationsdateien und andere.
    • scripts - Entwicklerskripte (Erstellen, Testen und Bereitstellen)
    • test - e2e und Unit Tests.
  • logs
  • node_modules- Diese Stack Overflow-Antwort wird empfohlen, um sie in Git einzufügen. Dies kann jedoch jetzt veraltet sein .
  • public - Dies kommt fast direkt aus dem Angular-Seed-App-Ordner.
    • css, img, js, lib, partials- ziemlich offensichtlich und schön kurz.
  • routes - Node.js Routen.
  • server - serverseitige "shebang" Node.js-Programme, Daemons, Cron-Programme, was auch immer.
  • server.js - von app.js umbenannt, um deutlicher zu machen, dass dies serverseitig ist.

Geben Sie hier die Bildbeschreibung ein

— Jess
quelle
1
Hier mag ich Rails. Konvention ist eine ausgezeichnete Idee.
— Jess
Machen wir dies als Assistent für Nodeclipse Node.js. Wo sind Quellen für diese Vorlage?
— Paul Verest
Hallo @PaulVerest, ich habe keine Quelle an sich. Ich nahm das Angular-Seed-Projekt und ein grundlegendes Express-generiertes node.js-Projekt und führte sie zusammen. Express finden Sie auf dieser Seite: expressjs.com/guide.html . Suchen Sie nach Verwenden von Express (1), um eine App zu generieren . Für Angular habe ich github.com/angular/angular-seed.git
— Jess
Ich habe gehofft, dass es Quellen gibt, die wir als Vorlage in Nodeclipse verwenden können. Wir haben bereits Wizard for Express. Das Hinzufügen von Angular erfolgt weiterhin manuell.
— Paul Verest
1
@ BenTaliadoros - du hast recht. Die Dinge müssen sich im Laufe der Zeit geändert haben und npm wurde besser. Ich habe die SO-Frage verlinkt und meine Antwort bearbeitet. Vielen Dank.
— Jess
5

Wie vorgeschlagen, kommt es hauptsächlich auf die persönlichen Vorlieben an und darauf, was für das Projekt funktioniert, an dem Sie gerade arbeiten. Jeder, mit dem Sie sprechen, hat andere Ideen, und jedes Projekt hat sein eigenes Design - was für das eine funktioniert, funktioniert möglicherweise nicht für das andere. Ich gehe davon aus, dass Sie einige verschiedene Strukturen ausprobieren werden und bald eine finden werden, die am bequemsten ist - aber diese wird sich im Laufe der Zeit weiterentwickeln.

Ich habe festgestellt, dass die Angular Seed-Struktur die sauberste ist, aber auch dies ist eine persönliche Präferenz (obwohl es hilfreich ist, dass sie vom Angular-Team entworfen wurde.)

Sie könnten auch Yeoman in Betracht ziehen, um Projektskelette zu generieren.

Yeoman ist eine robuste und einfühlsame Sammlung von Tools, Bibliotheken und einem Workflow, mit denen Entwickler schnell schöne, überzeugende Web-Apps erstellen können.

Es ist ein großartiges Tool zum Booten und Verwalten von Projekten (ähnlich wie bei Rails) und erstellt eine Verzeichnisstruktur und Skelettdateien, auf denen Sie aufbauen können. Brian Ford hat einen ausgezeichneten Beitrag über die Verwendung von Yeoman mit Angular geschrieben.

Ich schlage auch vor, die Angular-Meetup-Aufnahmen auf ihrem YouTube-Kanal anzusehen. Ich habe kürzlich an einem Treffen in Mountain View teilgenommen, bei dem diese Fragen auftauchten. Miško empfahl Angular Seed und Yeoman (zumindest als guten Ausgangspunkt).

So beantworten Sie Ihre individuellen Fragen:

  1. Alle Dateien, die serverseitig kompiliert werden, sollten außerhalb Ihres öffentlichen Ordners aufbewahrt werden. Ich würde empfehlen, keine Master-PSDs, Modelle oder andere Dateien, die nicht für den öffentlichen Gebrauch bestimmt sind (entweder vom Browser oder vom Benutzer), in öffentlichen Ordnern zu speichern.

  2. Es ist immer gut, statische Assets (JS, Images, CSS) von einem CDN bereitzustellen, wenn Sie viel Verkehr erwarten. Es ist nicht so wichtig für weniger besuchte Websites, aber dennoch eine gute Idee. Ich würde damit beginnen, die Dateien lokal für die anfängliche Entwicklung bereitzustellen. Lassen Sie die Asset-Optimierung, wenn Sie sich Ihrem Live-Datum nähern. Wenn diese Zeit gekommen ist, möchten Sie auch Ihr Caching richtig einrichten. Yeoman bietet beispielsweise eine gute Möglichkeit, Ihre Assets zu versionieren. Dies bietet Ihnen den Vorteil langlebiger Caches, ermöglicht es Ihnen jedoch, Aktualisierungen der Dateien an die Clients zu senden.

  3. Wenn für Ihre Indexdatei kein serverseitiges Rendering erforderlich ist, stellen Sie sie statisch bereit. Ich möchte mein Backend mit Angular-Apps so weit wie möglich vom Backend entkoppeln. Es hilft, die Trennung der Bedenken aufrechtzuerhalten. Bei der Entwicklung der Client-Dateien müssen Sie überhaupt nicht an das Backend denken (Angular eignet sich hervorragend dafür.)

Wirklich, Sie müssen nur herumspielen; Probieren Sie verschiedene Dinge aus, lesen Sie Blog-Beiträge, holen Sie sich Ideen von anderen, stellen Sie Fragen (wie Sie es hier und auf der Angular Google+ Community-Seite getan haben), schauen Sie sich Videos an und nehmen Sie, wenn Sie können, an Meetups teil - Meetups sind wirklich großartig dafür.

— Berry Phillips
quelle
Yeoman ist def. der Weg, den man gehen sollte. Es werden auch Codestrukturen (Boilerplate-Code) für Sie erstellt.
— Steve K
2

Ich bin nicht mit allen vorherigen Beiträgen einverstanden. Sie werden entweder von einem anderen Ort eingefügt oder hatten keinen eigenen Verstand. Nach meinen Erfahrungen ist es besser, Ihre clientseitigen Codes zu reduzieren. Ich meine, der Code in Ihrem Client-Verzeichnis sollte sich in Ihrem Stammverzeichnis befinden.

Warum schlage ich diesen Weg vor? Denn wenn Sie Ihr Full-Stack-JavaScript-Projekt in ein Projekt ohne Backend ändern möchten, aber nur das Frontend einschließen möchten, ist dies viel einfacher. Ich meine, die meisten mit JavaScript geschriebenen Projekte konzentrieren sich auf das Frontend.

Es ist besser, Ihren Backend-Code in einem Verzeichnis wie "Server" in derselben Ordnerebene wie "CSS", "Image" abzulegen. Der Vorteil ist, dass Sie einfach ein Backend hinzufügen müssen, wenn Sie ein Backend benötigen oder nicht oder löschen Sie das Verzeichnis "Server", ohne dass dies Auswirkungen auf die ursprüngliche Projektstruktur hat.

So was:

Geben Sie hier die Bildbeschreibung ein

— 胡亚雄
quelle
0

Ich habe genau das Gleiche untersucht.

Meine ersten Gedanken waren auf die Verwendung von Express Generator und Angular Seed gerichtet .

Dann habe ich eine viel schönere Lösung gefunden:

Einer der beliebtesten yeoman-Generatoren bietet Ihnen eine Struktur für Node.js- und AngularJS-Anwendungen.

Ich glaube an die Kraft der Standardisierung und neue Leute, die sich dem Projekt anschließen, werden die einheitliche Struktur zu schätzen wissen.

— Mars Robertson
quelle
Wie immer beim Downvoting - bitte geben Sie Feedback - nach meinem naiven Verständnis - sind Starterprojekte hier, um Best Practices in Bezug auf die Codestruktur durchzusetzen - was fehlt mir hier?
— Mars Robertson
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.