Entwicklerhandbuch zur Verbesserung der Projektstruktur in Meteor-Anwendungen

In den letzten Jahren hat die Zahl der verfügbaren JavaScript-Frameworks dramatisch zugenommen. Angefangen vom bewährten AngularJS bis hin zu zahlreichen Frameworks, die jeden Monat herauskommen, steht eine beeindruckende Vielfalt zur Auswahl. Eines, das meine Aufmerksamkeit vor ein paar Jahren erregt hat, ist ein Framework namens Meteor. Im Gegensatz zu den meisten Frameworks zielt Meteor darauf ab, eine vollständige Plattform für die Entwicklung von JavaScript-Apps zu sein. Für diejenigen, die neu bei Meteor sind, ermutige ich Sie, es auf ihrer Website zu überprüfen. Dieser Artikel ist keine Einführung in Meteor. Stattdessen werden wir einige einfache Möglichkeiten untersuchen, um Strukturen in Meteor-Projekte einzuführen.

Einer der großen Vorteile von Meteor ist, dass es sehr einfach ist, komplexe JavaScript-Anwendungen damit schnell zu prototypisieren. Da Meteor eine Mischung aus Front-End-Vorlagen und Rendering in Verbindung mit einem Node-basierten Server ist, der mit MongoDB (einer einheitlichen Lösung) interagiert, ist der größte Teil der Ersteinrichtung, die für die Erstellung einer Full-Stack-Webanwendung erforderlich ist, bereits für Sie erledigt. Die Leichtigkeit der Entwicklung, die dies bietet, kann jedoch eine Falle sein. Es ist leicht, in schlechte Praktiken zu verfallen und am Ende mit einem Durcheinander von unstrukturiertem Code zu enden, wenn man eine Meteor-App erstellt. Ich habe ein paar Vorschläge, wie dies vermieden werden kann.

Scaffolding: Verwaltbare Verzeichnishierarchie in Meteor

Erstens ist es wichtig, beim Erstellen Ihrer Anwendung die empfohlene Ordnerstruktur beizubehalten. Meteor ermöglicht es Ihnen, Dateien standardmäßig überall im Projektordner zu platzieren - Sie können sogar Ihren gesamten Code in einer einzigen Datei haben, wenn Sie dies wünschen. Während dies für ein Hackathon-Projekt funktionieren könnte, ist die Komplexität, die durch übliche skalierbare Apps auf Produktionsebene entsteht, ohne eine solide Struktur schwer zu bewältigen.

Um dieses Problem zu lösen, empfehle ich, sich das npm-Paket von Chris Mather anzusehen. Das Paket hat eine Vielzahl von Konfigurationsoptionen, daher wird es schwierig sein, es hier zu beschreiben, aber im Allgemeinen erstellt es eine Projektstruktur, die ungefähr so ​​​​aussehen wird:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

Für einige Projekte kann eine solche Ordner- und Dateistruktur jedoch zu viel des Guten sein. Nicht jedes Projekt muss eine so feinkörnige Organisationsebene haben, mit Trennungen für Sammlungen, Methoden und Veröffentlichungscode auf dem Server. Für diejenigen, die kein allzu großes Projekt haben oder einfach kein weiteres npm-Paket installieren und lernen möchten, empfehle ich diese grundlegende Ordnerstruktur:

Die Schlüsselelemente sind ein öffentlicher Ordner, der Dateien wie Ihr Favicon und andere statische Assets enthält, sowie die Client-, Common- und Server-Ordner. Die Client- und Serverordner sollten (natürlich) Code enthalten, der auf dem Client bzw. Server ausgeführt wird. Der allgemeine Ordner enthält Code, der sowohl für den Client als auch für den Server zugänglich sein muss. Ein Beispiel dafür ist Schema-Code, den wir gleich besprechen werden.

