Als Standard-Verfahren für Datei-Uploads kommt bei Nest.js-Anwendungen typischerweise ein Datei-Upload als multipart/form-data mit Hilfe der Multer-Bibliothek zum Einsatz. Dies ist jedoch nicht immer passend: Die Verwendung von multipart/form-data kommt typischerweise im Kontext von HTML Formularen vor. Ohne HTML Formular und eingebaute Logik eines Browser ist die Verwendung auf Clientseitig teilweise umständlich zu implementieren.

Im Kontext von Microservice Architekturen liegen manchmal Daten vor, die zwar als einzelne Verarbeitung behandelt werden sollen, die jedoch mit einem klassischen File-Upload Formular wenig zu tun haben.

Bei Nest.js kommt die aus dem Node / Express Umfeld bekannte Multer Bibliothek für Multipar-Uploads zum Einsatz. Mit einzelnen Binary-POSTs kann sie jedoch nicht umgehen.

In diesem Artikel werden wir einen Datei-Upload implementieren, der ohne Multer auskommt und stattdessen die Dateien direkt als Binärdaten einließt.

Ein typisches Java Projekt besteht nicht nur aus dem eigenen Code, sondern in der Regel auch vielen externen Bibliotheken als Abhängigkeiten.
Diese Abhängigkeiten machen dabei in einem Microservice mehr als 90% Anteil am gesamten Code aus. Die Wartung erfolgt zwar durch den jeweiligen Hersteller, jedoch muss das Projekt Team darauf achten, dass entsprechende Aktualisierungen auch im Projekt aufgenommen werden. Kritisch wird es dann, wenn Sicherheitsupdates zwar verfügbar sind, jedoch nicht die zugehörige Maven oder Gradle Konfiguration aktualisiert wird.

Um das Problem zu lösen gibt es verschiedene Ansätze mit einem unterschiedlichen Automatisierungsgrad. Wir wollen einen pragmatischen Ansatz vorstellen, der sich in der Praxis sehr bewährt hat und seinerseits keine zusätzlichen Abhängigkeiten einführt.

