Mirko Hillert: Du hältst einen Workshop zum Thema „Datenzentrierte APIs“. Bei der Entwicklung von APIs für Anwendungen geht es in erster Linie oft um Performance. Was kann die Performance von APIs negativ beeinflussen?
Raphael Schwarz: So banal es klingen mag, sind es im Wesentlichen immer zwei Faktoren, die bei der Entwicklung entweder schlecht oder inkorrekt berücksichtigt wurden, wenn das API langsam wird oder nicht so performt, wie es soll: Latenz und Bandbreite. Das sind die zwei wichtigen Faktoren, die beeinflussen, wie sich das API unter Last im Produktivsystem bei schlechter Bandbreite verhält. Das ist etwas, was man im Voraus im Entwicklungszyklus schon mitberücksichtigen und weiterhin regelmäßig checken muss. Das sind die klassischen Fehler, die in der Praxis immer erst auftreten, wenn wir ins Produktivsystem kommen. Dort hat man dann eine LTE-Internetverbindung, die nicht immer mit hoher Latenz stabil ist, oder höhere Datenmengen als im Testdatenbestand. Dort treten dann erst die Probleme auf. Das Analysieren solcher Systeme im Nachhinein und das Finden entsprechender Schwachstellen ist ein großer Teil meiner Arbeit.
Mirko Hillert: Wie lassen sich diese Fallstricke für datenzentrierte APIs, also APIs, die große Datenmengen übertragen, möglichst umgehen?
Raphael Schwarz: Am ehesten lassen sie sich grundsätzlich dadurch umgehen, indem man sie rechtzeitig erkennt. Man braucht im Entwicklungs-Lifecycle definierte Punkte, an denen man immer wieder Performanceanalysen macht. Zudem sollten immer wieder Auswertungen dazu gemacht werden, wie das System performt, wenn es nicht im Idealumfeld ist. Es also nicht in einem Gigabit-Netzwerk ist oder ich keinen Entwicklerrechner mit einer MMCS-Festplatte habe, die 3 Gigabyte pro Sekunde lesen und schreiben kann. Man sollte also die Realbedingungen schon im Entwicklungszyklus möglichst gut nachbauen, um rechtzeitig zu erkennen, wo die Schwachstellen liegen. Zudem sollten die richtigen Technologien ausgewählt werden, um diese Schwachstellen auch beheben oder sogar umgehen zu können.
Mirko Hillert: In deinem Workshop stellst du unter anderem das Entity Framework vor. Wie unterscheidet sich dieses von Alternativen wie Dapper oder NHibernate?
Raphael Schwarz: Das ist eine schwierige Frage. Grundsätzlich einmal dadurch, dass es ein natives Produkt von Microsoft ist, von der Open-Source-Entwicklung, aber von Mitarbeitern der Firma Microsoft entwickelt. Dadurch ist es sehr gut und eng in das .NET Framework und in die ganze .NET-Familie integriert – First-Class Citizen für LINQ Queries und so weiter. Dapper würde ich gar nicht in die gleiche Kategorie wie NHibernate und Entity Framework einordnen. Dapper ist eher auf Low-Level und reine Mapping-Funktionalitäten beschränkt. Die richtigen Mehrwerte, die ich durch LINQ-basierte Lösungen bekomme, so wie es in NHibernate größtenteils auch ist, sind, dass ich typisiert Query schreiben und auch typisiert auf meine Datenbanken zugreifen kann. Dinge, wo vorher bei kleinen Schemaänderungen große Auswirkungen zur Laufzeit sehr oft im Hintergrund standen. Beim Entity Framework sehe ich den großen Vorteil, dass es ein wirklich natives Produkt der .NET-Core-Familie ist und bei dem Redesign für Entity Framework Core sehr viele Dinge bedacht wurden, die bei Entity Framework 6 nicht so übermäßig gut waren und jetzt von Grund auf korrigiert wurden. Das sind Dinge wie native In-Memory-Provider für Unit Testing. Damit gibt es also einen erstklassigen Weg, wie APIs mit einem Entity Framework (Backend, besser gesagt) Unit getestet werden können. Ein weiteres Thema ist natürlich, dass auch die ganzen Non Relational Databases, wie MongoDB und NoSQL-Datenbanken, über das Entity Framework Support erhalten und sich der Support nicht nur auf die drei, vier großen relationalen Datenbanken beschränkt.
Mirko Hillert: Wie werden OData und GraphQL eingesetzt?
Raphael Schwarz: In meinen Samples für den Workshop ist das Backend immer ein ASP.NET Core Backend. Dort sitzt im Endeffekt OData und GraphQL auf dem Entity Framework als Metadatenschicht drauf. Es geht in dem Workshop weniger um das konkrete Einsetzen von OData oder GraphQL, sondern mehr um die Konzepte, die dahinterstecken. Wie man das Konzept von OData grundsätzlich an den Stellen übernimmt, wo OData seine Stärken hat, um dann Dinge zu lösen, bei denen es in Richtung Bandbreitenprobleme gehen kann. Man muss dann nicht noch mehr Daten übertragen, als man wirklich anzeigt und nicht 30 Requests zum Server machen, um eine Maske aufzubauen, sondern nur einen, oder auch, dass die Daten genau für den Anwendungsfall, den wir gerade brauchen, zugeschnitten sind. Genau dafür sind OData und GraphQL-Frameworks, die mir die richtigen Werkzeuge zur Verfügung stellen. Aber im Kern geht es mehr um das Konzept, das dahintersteckt.
Mirko Hillert: Raphael, 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.
