Lassen Sie LoopBack es tun: Eine exemplarische Vorgehensweise für das Node-API-Framework, von dem Sie schon immer geträumt haben

Es ist unnötig, die wachsende Popularität von Node.js für die Anwendungsentwicklung zu erwähnen. eBay betreibt seit 2011 einen Produktions-Node-API-Dienst. PayPal baut sein Front-End aktiv in Node um. Die mobile Website von Walmart ist in Bezug auf den Datenverkehr zur größten Node-Anwendung geworden. Am Thanksgiving-Wochenende 2014 verarbeiteten Walmart-Server 1,5 Milliarden Anfragen, von denen 70 Prozent über Mobilgeräte und mit Node.js bereitgestellt wurden. Auf der Entwicklungsseite wächst der Paketmanager Node (npm) weiterhin schnell und hat kürzlich die Marke von 150.000 gehosteten Modulen überschritten.

Während Ruby Rails und Python Django hat, muss das vorherrschende Anwendungsentwicklungs-Framework für Node noch etabliert werden. Aber es gibt einen starken Konkurrenten, der an Fahrt gewinnt: LoopBack, ein Open-Source-API-Framework, das von der Firma StrongLoop aus San Mateo, Kalifornien, entwickelt wurde. StrongLoop leistet einen wichtigen Beitrag zur neuesten Node-Version, ganz zu schweigen von den langjährigen Betreuern von Express, einem der beliebtesten existierenden Node-Frameworks.

Lassen Sie uns einen genaueren Blick auf LoopBack und seine Fähigkeiten werfen, indem wir alles in die Praxis umsetzen und eine Beispielanwendung erstellen.

Was ist LoopBack und wie funktioniert es mit Node?

LoopBack ist ein Framework zum Erstellen von APIs und zum Verbinden mit Backend-Datenquellen. Aufbauend auf Express kann es eine Datenmodelldefinition annehmen und einfach eine voll funktionsfähige End-to-End-REST-API generieren, die von jedem Client aufgerufen werden kann.

LoopBack wird mit einem integrierten Client, API Explorer , geliefert. Wir werden dies verwenden, da es die Ergebnisse unserer Arbeit leichter sichtbar macht und damit sich unser Beispiel auf das Erstellen der API selbst konzentrieren kann.

Sie müssen natürlich Node auf Ihrem Computer installiert haben, um mitzumachen. Hol es dir hier. npm wird mitgeliefert, sodass Sie die erforderlichen Pakete einfach installieren können. Lass uns anfangen.

Erstellen Sie ein Skelett

Unsere Anwendung verwaltet Personen, die Geschenke oder Dinge, die sie einfach nicht mehr benötigen, an jemanden spenden möchten, der sie möglicherweise benötigt. Die Benutzer sind also Spender und Empfänger. Ein Spender kann ein neues Geschenk erstellen und die Liste der Geschenke einsehen. Ein Empfänger kann die Liste der Geschenke von allen Benutzern sehen und alle nicht beanspruchten beanspruchen. Natürlich könnten wir Spender und Empfänger als separate Rollen für dieselbe Entität (Benutzer) erstellen, aber versuchen wir, sie zu trennen, damit wir sehen können, wie man Beziehungen in LoopBack aufbaut. Der Name dieser bahnbrechenden Anwendung wird Givesomebody sein.

Installieren Sie die StrongLoop-Befehlszeilentools über npm:

 $ npm install -g strongloop

Führen Sie dann den Anwendungsgenerator von LoopBack aus:

 $ slc loopback _-----_ | | .--------------------------. |--(o)--| | Let's create a LoopBack | `--------- | application! | ( _U`_ ) '--------------------------' /___A___\ | ~ | __'.___.'__ ` |° Y ` ? What's the name of your application? Givesomebody

