Wer in der Cloud mit SaaS erfolgreich sein will, muss ein modernes Web API als integralen Bestandteil seiner Lösung anbieten. Solche APIs sind schon lange kein unwichtiges Detail mehr; für viele Unternehmen ist die Qualität der APIs zu einem wichtigen Auswahlkriterium geworden. Das Web API ist eine bedeutsame Produktfunktion, der genauso viel Aufmerksamkeit im Hinblick auf Gestaltung, Tests, Dokumentation, Support und Produktpräsentation gewidmet wird wie anderen Aspekten der Software – und das über alle Sprachen hinweg.

A Web API to rule them all

Nun ist es so, dass APIs noch immer von vielen Entwicklern unterschätzt werden. Dabei bietet gerade eine Plattform wie NodeJS einige Vorteile, die man sich zu Nutze machen sollte.

Wir haben daher die Gelegenheit genutzt und mit dem Chair des NodeJS-Tracks, Christian Weyer, über das Geschäftsmodell API, NodeJS und einige andere Themen gesprochen.

Christian, das Geschäftsmodell von Applikationen hat sich in den letzten Jahren stark verändert. Früher waren (Public) APIs eher eine Ausnahme – heute gehört es zum Kerngeschäft des Business. Was hat sich deiner Meinung nach geändert?

Es geht nicht nur um Änderungen im Geschäftsmodell, sondern auch um allgemeine Änderungen im Bereich der Architekturen.

Christian Weyer: Ich würde sogar noch einen Schritt weiter gehen wollen: Es geht nicht nur um Änderungen im Geschäftsmodell, sondern auch um allgemeine Änderungen im Bereich der Architekturen. Nicht jeder wird eine Public API besitzen; viele Unternehmen mit denen wir arbeiten, die meisten kommen aus dem klassischen .NET-Umfeld, benötigen APIs für ihre eigene Software. Diese APIs sind nicht public, haben jetzt also nicht unbedingt eine direkte Auswirkung auf das Geschäftsmodell, dafür aber auf die Architektur der Software, die von den Kunden entwickelt wird.

Das bedeutet natürlich, dass man weg muss von diesen Monolithen und den geschlossenen DLLs und geschlossenen Systemen, hin zu API-basierten Systemen, die man entsprechend absichern muss, damit sie nicht von unbefugten genutzt werden können.

Was ist deiner Meinung nach die größte oder interessanteste Änderung im Bereich der Architektur? Reden wir von eventgetriebenen Architekturen, bewegen wir uns eher in Richtung Microservices? Oder ist es eine Mischung aus allem?

Christian: Na ja, vieles ist eigentlich nur Buzzword-Bingo, alter Wein in neuen Schläuchen. Die Diskussion rund um Microservices kann man sich ja beispielsweise schon gar nicht mehr anhören …

Für viele Softwareentwickler und für viele Softwarefirmen ist es momentan einfach noch immer ein notwendiger Schritt, überhaupt erstmal von einem Monolithen, von einer lokalen, von einer Two-Tier-Architektur wegzukommen. Jeder fordert von vornherein Mobile Apps – die Anwendung muss auf dem iPad laufen, auf dem Windows-Tablet, es muss im Browser funktionieren … aber die existierenden Anwendungen, sei es Java oder .NET, sind halt doch sehr „gewachsen“ und haben meistens Schnittstellen, die nur in der jeweiligen Plattform implementiert wurden. Also DLLs in .NET oder JARs oder WARs in Java.

Um jetzt aber wirklich einen Schritt in Richtung verteilte Anwendungen zu gehen, bei denen man über das Internet, über potenziell unsichere Verbindungen auf Daten zugreifen kann oder muss, muss sich natürlich irgendwie die Zielarchitektur ändern; und dafür benötigt man APIs.

Früher hat man versucht, das über SOAP und Web Services zu realisieren, aber der Zug ist schon lange abgefahren; vor allem, wenn es um Mobile oder das Web geht. Dafür braucht man leichtgewichtige Architekturansätze.