Es gibt zwei Möglichkeiten, die niedrigste Organisationsebene durchzuführen: eine nach Dateityp und die zweite nach Funktion. Die Organisation nach Dateityp bedeutet, dass Sie beispielsweise in Ihrem Client-/Vorlagenordner drei Ordner haben – einen für JavaScript-Dateien, einen für CSS und einen für HTML. Der HTML-Ordner enthält alle Ihre HTML-Vorlagendateien, z. B. Login.html, Main.html und so weiter. Die JavaScript- und CSS-Ordner enthalten jeweils Vorlagendateien ihres Typs. Organisation nach Funktion hingegen bedeutet Organisation nach dem Konzept, das die Dateien verkörpern. Beispielsweise hätte ich in client/templates einen Ordner „Login“ mit allen JavaScript-, CSS- und HTML-Dateien, die mit dem Anmeldeprozess der App verknüpft sind. Ich bevorzuge die Organisation nach Funktion, da Sie so klarer erkennen können, wo Sie bestimmte Dateien oder Codeteile finden können. Es ist jedoch nicht nur schwarz und weiß, und die meisten Einzelpersonen und Teams treffen auf eine Mischung dieser Methoden, um ihre Dateien und Ordner zu strukturieren.

Schema: Ihre App braucht es, auch wenn Ihre Datenbank es nicht tut

Die zweite Art von Struktur, die ich erörtern möchte, ist mit der Datenbank verbunden. In diesem Artikel wird davon ausgegangen, dass Sie MongoDB verwenden. Wenn Sie es nicht sind, gelten die Konzepte wahrscheinlich immer noch, aber die Besonderheiten nicht. Diejenigen, die MongoDB verwenden, wissen, dass die Art und Weise, wie wir unsere Daten speichern, unstrukturiert ist. Da MongoDB eine NoSQL-Dokumentspeicherdatenbank ist, gibt es kein festes Schema für irgendeinen „Typ“ von Daten. Diese Freiheit bedeutet, dass Sie sich nicht darum kümmern müssen, sicherzustellen, dass alle Objekte in einer starren Form standardisiert sind, sondern alle Daten Ihrer App können auf Wunsch in eine einzige Sammlung geworfen werden. Wenn es jedoch darum geht, Apps in Produktionsqualität zu erstellen, ist dies nicht wirklich wünschenswert. Um dies zu verwalten und nützliche Funktionen wie die Validierung von Schreibanforderungen hinzuzufügen, können wir uns zwei wunderbaren Meteor-Paketen zuwenden: Aldeeds SimpleSchema und Collection2.

Das SimpleSchema-Paket ermöglicht Ihnen, wie der Name schon sagt, die reaktive Validierung von Objekten in Ihrer App. Schauen Sie sich die Dokumente auf GitHub an. Das Collection2-Paket wird von SimpleSchema gestartet und ermöglicht es Ihnen, geeignete Schemas in Meteor-Sammlungen zu bringen. Was dies ermöglicht, ist die automatische Validierung von client- und serverseitigen Schreibanforderungen an jede Sammlung mit einem daran angehängten Schema. Beide Pakete sind sehr umfangreich und anpassbar, daher ist es schwierig, sie in wenigen Absätzen vollständig zu verstehen. Vielmehr empfehle ich Ihnen, sich die ausführlichen Readmes anzusehen, die Aldeed für die Einzelheiten zusammengestellt hat. Ich werde einfach darüber sprechen, wie ich aus diesen Paketen Nutzen gezogen habe. Eines der besten Dinge, die sie ermöglichten, war die Validierung der Formulareingabe des Benutzers. Dies ist praktisch, um Meteor-Benutzerdokumente (aus dem Accounts-Paket) zu validieren. Standardmäßig haben Meteor-Benutzer ein überraschend komplexes implizites Schema. Hier ist ein Bild eines Teils davon aus dem Code, den Aldeed so freundlicherweise zur Verfügung gestellt hat:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