Lassen Sie uns ein Modell hinzufügen. Unser erstes Modell wird Gift heißen. LoopBack fragt nach der Datenquelle und der Basisklasse. Da wir die Datenquelle noch nicht eingerichtet haben, können wir db (memory) setzen. Die Basisklasse ist eine automatisch generierte Modellklasse, und wir wollen in diesem Fall PersistedModel verwenden, da es bereits alle üblichen CRUD-Methoden für uns enthält. Als Nächstes fragt LoopBack, ob das Modell über REST verfügbar gemacht werden soll (Ja), und gibt den Namen des REST-Dienstes an. Drücken Sie hier die Eingabetaste, um den Standardwert zu verwenden, der einfach der Plural des Modellnamens ist (in unserem Fall gifts ).

 $ slc loopback:model ? Enter the model name: Gift ? Select the data-source to attach Gift to: (Use arrow keys) ❯ db (memory) ? Select model's base class: (Use arrow keys) Model ❯ PersistedModel ? Expose Gift via the REST API? (Y/n) Yes ? Custom plural form (used to build REST URL):

Schließlich geben wir die Namen der Eigenschaften, ihre Datentypen und erforderliche/nicht erforderliche Flags an. Das Geschenk wird name und description haben:

 Let's add some Gift properties now. Enter an empty property name when done. ? Property name: name invoke loopback:property ? Property type: (Use arrow keys) ❯ string ? Required? (y/N)Yes

Geben Sie einen leeren Eigenschaftsnamen ein, um anzugeben, dass Sie mit der Definition der Eigenschaften fertig sind.

Der Modellgenerator erstellt zwei Dateien, die das Modell in common/models der Anwendung definieren: gift.json und gift.js . Die JSON-Datei gibt alle Metadaten über die Entität an: Eigenschaften, Beziehungen, Validierungen, Rollen und Methodennamen. Die JavaScript-Datei wird verwendet, um zusätzliches Verhalten zu definieren und Remote-Hooks zu spezifizieren, die vor oder nach bestimmten Operationen (z. B. Erstellen, Aktualisieren oder Löschen) aufgerufen werden sollen.

Die anderen beiden Modellentitäten sind unsere Spender- und Empfängermodelle. Wir können sie mit demselben Prozess erstellen, außer dass wir dieses Mal User als Basisklasse verwenden. Es gibt uns einige Eigenschaften wie username , password , email out of the box. Wir können beispielsweise nur den Namen und das Land hinzufügen, um eine vollständige Entität zu erhalten. Für den Empfänger möchten wir auch die Lieferadresse hinzufügen.

Projektstruktur

Werfen wir einen Blick auf die generierte Projektstruktur:

Die drei Hauptverzeichnisse sind: - /server – Enthält Knotenanwendungsskripte und Konfigurationsdateien. - /client – ​​Enthält .js, .html, .css und alle anderen statischen Dateien. - /common – Dieser Ordner ist sowohl dem Server als auch dem Client gemeinsam. Modelldateien gehen hier.

Hier ist eine detaillierte Aufschlüsselung des Inhalts der einzelnen Verzeichnisse aus der LoopBack-Dokumentation:

Beziehungen aufbauen

In unserem Beispiel müssen wir einige wichtige Beziehungen modellieren. Ein Spender kann viele Geschenke spenden, wodurch die Beziehung Spender viele Geschenke hat . Ein Empfänger kann auch viele Geschenke erhalten, also haben wir auch die Beziehung Empfänger hat viele Geschenke . Auf der anderen Seite gehört das Geschenk dem Spender und kann auch dem Empfänger gehören, wenn der Empfänger es annimmt. Lassen Sie uns dies in die Sprache von LoopBack übertragen.

 $ slc loopback:relation ? Select the model to create the relationship from: Donor ? Relation type: has many ? Choose a model to create a relationship with: Gift ? Enter the property name for the relation: gifts ? Optionally enter a custom foreign key: ? Require a through model? No

Beachten Sie, dass es kein durchgehendes Modell gibt; wir halten nur den Hinweis auf das Geschenk.

