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.

Die durch das neuartige Corona-Virus SARS-CoV-2 ausgelöste Krankheit COVID-19 und die durch die Pandemie veränderten Lebensumstände stellen vieles auf den Kopf. Remote-Arbeiten, Digitalisierung und potentieller struktureller Wandel sind alles Themen, die den Technologiesektor tangieren, und somit auch viele unserer Kunden.

Die ganz persönlichen Lebensumstände betrifft das bisher einzige Mittel, um mit der Bedrohung umzugehen: Social Distancing.
Oft stellt sich die Frage, ob das wirklich so viel bringt gegen das Corona Virus.

Wir haben eine kleine Anwendung erstellt, mit der sich jeder selbst ein Bild machen kann: Den Corona Virus Simulator.
Es gibt zwar bereits einige Anwendungen dieser Art, auf denen wir auch mit unseren Beispiel aufbauen wollen, doch das besondere in dieser Version: Man kann sich einen direkten Vergleich von zwei Populationen anzeigen lassen, und damit die direkten Auswirkungen verschiedener Parameter gegenüberstellen.
Wir simulieren, was in der echten Welt nicht möglich ist: Nämlich gleichzeitig den Effekt von Social Distancing und weiteren Parametern und parallel dazu zum Vergleich die Entwicklung ohne Social Distancing.

Single Board Computer (SBC) wie der Raspberry Pi oder die ODROID-Serie eignen sich sehr gut als stromsparende und hinreichend performante Maschinen für Container-Hosting mit Docker oder Kubernetes.
In dem Artikel "Kubernetes auf Odroid N2" wurde die Einrichtung von Kubernetes auf ODROID N2 mit Arch Linux ARM beschrieben.
Der von Hardkernel, dem Hersteller der ODROIDs, bereitgestellte Kernel basiert auf einem alten Stand und wurde durch zusätzliche Treiber und Patches für den ODROID N2 kompatibel gemacht.
Leider bringt der verwendete Kernel einige Nachteile mit sich: So gibt es zum Teil Abstürze und Instabilitäten. Der Prometheus Node-Exporter führt zu einem sofortigen Absturz, so dass an Metrikmonitoring gar nicht zu denken ist. (Hier scheint das Problem in der dynamischen Taktung zu liegen cpufreq_cpu_get, taucht im Stacktrace stets auf.)

Abhilfe schafft der sogenannte Mainline-Kernel. Das ist ein nicht gepatchter Kernel und kann seit Linux 5.5 prinzipiell verwendet werden, da die Unterstützung der verwendeten Hardwarekomponenten des ODROID N2 in diesem enthalten ist.

Im vorhergehenden Artikel wurde der Einsatz von GitHub Actions beschrieben, um eine Angular Anwendungen auf GitHub zu testen und zu bauen.
Das Thema Deployment wurde dabei aufgrund der Vielzahl an Varianten nicht weiter behandelt. In diesem Beitrag wird nun erklärt, wie die ebenfalls von GitHub bereitgestellte Plattform zum Hosting von statischen Seiten, GitHub Pages, genutzt werden kann, um darauf eine Angular Anwendung bereitzustellen.

Der große Vorteil von clientseitigen Frameworks kommt dabei voll zur Geltung: Es wird lediglich ein simpler Webserver benötigt, der die HTML, JavaScript und CSS Dateien ausliefert. Serverseitige Logik wird für das Angular Frontend an sich nicht benötigt.

GitHub Actions ermöglichen es, Reaktionen auszulösen, wenn in einem GitHub Repository Ereignisse eintreten.
Damit lässt sich beispielsweise Generierung von Dokumentation, oder Build und Test von Programmcode umsetzen, ohne einen zusätzlichen CI-Server zu benötigen.

Anders als viele andere CI Lösungen, wie beispielsweise GitLab-CI, setzt GitHub Actions dabei auf vordefinierte Umgebungen und nicht auf Container.
Allerdings lassen sich neben den in den Umgebungen vorhandenen Standardwerkzeugen auch zusätzliche Actions hinzunehmen. Bei Actions handelt es sich um wiederverwendbare Code-Bausteine. Außer von GitHub oder dem eigenen Repository können Actions auch auf einem Marketplace von Drittanbietern, z.B. als Docker-Image, bereitgestellt werden.

Als Umgebungen stehen bei GitHub derzeit Linux, Windows und MacOS zur Verfügung.

Das Ergebnis von GitHub Actions können dann Aktionen unter Verwendung der GitHub API sein. Außerdem können auch Docker-Images erstellt und anschließend in eine Registry gepushed werden.

Wie GitHub Actions genutzt werden können, um eine Angular-Anwendung zu testen und zu bauen, stellen wir in diesem Beitrag vor.