Das Anbieten von APIs ist längst nicht mehr nur ein nice-to-have-Feature einer Applikation; für viele ist es gar der Hauptbestandteil Ihres Business-Modells geworden. Doch was genau bedeutet das eigentlich?

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.

Genau diesem Thema widmet sich der API Summit, der am 22. und 23. November 2016 in Berlin stattfinden wird, und sich in insgesamt vier Tracks – Architektur, .NET, Java und NodeJS – mit allem beschäftigt, was im Bereich der Entwicklung und Bereitstellung von APIs zu beachten ist.

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.

Vue, Vite,Vitest

Explore Vitest, the JavaScript testing framework built for Vite, with React, Vue, and Node.js support plus modern features like ECMAScript modules.

Download for free

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?

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

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.

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 …

Auf dem API Summit bist du der Chair des NodeJS-Tracks, was vor allem in deinen Cross-Plattform-Bemühungen begründet sein dürfte. Wo unterstützt NodeJS die API-Story besonders?

.NET hat mir Web API beispielsweise schon lange aufgeholt.

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.

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.

Gib uns doch mal einen kleinen Ausblick darauf, was die Besucher des API Summits im NodeJS-Track erwartet.

Christian: Wir werden behandeln, wie man mit NodeJS pragmatische Web APIs entwickelt; und wir haben es extra nicht REST-APIs genannt!

Wir werden uns ansehen, wie man mit einer Programmiersprache sowohl serverseitige Web APIs als auch clientseitige Applikationen mit TypeScript entwickeln kann. Ein Framework wie zum Beispiel Angular 2 setzt ja sehr stark auf TypeScript, und wir haben Projekte, in denen wir die Serverseite nicht mehr historischerweise in .NET bauen – also mit der Technologie, aus der wir ursprünglich herkommen – sondern mit NodeJS und mit TypeScript, während der Client mit Angular 2 und TypeScript entwickelt wird. So haben wir das gleiche Tooling, die gleiche Sprache und teilweise sogar vielleicht den einen oder anderen Teil Code, den wir zwischen beiden Bereichen sharen können.

Weiterhin werden wir uns ansehen, wie man mit NodeJS wirklich „großen Code“ schreiben kann, der dann auch skalieren kann – ein extrem wichtiges Thema. Wir beschäftigen uns mit der Thematik der Realtime-Kommunikation, also Push-Kommunikation, WebSockets oder nicht, HTTP Long-polling, etc. Welche Optionen existieren, wie wirkt sich das in der Praxis aus und wie lässt es sich in NodeJS implementieren?

Zusätzlich haben wir ein spezielles Architekturpattern, das ja auch heiß diskutiert wird: CQRS – Command Query Responsibility Segregation. Hier wird uns Golo Roden einen Praxisbericht mit Best Practices aus einigen seiner Projekte geben.

Last but not least mein Lieblingsthema von einer Kollegin von Thoughtworks – dabei geht es um Offline-First-Architekturen. Ein wichtiges Thema, denn je mobiler man ein System entwickelt, und je mehr Architekturen man für mobile Endgeräte baut, desto mehr muss man den Offline-Gedanken denken. Es wird nie so weit sein, dass wir wirklich immer voll online sind oder vollständig online gehen wollen. Das heißt, wenn man Daten mitnehmen muss und unterwegs bearbeitet oder neue Daten anlegt oder Daten verändert, die man vorher online geholt hat und im offline-Zustand speichert, gibt es ganz spezielle Architekturansätze und Dinge zu beachten, die komplett anders funktionieren, als wenn man davon ausgeht, dass man immer online ist.

Christian Weyer

Christian Weyer ist Gründer und Vorstand der Thinktecture AG sowie Google GDE (Developer Expert) und Microsoft MVP (Most Valuable Professional). Er spricht seit knapp zwei Dekaden auf unterschiedlichsten Softwarekonferenzen und -events weltweit – mit Leidenschaft und Engagement.