Wenn wir das obige Verfahren für Receiver wiederholen und zwei gehört zu Beziehungen zu Gift hinzufügen, werden wir unser Modelldesign auf einer Back-End-Seite durchführen. LoopBack aktualisiert automatisch die JSON-Dateien für die Modelle, um genau auszudrücken, was wir gerade durch diese einfachen Dialoge getan haben:

 // common/models/donor.json ... "relations": { "gifts": { "type": "hasMany", "model": "Gift", "foreignKey": "" } }, ...

Fügen Sie eine Datenquelle hinzu

Sehen wir uns nun an, wie Sie eine echte Datenquelle anhängen, um alle unsere Anwendungsdaten zu speichern. Für die Zwecke dieses Beispiels verwenden wir MongoDB, aber LoopBack verfügt über Module zur Verbindung mit Oracle, MySQL, PostgreSQL, Redis und SQL Server.

Installieren Sie zuerst den Connector:

 $ npm install --save loopback-connector-mongodb

Fügen Sie dann Ihrem Projekt eine Datenquelle hinzu:

 $ slc loopback:datasource ? Enter the data-source name: givesomebody ? Select the connector for givesomebody: MongoDB (supported by StrongLoop)

Der nächste Schritt besteht darin, Ihre Datenquelle in server/datasources.json zu konfigurieren. Verwenden Sie diese Konfiguration für einen lokalen MongoDB-Server:

 ... "givesomebody": { "name": "givesomebody", "connector": "mongodb", "host": "localhost", "port": 27017, "database": "givesomebody", "username": "", "password": "" } ...

Öffnen Sie schließlich server/model-config.json und ändern Sie die datasource für alle Entitäten, die wir in der Datenbank beibehalten möchten, in "givesomebody" .

 { ... "User": { "dataSource": "givesomebody" }, "AccessToken": { "dataSource": "givesomebody", "public": false }, "ACL": { "dataSource": "givesomebody", "public": false }, "RoleMapping": { "dataSource": "givesomebody", "public": false }, "Role": { "dataSource": "givesomebody", "public": false }, "Gift": { "dataSource": "givesomebody", "public": true }, "Donor": { "dataSource": "givesomebody", "public": true }, "Receiver": { "dataSource": "givesomebody", "public": true } }

Testen Ihrer REST-API

Es ist Zeit zu sehen, was wir bisher gebaut haben! Wir verwenden das großartige integrierte Tool API Explorer , das als Client für den gerade erstellten Dienst verwendet werden kann. Lassen Sie uns versuchen, REST-API-Aufrufe zu testen.

Starten Sie MongoDB in einem separaten Fenster mit:

 $ mongod

Führen Sie die Anwendung aus mit:

 $ node .

Gehen Sie in Ihrem Browser zu http://localhost:3000/explorer/ . Sie können Ihre Entitäten mit der Liste der verfügbaren Operationen sehen. Versuchen Sie, einen Spender mit einem POST /Donors -Anruf hinzuzufügen.

API Explorer ist sehr intuitiv; Wählen Sie eine der angezeigten Methoden aus, und das entsprechende Modellschema wird in der unteren rechten Ecke angezeigt. Im data ist es möglich, einen benutzerdefinierten HTTP-Request zu schreiben. Sobald die Anfrage ausgefüllt ist, klicken Sie auf die Schaltfläche „Ausprobieren“, und die Antwort des Servers wird unten angezeigt.

Benutzerauthentifizierung

Wie oben erwähnt, ist eine der mit LoopBack vorgefertigten Entitäten die User-Klasse. Der Benutzer verfügt über Anmelde- und Abmeldemethoden und kann an eine AccessToken-Entität gebunden werden, die das Token des jeweiligen Benutzers behält. Tatsächlich ist ein vollständiges Benutzerauthentifizierungssystem sofort einsatzbereit. Wenn wir versuchen, /Donors/login über API Explorer aufzurufen, erhalten wir folgende Antwort:

 { "id": "9Kvp4zc0rTrH7IMMeRGwTNc6IqNxpVfv7D17DEcHHsgcAf9Z36A3CnPpZJ1iGrMS", "ttl": 1209600, "created": "2015-05-26T01:24:41.561Z", "userId": "" }