An dieser Stelle möchte ich einen kleinen Exkurs machen: Auf der GitHub Universe hat GitHub das erste öffentliche GraphQL API vorgestellt. Ist das – also GraphQL – der Weg, der in Zukunft aufzeigt?

Christian: GraphQL ist momentan in aller Munde und wird sehr gehyped, nur weil Facebook und Co es Open Source gestellt und die Spezifikation veröffentlicht haben. Am Ende des Tages ist GraphQL jedoch wieder nur so etwas Ahnliches, wie es Microsoft schon vor Jahren mit OData gemacht hat. Für bestimmte Use Cases und für bestimmte Projekte, vor allem für öffentliche APIs, ist es mit Sicherheit gut. Aber für geschlossene Business-APIs sehe ich es eher als kritisch an, weil man Use Cases in Business-Anwendungen im vornherein kennen und definieren muss, und da auch eine explizit definierte API zur Verfügung stellen sollte.

Am Ende macht man SQL in SOA – und das ist nicht das, was man machen möchte …

Wenn man eine sehr offene und über GraphQL oder über OData fast beliebig penetrier- und abfragbares API zur Vefügung stellst … da habe ich immer ein leicht schwindeliges Architekturgefühl dabei. Das endet irgendwann in SQL über SOA, und das ist nicht das, was man eigentlich machen möchte …

Wo unterstützt NodeJS die API-Story besonders?

Christian: Du kommst mit relativ schnell mit relativ wenig Aufwand – also faktisch mit wenigen Zeilen Code – ans Ziel. Um ein simples Web API zu entwickeln, musst man sehr wenig Arbeit investieren.

.NET hat mir Web API beispielsweise schon lange aufgeholt.

Die anderen Frameworks haben da natürlich schon lange aufgeholt: .NET mit Web API, und auch in der Java-Welt gibt es entsprechende Implementierungen dafür. Aber dieser leichtgewichtige Architekturansatz ist eben auch im Core von NodeJS zu finden. Es gibt da beispielsweise Frameworks wie restify, mit denen man mit wenig Aufwand ein einfaches Web-API hochziehen kann.

Darüber hinaus gilt: Node läuft einfach überall. Das macht Java auf dem Server zwar auch, aber mit einem etwas anderen Footprint. .NET Core möchte das irgendwann auch mal können, aber momentan tut man sich damit ein wenig schwer …

NodeJS macht das nun schon seit Jahren. Es läuft auf Linux, es läuft auf Windows, auf Mac OS, es läuft einfach überall. Und es ist mittlerweile überall Voraussetzung für jede Entwicklungsumgebung, für jedes Toolkit, für jedes noch so kleine Framework.

Da kommen wir aber schon zum nächsten Problem – gerade vor Kurzem wurde die LTS-Version abgelöst. Dieses schnelllebige, diese schnellen Versionsänderungen mit zum Teil Breaking Changes – kann das nicht zu einem Problem werden für das Geschäftsmodell eines stabilen API?

Christian: Absolut. Jedes Mal, wenn ein neues Major Release kommt – am besten noch mit Breaking Changes – sollte man aufmerksam werden. Aber ganz ehrlich: man muss ja nicht jedes Mal upgraden! Irgendwann einmal muss man einen Cut machen und sagen: Jetzt, in Production, bleibe ich auf genau dieser Version. Das ist ja immer so, wir sehen das ja jetzt auch bei .NET Core und Microsoft: Die werden wohl auch in Monats- oder Quartalsabständen irgendwelche Updates veröffentlichen.

… das ist ja aber eine Sache, die für euch aus dem klassischen Microsoft-Umfeld eher neu ist, oder?

Christian: Die ist für uns nicht wirklich neu, im Frontend-Bereich war es ja schon immer so. Ich habe gerade heute erst erwähnt [das Interview wurde auf der BASTA! in Mainz aufgenommen, Anm. d. Red.], dass ich diesen Web-API-Talk hier auf BASTA! seit fünf Jahren mit dem gleichen Inhalt halte – einen UI-Client-Framework-Talk könnte ich keine fünf Jahre halten, denn ein Framework aus diesem Bereich wird nicht so lange existieren.