Close

8. Mai 2017

Loopback – REST-Apis mit Turbo-Express

REST-APIs sind ein häufiger Begriff, wenn es um SinglePage Applications oder Apps geht. Jedes größere Unternehmen und natürlich die global player Facebook, Google, Twitter, GitHub, usw. bieten für ihre Services REST APIs an. Häufig hört man hier Express, wenn es auf Node.js basieren soll.

Eine REST-API basiert auf dem grundsätzlichen Prinzip HTTP bestmöglich zu nutzen. Das bedeutet Ressourcen hinter Endpunkten (APIURL/endpunkt) zu bündeln und diese soweit möglich filterbar zu gestalten. Für kleinere Services kann dies schnell anstrengend werden, möchte man in aller Regel schnell starten und wenig Boilerplate Code für APIs schreiben müssen. Hier kommt Loopback von Strongloop ins Spiel, ein 2015 von IBM gekauftes Startup, das Express (eines der beliebtesten HTTP-Frameworks im NodeJS Umfeld) maßgeblich gesponsert hat und sein Produkt Loopback auch darauf basieren lässt.

TL;DR

Loopback ermöglicht es, ohne besonderen Aufwand Basic-REST APIs mit Relationen, Datenstrukturen und User-Authentifizierung, sowie Berechtigungsmanagement mit nicht viel mehr als Konfiguration aufzusetzen.

Was ist Loopback?

Loopback ist ein Framework, welches auf Express aufsetzt und die Erstellung von REST APIs mit verschiedenen Datenquellen vereinfacht und einige Standard-Komponenten ausliefert. Dies umfasst Authorisierung inkl. OAuth 2 und SingleSign On Lösungen wie Facebook, Google und Twitter Auth, CRUD Operationen, Relation Building und Mapping, E-Mail Management und Permission & ACL Management.

Wie beginne ich?

Natürlich; die NPM CLI installieren, am besten global:

npm install -g loopback-cli

Und dann ein Projekt aufsetzen, Loopback liefert hier schon Boilerplates mit:

lb

Hier startet nun ein Yeoman Generator, der mit einigen Fragen eine funktionale REST-API auf Express-Basis mit User-Authentifizierung für euch aufsetzt. Schon ganz nett, aber viel kann sie noch nicht.

Datenstrukturen

Was wäre eine API ohne Daten. Und was wären Daten ohne Struktur? Anyway; es würde etwas fehlen!

Datenstrukturen inkludieren, neben dem eigentlichen Aufbau der Daten, primär auch Relationen, im weiteren Sinne ACLs. Kurzum; Daten zu modellieren ist ein Kernbestandteil der API-Entwicklung. Zum Modelling gehört im weitesten Sinne auch die Datenbank-Anbindung.

Auf den Kopf gestellt beginnen wir mit der DB-Anbindung. Loopback bringt hier ein Konzept namens Datesource-Juggling mit, welches neben klassischem ORM/ODM die Datenquelle im Hintergrund abstrahiert. Das geht soweit, dass der Datasource-Juggler auch Datenquellen, wie fremde REST-APIs, E-Mail als Datenquelle und Filesystem in das Konzept integriert.

Standardmäßig bringt Loopback eine In-Memory Datenbank mit, die für die Entwicklung ausreichend ist. Wie weitere Datenquellen angelegt werden können, kann in der Dokumentation unter http://loopback.io/doc/en/lb3/Connecting-models-to-data-sources.html detailliert nachgeschlagen werden, hier existiert auch eine Liste unterstützter (durch Strongloop oder Third-Parties) Conncetoren.

Models

Nachdem wir nun eine Datenquelle haben, begeben wir uns auf Model-Ebene. Ein Model stellt eine Beschreibung der Datenstruktur einer einzelnen Entity dar. Konzeptuell wäre ein Model also ein Auto, ein Baum oder eine Pflanze.

Mittels

lb model

können wir ein Model mittels CLI erzeugen. Der Generator hier erzeugt eine Struktur mit Datentypen nach dem Step-by-Step Prinzip.

Im Standard-Setup werden Models als .js und .json Files unter common/models (für isomorphe Models, das sollte die meist genutzte Eigenschaft sein), bzw. server/models (für Server-Only Entities) angelegt.

Die Definition der Models ist primär JSON-gesteuert, jedes neue Model repräsentiert einen zusätzlichen Endpunkt nach Model-Namen in Plural-Form.

Falls zusätzliche Logik nötig sein sollte, kann diese dann im Model.js in Form von Hooks und Events (z.B. beforeSave, beforeRemote) implementiert werden. Standard-CRUD implementiert Loopback hierbei bereits mit einer an MongoDB angelehnten Filter-API, sowohl für Server-, Client- als auch REST-Nutzung via HTTP. Mittels Plugins bzw. Middleware kann übrigens aus einer Loopback-API auch eine GraphQL API werden.

Relationen

Was wären einzelne Entities ohne Verknüpfung? Auch fad! Loopback bringt daher auch ein Relation-Mapping mit, das entweder via Generator

lb relation

oder via Model.json und auch Model.js definiert werden kann.

Hierbei existieren alle gängigen und notwendigen Relation-Typen (u.a. BelongsTo, HasMany, HasManyThrough und HasAndBelongsToMany (jeweils verlinkt zur Loopback-Dokumentation)) die jeweils vom Model zu einem anderen Model definiert werden können. Zu beachten ist hierbei der semantische Unterschied von HasMany und HasAndBelongsToMany. Praktisch ausgedrückt heißt das; HasMany verlinkt immer zu einer Instanz eines anderen Models (und erzeugt einen ID-Key auf diesem Model), während HasAndBelongsToMany zu bestehenden Models kompatibel ist und diese in einer weiteren Collection bzw. Tabelle verlinkt (aka ModelA2ModelB).

Weiterführendes

Weiterführend bietet Loopback die Möglichkeit ACLs zu definieren und damit Zugriffsrechte zu steuern. Ebenso können Remote-Methods entfernt oder zusätzliche implementiert werden. Falls Interesse daran besteht schreibe ich zu gegebener Zeit einen zusätzlichen Blog-Post dazu 😉

Am besten ist aber immer; einfach ausprobieren!

Zum Weiterlesen…

 

Bild bearbeitet von VIKTOR HANACEK (https://picjumbo.com/seaside-rocks-sunset)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.