Die id ist eigentlich der Wert des AccessToken, der automatisch generiert und in der Datenbank gespeichert wird. Wie Sie hier sehen, ist es möglich, ein Zugriffstoken festzulegen und es für jede nachfolgende Anfrage zu verwenden.

Remote-Methoden

Eine Remotemethode ist eine statische Methode eines Modells, die über einen benutzerdefinierten REST-Endpunkt verfügbar gemacht wird. Remote-Methoden können verwendet werden, um Vorgänge auszuführen, die nicht von LoopBacks Standardmodell-REST-API bereitgestellt werden.

Neben den CRUD-Methoden, die wir standardmäßig erhalten, können wir so viele benutzerdefinierte Methoden hinzufügen, wie wir möchten. Alle von ihnen sollten in die Datei [model].js werden. In unserem Fall fügen wir dem Gift-Modell eine Remote-Methode hinzu, um zu prüfen, ob das Geschenk bereits reserviert ist, und eine, um alle nicht reservierten Geschenke aufzulisten.

Zuerst fügen wir dem Modell eine zusätzliche Eigenschaft namens reserved hinzu. Fügen Sie dies einfach zu den Eigenschaften in gift.json :

 ... "reserved": { "type": "boolean" } ...

Die Remote-Methode in gift.js sollte etwa so aussehen:

 module.exports = function(Gift) { // method which lists all free gifts Gift.listFree = function(cb) { Gift.find({ fields: { reserved: false } }, cb); }; // expose the above method through the REST Gift.remoteMethod('listFree', { returns: { arg: 'gifts', type: 'array' }, http: { path: '/list-free', verb: 'get' } }); // method to return if the gift is free Gift.isFree = function(id, cb) { var response; Gift.find({ fields: { id: id } }, function(err, gift) { if (err) return cb(err); if (gift.reserved) response = 'Sorry, the gift is reserved'; else response = 'Great, this gift can be yours'; }); cb(null, response); }; // expose the method through REST Gift.remoteMethod('isFree', { accepts: { arg: 'id', type: 'number' }, returns: { arg: 'response', type: 'string' }, http: { path: '/free', verb: 'post' } }); };

Um herauszufinden, ob ein bestimmtes Geschenk verfügbar ist, kann der Client nun eine POST-Anfrage an /api/Gifts/free senden und die id des betreffenden Geschenks übergeben.

Remote-Hooks

Manchmal muss eine Methode vor oder nach der Remote-Methode ausgeführt werden. Sie können zwei Arten von Remote-Hooks definieren:

• beforeRemote() wird vor der Remote-Methode ausgeführt.
• afterRemote() wird nach der Remote-Methode ausgeführt.

In beiden Fällen geben Sie zwei Argumente an: einen String, der der entfernten Methode entspricht, an die Sie Ihre Funktion „hängen“ möchten, und die Callback-Funktion. Ein Großteil der Leistungsfähigkeit von Remote-Hooks besteht darin, dass die Zeichenfolge Platzhalter enthalten kann, sodass sie von jeder übereinstimmenden Methode ausgelöst wird.

Lassen Sie uns in unserem Fall einen Haken setzen, um Informationen an die Konsole zu drucken, wenn ein neuer Spender erstellt wird. Um dies zu erreichen, fügen wir einen „before create“-Hook in „ donor.js “ hinzu:

 module.exports = function(Donor) { Donor.beforeRemote('create', function(context, donor, next) { console.log('Saving new donor with name: ', context.req.body.name); next(); }); };

Die Anfrage wird mit dem gegebenen context aufgerufen, und der next() Callback in der Middleware (siehe unten) wird aufgerufen, nachdem der Hook ausgeführt wurde.

Zugriffskontrollen

LoopBack-Anwendungen greifen über Modelle auf Daten zu, sodass die Kontrolle des Zugriffs auf Daten bedeutet, Einschränkungen für Modelle zu definieren; Das heißt, es wird festgelegt, wer oder was die Daten lesen und schreiben oder Methoden auf den Modellen ausführen kann. LoopBack-Zugriffskontrollen werden durch Zugriffskontrolllisten oder ACLs bestimmt.

Erlauben wir nicht eingeloggten Spendern und Empfängern, Geschenke anzuzeigen, aber nur eingeloggten Spendern, sie zu erstellen und zu löschen.

 $ slc loopback:acl

Lassen Sie uns zunächst allen den Zugriff auf alle Endpunkte verweigern.

 ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: All (match all types) ? Select the role: All users ? Select the permission to apply: Explicitly deny access

Erlauben Sie als Nächstes allen, von Geschenkmodellen zu lesen:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Read ? Select the role: All users ? Select the permission to apply: Explicitly grant access

Dann möchten wir authentifizierten Benutzern erlauben, Geschenke zu erstellen:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: A single method ? Enter the method name: create ? Select the role: Any authenticated user ? Select the permission to apply: Explicitly grant access

Und schließlich erlauben wir dem Besitzer des Geschenks, Änderungen vorzunehmen:

 $ slc loopback:acl ? Select the model to apply the ACL entry to: Gift ? Select the ACL scope: All methods and properties ? Select the access type: Write ? Select the role: The user owning the object ? Select the permission to apply: Explicitly grant access

Wenn wir jetzt gift.json überprüfen, sollte alles vorhanden sein:

 "acls": [ { "accessType": "*", "principalType": "ROLE", "principalId": "$everyone", "permission": "DENY" }, { "accessType": "READ", "principalType": "ROLE", "principalId": "$everyone", "permission": "ALLOW" }, { "accessType": "EXECUTE", "principalType": "ROLE", "principalId": "$authenticated", "permission": "ALLOW", "property": "create" } ],

Ein wichtiger Hinweis hier: $authenticated ist eine vordefinierte Rolle, die allen Benutzern im System (sowohl Spendern als auch Empfängern) entspricht, aber wir möchten nur Spendern erlauben, neue Geschenke zu erstellen. Daher benötigen wir eine benutzerdefinierte Rolle. Da Role eine weitere Entität ist, die wir aus der Box bekommen, können wir ihren API-Aufruf nutzen, um die Rolle $authenticatedDonor in der Boot-Funktion zu erstellen, und dann einfach pricipalId in gift.json .

Es ist notwendig, eine neue Datei server/boot/script.js zu erstellen und den folgenden Code hinzuzufügen:

 Role.create({ name: 'authenticatedDonor' }, function(err, role) { if (err) return debug(err); })

Die RoleMapping-Entität ordnet Rollen Benutzern zu. Stellen Sie sicher, dass Role und RoleMapping beide über REST verfügbar gemacht werden. Überprüfen Sie in server/model-config.json , ob "public" für die Rollenentität auf „ true “ gesetzt ist. Dann können wir in der Datei „ donor.js “ einen „before create“-Hook schreiben, der die userID und die roleID im RoleMapping POST API-Aufruf zuordnet.

Middleware

Middleware enthält Funktionen, die ausgeführt werden, wenn eine Anfrage an den REST-Endpunkt gestellt wird. Da LoopBack auf Express basiert, verwendet es Express-Middleware mit einem zusätzlichen Konzept, das als „Middleware-Phasen“ bezeichnet wird. Phasen werden verwendet, um die Reihenfolge klar zu definieren, in der Funktionen in der Middleware aufgerufen werden.

Hier ist die Liste der vordefinierten Phasen, wie in den LoopBack-Dokumenten bereitgestellt:

1. initial – Der erste Punkt, an dem Middleware ausgeführt werden kann.
2. session - Bereiten Sie das Sitzungsobjekt vor.
3. auth - Behandelt die Authentifizierung und Autorisierung.
4. parse - Analysiert den Anforderungstext.
5. routen – HTTP-Routen, die Ihre Anwendungslogik implementieren. Über die Express-API app.use, app.route, app.get (und andere HTTP-Verben) registrierte Middleware wird zu Beginn dieser Phase ausgeführt. Nutzen Sie diese Phase auch für Sub-Apps wie Loopback/Server/Middleware/Rest oder Loopback-Explorer.
6. files - Stellt statische Assets bereit (Anfragen treffen hier auf das Dateisystem).
7. final - Umgang mit Fehlern und Anfragen für unbekannte URLs.

Jede Phase hat drei Unterphasen. Die Unterphasen der Anfangsphase sind beispielsweise:

1. initial: vorher
2. Initial
3. anfänglich: nach

Werfen wir einen kurzen Blick auf unsere standardmäßige middleware.json:

 { "initial:before": { "loopback#favicon": {} }, "initial": { "compression": {}, "cors": { "params": { "origin": true, "credentials": true, "maxAge": 86400 } } }, "session": { }, "auth": { }, "parse": { }, "routes": { }, "files": { }, "final": { "loopback#urlNotFound": {} }, "final:after": { "errorhandler": {} } }

In der Anfangsphase rufen wir loopback.favicon() auf ( loopback#favicon ist die Middleware-ID für diesen Aufruf). Dann werden die npm-Module von Drittanbietern compression und cors aufgerufen (mit oder ohne Parameter). In der Endphase haben wir noch zwei Calls. urlNotFound ist ein LoopBack-Aufruf und errorhandler ist ein Modul eines Drittanbieters. Dieses Beispiel soll zeigen, dass viele eingebaute Aufrufe genauso wie die externen npm-Module verwendet werden können. Und natürlich können wir jederzeit unsere eigene Middleware erstellen und sie über diese JSON-Datei aufrufen.

loopback-boot

Lassen Sie uns zum Abschluss ein Modul erwähnen, das die Funktion boot() exportiert, die die Anwendung initialisiert. In server/server.js finden Sie den folgenden Code, der die Anwendung bootet:

 boot(app, __dirname, function(err) { if (err) throw err; // start the server if `$ node server.js` if (require.main === module) app.start(); });

Dieses Skript durchsucht den server/boot Ordner und lädt alle dort gefundenen Skripte in alphabetischer Reihenfolge. Daher können wir in server/boot jedes Skript angeben, das beim Start ausgeführt werden soll. Ein Beispiel ist explorer.js , das API Explorer ausführt , den Client, den wir zum Testen unserer API verwendet haben.

Fazit

Bevor ich Sie verlasse, möchte ich StrongLoop Arc erwähnen, eine grafische Benutzeroberfläche, die als Alternative zu slc -Befehlszeilentools verwendet werden kann. Es enthält auch Tools zum Erstellen, Profilieren und Überwachen von Node-Anwendungen. Für diejenigen, die keine Fans der Kommandozeile sind, ist dies definitiv einen Versuch wert. StrongLoop Arc wird jedoch bald eingestellt und seine Funktionalität wird in das IBM API Connect Developer Toolkit integriert.

Im Allgemeinen kann LoopBack Ihnen viel manuelle Arbeit ersparen, da Sie eine Menge Dinge aus der Box bekommen. Es ermöglicht Ihnen, sich auf anwendungsspezifische Probleme und Geschäftslogik zu konzentrieren. Wenn Ihre Anwendung auf CRUD-Operationen basiert und vordefinierte Entitäten manipuliert, wenn Sie es satt haben, die Authentifizierungs- und Autorisierungsinfrastruktur des Benutzers neu zu schreiben, wenn Tonnen von Entwicklern dies vor Ihnen geschrieben haben, oder wenn Sie alle Vorteile eines großartigen Web-Frameworks wie nutzen möchten Express, dann kann der Aufbau Ihrer REST-API mit LoopBack Ihre Träume wahr werden lassen. Es ist ein Stück Kuchen!