Das ist einfach das Schema für das Profilobjekt des Benutzers. Der Versuch, das gesamte User-Objekt zu validieren, wäre ohne ein speziell entwickeltes Paket wie SimpleSchema ein Durcheinander. Während alle diese Felder im Bild optional erscheinen, wären sie es wahrscheinlich nicht, wenn Sie ein ordnungsgemäß validiertes Benutzerschema wollten, und Dinge wie „Schema.UserCountry“ leiten tatsächlich zu anderen Schemas zur Validierung um. Indem wir dieses Schema an das Benutzerobjekt anhängen und es reaktiv in unsere Formulare integrieren, vielleicht mit einem Paket wie AutoForm von Aldeed, können wir genau steuern, was in unsere Datenbanken gelangt und was nicht, was Zeit und Mühe spart ein konzeptionelles Modell des Umgangs mit Daten in unserer Anwendung, auf das konkret verwiesen und diskutiert werden kann.

Rollen: Für die 401er und 403er

Der letzte Vorschlag, den ich zum Strukturieren und Verbessern eines Meteor-Projekts habe, ist das Rollenpaket von Alanning. Dies ist ein Autorisierungssystem für Meteor, mit dem Sie Benutzerzugriffsebenen für jeden Teil Ihrer Web-App überprüfen können. Berechtigungen werden dem Benutzerprofil in Form von Zeichenfolgen angehängt, die später validiert oder ungültig gemacht werden, wenn der Benutzer versucht, auf Meteor-Methoden oder -Daten zuzugreifen, die für den Client veröffentlicht wurden. Zum Beispiel:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

Obwohl der Kern des Systems relativ einfach ist, ermöglicht es komplexe und fein abgestimmte Berechtigungen für jeden Teil Ihrer Anwendung. Da alle Rollen als Strings gespeichert sind, können Sie ein beliebig tiefes System einrichten – „admin“, „admin.division1.manage“, „admin.division1.manage.group2“ und so weiter.

Das Problem mit der Freiheit, die dieses Paket bietet, besteht darin, dass es schwierig sein kann, ein hochgradig granulares Rollensystem im Auge zu behalten. Das Paket bietet Funktionen wie „getAllRoles“, die, wie der Name schon sagt, alle von Ihnen erstellten Rollen abrufen, aber es liegt an Ihnen, zu verfolgen, was all ihre Bedeutungen sind und wann eine bestimmte Rolle sollte verwendet werden. Und für diejenigen, die neugierig sind, was der Unterschied zwischen „Rollen“ und „Berechtigungen“ ist, für die Zwecke dieses Pakets sind sie im Wesentlichen nicht anders.

Einpacken

Leider war es aufgrund der Breite des Artikels (jedes der hier erwähnten Pakete verdient ein eigenes Tutorial) nicht möglich, auf ein bestimmtes Paket im Detail einzugehen, aber ich hoffe, ich habe etwas Licht ins Dunkel gebracht, wie Sie auf eine „standardisierte ” Meteor-Anwendung, von der Sie sicher sein können, dass sie in der Produktion und im großen Maßstab gut funktioniert. Wenn Sie nach weiteren Informationen suchen, sehen Sie sich die Links an, die ich gepostet habe, und werfen Sie einen Blick auf eine weitere Sache, die es nicht in diesen Artikel geschafft hat, aber in einer Meteor-App nützlich ist: das Restivus-Paket, das Ihnen erlaubt um auf einfache Weise eine REST-API für Ihre App verfügbar zu machen.

Als Haftungsausschluss bin ich nicht der Autor eines dieser Pakete, und ich entschuldige mich, wenn ich die Funktionen oder Ziele eines Pakets falsch dargestellt habe. Vielen Dank für das Lesen, und ich hoffe, dieser Artikel war für Sie von Nutzen. Fühlen Sie sich frei, mich bei Fragen zu kontaktieren, die Sie haben könnten, oder hinterlassen Sie unten einen Kommentar.