Auf dem API Summit 2017 in Berlin vermitteln die bedeutendsten deutschsprachigen API-Experten tiefgehendes Know-how zu plattformunabhängigen Best Practices und Standards sowie zur Implementierung und Betrieb von Web APIs mit Node. js, .NET und Java. Manuel Rauber (Thinktecture) stellt sich im Interview mit Mirko Hillert auf dem API Summit 2017 in Berlin allen relevanten Fragen rund um Node.js.
Mirko Hillert: Du hältst zusammen mit Sven Kölpin den Workshop zum Thema „Moderne Web-APIs mit Node.js“. Was erwartet die Teilnehmer in dem Workshop?
Manuel Rauber: Wir werden grundsätzlich erst einmal den typischen Einblick in die Web-API-Welt geben und erklären, was wir darunter verstehen, da es viele Begriffe gibt, die dazu in der Welt herumschwirren. Wir erklären, was überhaupt hinter Begriffen wie Web-API und Microservices steckt.
Damit das API nicht ganz so nüchtern dasteht, haben wir auch ein kleines Frontend in Form eines Twitter-Clients mitgebracht. Wir gehen also ein wenig darauf ein, nicht nur Microservices, sondern dazu auch ein passendes Micro-Frontend zu bauen. Wie dort die Welt ausschaut, macht einen ganz kleinen Part des Workshops aus. Im Großen und Ganzen geht es dann darum, Web-APIs mit Node.js von der Pike auf mit dem ersten Controller und dem ersten Service zu bauen.
Wir schauen uns an, wie man es mit einer Datenbank verbinden kann und wie man am besten auf Realtimesachen eingeht, um zum Beispiel Push Notifications an die Clients rausschicken, damit diese bei einer Änderung sofort informiert werden. Das kennt man zum Beispiel von Twitter: Jemand macht einen neuen Tweet und man möchte diese Änderung sofort mitbekommen. Wie kann man das mit einer auf Realtimeevents spezialisierten Datenbank realisieren?
Das wird so ungefähr der Umfang des Workshops sein. Ich bin schon sehr gespannt.
Mirko Hillert: Zu eurem Workshop wird es noch drei parallel laufende Workshops geben, die sich mit der Entwicklung von APIs mit Java, .NET und Node.js beschäftigen. Ihr fokussiert euch auf Node.js. Was sind die Stärken von Node.js bei der Entwicklung von Web-APIs?
Manuel Rauber: Wir haben es eben schon mal gehört: Das Stichwort Realtime fiel ziemlich oft. Das heißt, alles was auf Realtimesachen geht, sogenannte I/O-Events, also Eingabe-, Ausgabedinge. Hierfür ist Node.js sehr stark, also alles, was es quasi wegdelegieren kann oder was jemand anderes erledigt. Eine Datenbankabfrage, eine Abfrage an ein drittes API, da ist Node.js sehr stark. In Node.js haben wir jedoch den kleinen Nachteil: Es gibt einen Thread. Das heißt, wir können auf der CPU nicht viele intensive Dinge tun, weil wir damit diesen Thread blockieren würden. Wenn wir beispielsweise das Klimamodell von morgen berechnen wollen, wäre das eine sehr CPU-intensive Angelegenheit und wir könnten in der Zeit der Berechnung keine Anfragen von außen entgegennehmen. Das heißt, wir müssten hier ein kleines bisschen aufpassen, das ist so ein kleiner Fallstrick von Node.js. Aber bei allem, was es dann delegieren kann, also Anfragen entgegennehmen, weiterleiten und kleinere Berechnungen anstellen, ist Node.js sehr stark und kann sehr einfach eingesetzt werden.
Es macht es natürlich auch vom Gedankenmodell ein wenig einfacher, wenn man nur einen Thread hat. Das heißt, wir haben die typischen Synchronisierungsprobleme nicht, die man normalerweise in der Threadwelt hat. Die können wir gedanklich alle weglassen und uns um unsere Haupt-Use-Cases kümmern.
Da ich auch im Frontend mit JavaScript unterwegs bin, kann ich sehr viel Wissen auf beiden Seiten mitnehmen. Ich habe auch die Möglichkeit, einen Code zu sharen; beispielsweise ein API mit einem Businessmodell hinten dran, so wie man es typischerweise hat. Ich muss es auf dem API sowieso validieren, dass beispielsweise der Vorname stimmt oder beim Alter kein Minusalter herauskommt. Genau diese Validierung möchte ich ja eigentlich auch vorne im Client haben, um dem Benutzer direkt mitzuteilen, dass er an dieser Stelle vielleicht „Müll“ eingegeben hat und man damit nichts anfangen kann. Genau die Logik dieser Validierung kann man wunderbar teilen, weil beide Seiten mit JavaScript entwickelt sind. Gewisse Teile meiner Anwendung kann ich einmal also wirklich entwickeln und sowohl im Client als auch im Server benutzen. Das bezeichnet man heute als Universal JavaScript oder Isomorphic JavaScript, je nachdem, mit welchen Begriffen man hier googeln möchte. Das sind alles ziemlich coole Vorteile bei Node.js, die man einsetzen kann.
Mirko Hillert: Du würdest also Node.js für ziemlich viele Anwendungen einsetzen. Für welche denn eher nicht?
Manuel Rauber: Alles, was sehr CPU-intensiv ist und wo ich starke Dinge berechnen möchte, zum Beispiel Klimamodellberechnung, vielleicht auch Trendberechnung. Dinge, die starke CPU-Sachen erfordern, kann man durchaus mit Node.js machen, müsste man jedoch anderweitig skalieren. Man könnte Node.js auch als Proxy nutzen, um die Anfrage entgegenzunehmen und in einen Backgroundprozess zu verschieben. Dieser berechnet dann die eigentliche Anfrage durch, kommt mit dem Ergebnis zu dem Node.js-Server zurück und spielt es wieder zurück an den Client.
Mirko Hillert: Ansonsten ist Node.js für dich das Mittel, fast alles zu entwickeln?
Manuel Rauber: Schön wäre es! Ich denke, jede Programmiersprache und jedes Framework hat immer seine Vor- und Nachteile. Ich finde, es passt immer ganz gut zum Microservices und API Summit, da man gerade mit den Microservices die Möglichkeit hat, jeden Use Case in einer Sprache zu implementieren, die für den jeweiligen am besten geeignet ist.
Wenn ich etwas Realtimelastiges habe, kann ich Node.js nutzen. Habe ich etwas, das sehr threadlastig und berechnungsintensiv ist, greife ich auf Java oder .NET zurück. Wenn man einen Use Case hat, der vielleicht auf Ruby oder Python passt, warum sollte man es nicht einsetzen? Denn alles sind immer kleine fachlich getrennte Services, und so kann man die Stärken jeder Sprache ausspielen.
Mirko Hillert: Du bist ja in vielen Kundenprojekten unterwegs. Welche Herausforderungen siehst du, wenn man sich neu mit Node.js beschäftigt?
Manuel Rauber: Ich denke mal, dass gerade wenn man zuvor noch nie mit JavaScript entwickelt hat und von einer stark typisierten Sprache wie Java und .NET herkommt, hat man mit Node.js und auch Java, da es sehr dynamisch ist, gerade zum Anfang Schwierigkeiten. Man kann damit zwar quasi alles machen, doch genau da liegt dann auch der Fallstrick. Wenn man es nicht bewusst einsetzt und es dementsprechend blöd läuft, schießt man sich selbst ins Knie. Auch das Gedankenmodell, dass man außer diesem einen keine Threads mehr hat, muss erst einmal in den Entwickler rein, um mit Node.js entwickeln zu können.
Auch das ganze Tooling rundherum ändert sich natürlich, wenn ich beispielsweise Node.js in Azure laufen lassen würde. Mach ich es in einem Docker-Container? Mach ich es direkt auf Azure? Es kommt also mit Node.js noch ein kleines Toolset für den Entwickler mit, das er bestenfalls beherrschen sollte. Ob er das nun zu hundert Prozent beherrscht oder nicht, das ist wieder Use-Case-abhängig und davon, was implementiert werden soll.
Ich würde also behaupten, dass die meisten, die zuvor JavaScript gehasst haben, dieses unwohle Kostüm abwerfen müssen, das man noch anhat, wenn man an die alten JavaScript-Zeiten denkt. Man kennt es ja noch: Die Sprache war ein wenig verrufen, was mittlerweile natürlich sehr viel besser geworden ist. Man muss sich auf die neue Sprache einlassen und schauen, wie sie sich in den letzten Jahren weiterentwickelt hat.
Meiner Meinung nach ist die größte Herausforderung diese Berührungs- – nicht Ängste –, aber Herausforderungen zu überwinden.
Mirko Hillert: Hast du ein paar Beispiele aus deinen Kundenprojekten, bei denen es Schwierigkeiten bei der Umsetzung mit Node.js gab?
Manuel Rauber: Ich hatte einen Kunden, der Java- und .NET-lastig war, aber schon diese Microservices „gedacht“ hat und jetzt anfängt, Teile der neuen Applikation in Node.js zu machen. Er macht das auch als Microservices-basierten Ansatz. Im Endeffekt spricht also Node.js mit C Sharp, Web API mit einem Java-API und das kann wieder mit einem Node.js-API sprechen. JavaScript zu machen, war für ihn die neue Welt, obwohl er zuvor eher Angular machte. Es kam also sehr viel hinzu. Auch ein Grund, warum er beispielsweise Node.js mit TypeScript programmiert und nicht direkt mit JavaScript. Da Angular in TypeScript entwickelt wird, hat er beschlossen, dass wenn er sich schon eine neue Sprache anschaut, dann würde er diese auch gern noch im Backend mit machen. Er hat also sehr viele neue Eindrücke bekommen. Wir haben sehr intensiv zusammengearbeitet, um die ersten kleinen Schritte zu machen, sodass er jetzt mittlerweile 10 oder 15 Microservices in den unterschiedlichsten Programmiersprachen, die miteinander verknüpft sind, laufen hat. Das war ein sehr schöner Weg, da es gezeigt hat, dass auch jemand, der neu in dieser Welt war, die Schritte zügig und gut gemacht hat. Das lag sicherlich auch daran, dass es immer sehr fokussiert kleine Use Cases waren. Es war einfach schön, ihn auf diesem Weg zu begleiten.
Mirko Hillert: Danke für den positiven Ausblick und vielen Dank für das Interview.
Interviewt von: Mirko Hillert
Mirko Hillert verantwortet seit 2007 als Leiter der Entwickler Akademie den Trainingsbereich bei Software & Support Media. Er studierte Betriebswirtschaft an der Westsächsischen Hochschule Zwickau und der Universidad Valencia sowie Marketing an der Westfälischen Wilhelms-Universität Münster. Als ehemaliger Dozent und Ausbilder für Managementprozesse treibt er seit vielen Jahren die fundierte Aus- und Weiterbildung von Entwicklern und Softwarearchitekten im IT-Markt voran, unter anderem mit innovativen Eventformaten und hochwertigen Trainingsinhalten.
