Unternehmens-APIs mit Microservices
Seite 2: Option 1: Zusammenlegen der beiden Services
In obigem Beispiel sollte man zunächst überlegen, ob das Zerteilen der Services mit dem Setup überhaupt Sinn ergibt. Schließlich setzt man auf Microservices, um unabhängige Deploybarkeit zu erreichen und dadurch schneller zu werden. Koppelt man aber nun die beiden APIs wieder eng aneinander und lässt die eigentlichen Services trotzdem getrennt, läuft man schnell Gefahr, dass man einen verteilten Monolithen baut. Nicht umsonst gehen bei Ansätzen wie Self-Contained Systems die Tendenzen eher dahin, größere Deployables zu haben. Auf einer Infoseite zum Thema sprechen die Autoren beispielsweise von 5-25 Services für einen kompletten Onlineshop.
Nachteil der Zusammenlegung ist, dass es nicht vollkommen freigestellt ist, den Service weiter zu vergrößern. Spätestens, wenn Entwickler einen Service über Teamgrenzen hinweg betreiben, wird es schwierig. Man mutet dem Kunden damit zu, eine handvoll APIs zu kennen.
Im Beispielfall lassen sich beide Services in eine Komponente legen und damit die Trennung aufheben. Der "article"-Endpunkt der neuen API enthält dann sowohl Artikelinhalt als auch die Gesamtbewertungen und "rating"-Links. Damit ergibt sich der Vorteil, dass Routing, Versionshandling und Authentifizierung nachvollziehbar in einer Komponente liegen. Auch die Dokumentation korrespondiert 1:1 mit einer Komponente.
