Seite 3: Option 2: API-Gateway

Inhaltsverzeichnis

Sollte die Überarbeitung des Schnitts keine Option sein, bleibt immer noch die Möglichkeit, vor die Mircroservices einen API-Service zu stellen, der das Mapping der Sprache aller Microservices auf die API-Sprache übernimmt. Routing und Versionsmanagement sind damit auch erschlagen. In gewisser Hinsicht gelten auch hier die Einschränkungen aus Option 1, jedoch mit einer entscheidenden Änderung.

Denn natürlich spricht man an den Services "nach hinten" auch REST (inklusive HATEOAS) – somit ist die eigentliche Businesslogik kapselbar. Der Backend-Service gibt über das Schema ebenfalls aus, was er genau erwartet und was er ausliefert. Somit bleiben nur bestimmte feste Transformationen der Schemata und Relationen, die im API-Service fest sind. Sie sind für gewöhnlich dokumentiert und dürfen sich deshalb nicht ändern.

Bei einem Breaking Change eines beteiligten Service ist klar, dass man unter Umständen den betreffenden Microservice und die API releasen muss. Man hat zusätzlich noch die Möglichkeit, die Änderung vor den Kunden zu verbergen, indem der API-Service sie abfedert. Dies bedeutet im Zweifelsfalle aber mehr Aufwand. Ein weiterer Vorteil wäre, dass es möglich ist, unterschiedliche Microservices zu neuen APIs zusammenzusetzen.

Der Nachteil ist, dass solche Services über Teamgrenzen hinweg problematisch sind, wie ein Erfahrungsbericht von Netflix eindrucksvoll beschreibt. Wenn die einzelnen Microservices auch von außerhalb der Organisation erreichbar sind, bezeichnet man die Konstellation gerne als Backend-For-Frontend. Die generelle Erreichbarkeit der Backend-Services von Außen ist aber eigentlich nicht erforderlich. Sie führt allerdings meist zu besserem Code, da sich auch der Entwickler in "zweiter Reihe" Gedanken machen muss, wie der Kunde seinen Service benutzt. Somit hilft ein solcher Aufbau dabei, reine CRUD-Services (Create, Read, Update and Delete) von vornherein zu vermeiden. Im allgemeinen Fall wird der API-Service als API-Gateway bezeichnet.

Am konkreten Beispiel sieht ein API-Gateway so aus: Es gibt einen API-Service C. Dieser liefert unter C/articles/{id} den Payload von Service A aus, ergänzt aber dort einen "ratings"-Link, den er von Service B holt. Dabei schreibt er allerdings die URL auf seine eigene C/articles/{id}/ratings-URL um. Er übernimmt außerdem das Schema von B. Dazu muss er wissen, wie er bei Service B an die "ratings"-Links für einen Artikel kommt.

Das geschieht, indem er von der Root-Ressource von B den Template-Link "article" entsprechend ausfüllt und von dort den "ratings"-Link nimmt. Die API C kann sich, was Rechte und Schemata betrifft, komplett am Service B orientieren und beispielsweise cachen. Es wäre auch vorstellbar, dass die API immer die Gesamtbewertungen als Teil des Artikels sieht. Es wäre somit für C problemlos möglich, sie zum eigentlichen Payload von A vor der Auslieferung hinzuzufügen.