Dank Spring Boot ist die Erstellung von Java basierten Anwendungen und Microservices extrem leicht geworden: Mit Spring Initializr ( https://start.spring.io ) ist eine API Anwendung schnell erstellt. Sinnvolle Standardeinstellungen und eine gute Entwicklerproduktivität machen Spring Boot auch im weiteren Verlauf eines Softwareprojekts zu einer beliebten Plattform.

Doch was ist, wenn man von den vorgegebenen Pfaden abweichen will?
Spring Boot zeigt sich hier flexibel: Am Beispiel von YAML als Datenformat für unsere Anwendung schauen wir uns das einmal genauer an.

Auch wenn Microservice Architekturen und damit einhergehend Single-Module-Repositories im Trend liegen, gibt es immer wieder Gründe für ein Multi-Module Projekt. Sogar bei Microservice als Deployment.
Wenn es nun darum geht, die Code-Coverage zu ermitteln, um diese bei GitLab CI anzuzeigen oder Trends zu ermitteln, muss man sich etwas behelfen. GitLab CI ist im Verglech zu Jenkins nämlich deutlich dünner ausgestattet, so dass eine Fancy Plugins die Arbeit abnehmen. Damit ist Jenkins nicht automatisch besser oder GitLab CI schlechter, als Jenkins: Die Ausrichtung ist einfach anders.

Im folgenden betrachten wir einmal, wie die modulübergreifende Auswertung von Code Coverage, erhoben mit dem JaCoCo Maven Plugin, aussehen könnte. Der Ansatz lässt sich natürlich auf andere Coverage-Tools und Sprachen analog übertragen.

React Native oder NativeScript? - Eine komparative Analyse für Enterpriseanwender
Im Bereich der mobilen Anwendungsentwicklung von nativen Apps gibt es viele Wege, die zum Ziel führen. Aus bereits im Vorfeld beschriebenen Gründen [1] [2] konnten wir diese Auswahl an Wegen für die meisten praktischen Anwendungsfälle bereits auf die beiden Cross-Platform-Frameworks React Native und NativeScript reduzieren.

Aber welches der beiden Frameworks sollte man denn nun für die eigene Anwendung verwenden? Die Lösung dazu und die Antwort auf weitere Fragen werden in dieser Analyse behandelt.

Für die Lesenden, die sich zunächst einmal grundlegend mit den beiden Frameworks auseinandersetzen möchten, haben wir bereits jeweils einen Artikel zu React Native[1] und einen zu Native Script [2] vorbereitet.

OpenID Connect und OAuth2 sind vielleicht etwas moderner und hipper als das bereits etwas in die Jahre gekommene SAML 2 Protokoll. Soll jedoch im Enterpriseumfeld eine Anwendung in bestehende Landschaften integriert werden, führt selten ein Weg an SAML 2 vorbei. Das gilt um so stärker, wenn es sich um eine Branche mit hohem Sicherheitsbedarf wie Luftfahrt, Banken oder Versicherungen handelt.

Keycloak hat sich als zuverlässige und gleichzeitig sehr leicht zugängliche Plattform zur Umsetzung von OpenID Connect oder SAML erwiesen. Dabei kann Keycloak sowohl produktiv eingesetzt werden, als auch sehr komfortabel als lokale Testumgebung für Entwicklung und Test verwendet werden. Zur Integration von Keycloak in Spring Boot existieren neben einem Keycloak Modul auch Spring-Security-SAML bzw. OAuth2 Client und Resourceserver.

Gerade wenn es um das Thema Security geht, bringen automatisierte Tests ein wichtiges Sicherheitsnetz für die Software. Wir wollen Keycloak als SAML 2 IdP verwenden und mit einer Spring Boot Anwendung Authentifizierung mit SAML 2 als Beispielanwendung für automatisierte Integrationstests verwenden. Ein - relativ einfacher - Weg wäre, Keycloak als Docker Container im Rahmen der CI-Pipeline mit Jenkins, Bamboo oder GitLab-CI bereitzustellen, so dass die zu testende Software darauf zugreifen kann. Allerding verliert man damit die Möglichkeit, die Tests lokal genauso zu entwickeln und zu validieren, wie sie nachher in der Buildserver Umgebung laufen.

Eine Alternative stellen Testcontainers dar. Die allgemeine Verwendung von Testcontainers wurde bereits in Testcontainers mit JUnit 5 erläutert. Nun schauen wir uns an, wie Keycloak, Testcontainers und Spring Boot SAML 2 zusammen eingesetzt werden kann.

Mobile Entwicklung für Enterprise Anwendungen
Bei der mobilen App-Entwicklung gibt es heutzutage viele verschiedene Optionen. Im letzten Artikel [3] wurde bereits React-Native als ein Weg zum Ziel beschrieben. Dort wurde die insbesondere für Enterprise-Anwendungen größtenteils fehlende MVC-Trennung angemerkt. Eine weitere Alternative mit anders umgesetzter Separation of Concerns ist NativeScript [1].

In diesem Artikel wollen wir eine Basis für App-Entwicklung aller Art mit NativeScript legen, daher ist der gesamte Quellcode auf GitHub verfügbar [2]. Er kann direkt ausgechecked und auf die eigenen Bedürfnisse ausgebaut werden. Das spart Zeit beim initialen Setup.

Regelmäßig kommt in unseren Docker Schulungen Verwunderung auf, wenn wir Beispiele zum Einsatz von Containern im Entwicklungsprozess aufzeigen. Denn Container bzw. Docker bringt gerade da auch immense Vorteile: Neben einer möglichen Parität zwischen Produktionsumgebung und Entwicklersystem ist es gerade die sehr einfache Möglichkeit, Umsysteme als Container bereitzustellen.

Das kann für einen Frontendentwickler das Backend sein, für einen Backendentwickler kann es die richtige Datenbank, Message-Queue oder ein anderer (Micro-)Service sein.
Verfügen aktuelle IDEs in der Regel über Docker-Integration oder wird docker-compose eingesetzt, stellt sich die Frage, wie in CI-Umgebungen Container für Integrationstests am besten eingesetzt werden können. Hier hat das Projekt Testcontainers eine Lösung ins Rennen geschickt: Durch eine gelungene Abstraktion lassen sich Container sehr leicht in Tests verwalten und zusammen mit den Tests orchestrieren. Container-Typen und Versionen werden gemeinsam mit dem Testcode versioniert, was die Wartung und Refactoring erleichtert. Auch ein häufiges Problem, nämlich auf den erfolgreichen Start eines Containers bzw. des damit bereitgestellten Dienstes zu warten, wird gut gelöst.

Testcontainers gibt es für verschiedene Programmiersprachen bzw. Plattformen. Wir schauen uns im folgenden einmal die Umsetzung für Java speziell im Kontext von JUnit 5 genauer an.

Wie macht man mobile Entwicklung heute?
Häufig ist die Antwort hierfür ein Cross-Platform Framework. Insbesondere für Rapid Prototyping sollte der initiale Entwicklungsaufwand möglichst begrenzt sein. Wenn gleichzeitig auch die langfristigen Wartungskosten reduziert werden können, lassen sich diese Prototypen im nächsten Schritt gleich in vollständige Anwendungen umbauen. Es ist möglich, beispielsweise für eine Messe oder als Proof of Concept mit sehr geringem Aufwand und beschränktem Plattformwissen mobile Anwendungen zu launchen, ohne dabei allzu viel Zeit zu verschwenden.

React Native [3] hat sich hierbei als eines der populärsten Frameworks für derartige Anwendungsfälle herausgetan [1] [2]. Die Gründe dafür sowie eine kurze Einführung in die Konzepte inklusive einer Basis-Anwendung, die als Grundgerüst für die eigenen React-Native-Aspirationen dient, sind in diesem Artikel zu lesen.

Container, allen voran Docker, sind in aktuellen Infrastrukturen ein fester Bestandteil. Waren früher gerade Buildserver und CI-Umgebungen schwer zu warten, da diverse Werkzeuge oftmals jeweils in mehreren Versionen gepflegt werden müssen, können Build-Container alle benötigten Werkzeuge direkt mitbringen.

Moderne Buildserver wie DroneCI oder GitLab CI unterstützen daher nativ die Verwendung von Werkzeugcontainern in Form von Docker Images. Für Angular gibt es beispielsweise mit https://hub.docker.com/r/trion/ng-cli-karma ein Image, in dem Angular CLI und Webbrowser bereitgestellt werden.

In diesem Beitrag werfen wir einen Blick auf Cypress, dass sich sehr gut zur Umsetzung von Integrations- und Ende-zu-Ende Tests eignet. Cypress kann prinzipiell mit beliebigen Technologien kombiniert werden, beispielsweise serverseitig gerenderten Anwendungen, oder mit Angular, React oder Vue im Browser umgesetzten Anwendungen.
Wir verwenden in diesem Beispiel React, jedoch sollte die Übertragung auf andere Frameworks dem Entwickler sehr einfach von der Hand gehen.