Eine Vielzahl von Anwendungen setzt mittlerweile auf das Kommunikationsprotokoll MQTT. Das Protokoll findet beispielsweise Einsatz in IoT-Anwendungen wie Industrie 4.0, Connected Cars und Logistik sowie generell bei der Kommunikation zwischen Microservices.

In jedem Unternehmen gibt es große Softwaresysteme, die über viele Jahre weiterentwickelt wurden und deren Wartung Jahr für Jahr immer zäher und teurer wird. Vor dem Hintergrund neuer Architekturparadigmen wie Microservices sollen diese Systeme nun modern, skalierbar und flexibel werden. Dabei ist die Hoffnung, dass man sich der großen, schwerfälligen Monolithen entledigen kann, indem man sie in kleinere, besser zu beherrschende Microservices zerlegt.

Die Verbreitung der Akronyme CQRS und DDD nimmt seit einigen Jahren stetig zu: Vor allem im Kontext von Microservices begegnet man den beiden Konzepten immer häufiger. Was steckt dahinter?

Obgleich das Zielbild sowohl ein Monolith als auch eine Microservices-Architektur sein kann – das Axon Framework offeriert einen leichtgewichtigen Ansatz zur Implementierung Event-basierter Anwendungen. Dabei stützt sich das Framework auf gängige Muster aus dem Domain-driven Design (DDD) [1] und begünstigt die Umsetzung einer Anwendung nach dem Architekturprinzip Command Query Responsibility Segregation (CQRS) [2] und der Persistenzstrategie Event Sourcing [3]. Durch diese Flexibilität und die Tatsache, dass das Axon Framework bestens mit dem Spring Framework integriert ist und damit ein quasistandardisiertes Programmiermodell unterstützt, ist es für den modernen Java-Entwickler einen Blick wert.

In seinem Vortrag „10 Things I Regret About Node.js“ hat Ryan Dahl, der Schöpfer von Node.js, von falschen Designentscheidungen gesprochen, die seinerzeit bei der Entwicklung von Node.js getroffen worden seien. Da man die Zeit nicht zurückdrehen kann, hat Dahl sein neues Projekt Deno ins Leben gerufen. Das Ziel: Schwächen von Node sollen revidiert und eine moderne, sichere Plattform für serverseitiges JavaScript bereitgestellt werden. Ist der Versuch geglückt?

Nx Monorepos erlauben das Aufteilen großer Projekte in einzelne Domänen und Bibliotheken. Zugriffsregeln und öffentliche APIs stellen eine lose Kopplung sicher. Der erste Teil dieser Artikelserie stellt vor, wie das relativ einfach zum Projektstart eingerichtet werden kann.

Die Architektur definiert die Struktur eines Softwaresystems und ist zentral für den Erfolg eines Projekts. Deswegen ist Softwarearchitektur so wichtig. Aber in Wirklichkeit ist Softwarearchitektur noch viel mehr, und eine erfolgreiche Softwarearchitektur erfordert viele, teilweise überraschende Maßnahmen.

In verteilten Systemen ist Fehlerbehandlung oft aufwendig und schwierig. Jeder Aufruf zu einem externen System kann schiefgehen und muss daher separat behandelt, wiederholt und überwacht werden. Sollte ein Aufruf in einer Sequenz von Operationen so fehlschlagen, dass er nicht auf der Stelle behoben werden kann, muss die gesamte Sequenz neu gestartet werden. Bereits erfolgreiche Aufrufe werden ausgelassen.

Vor rund zehn Jahren kam der Begriff DevOps auf. Seitdem hat sich technisch einiges verändert. Außerdem gibt es ganz neue Kollaborationsansätze in der IT.

An JavaScript als Programmiersprache gibt es mittlerweile kaum einen Weg vorbei. Es ergibt für viele Programmierer also durchaus Sinn, wenn sie sich zumindest mit den Grundlagen beschäftigen. Umsteiger sollten sich ebenfalls zuerst mit den Grundlagen und Besonderheiten befassen.

Wir schreiben das Jahr 2000. Unsere Branche hat den Millennium-Bug überlebt. Ein Smartphone kann auch die Uhrzeit anzeigen. Java ist eine Sprache ohne Generics, Lambdas oder Typinferenz. Die Bereitstellung von EAR-Dateien dauert ewig. EAR-Dateien? Genau, das Spring Framework ist nämlich noch Jahre von der Markteinführung entfernt. Richtige Programmierer verwenden RMI und CORBA.

Große Softwaresysteme existieren in der Regel nicht allein und haben normalerweise viele Schnittstellenpartner. Die Anzahl der Partnersysteme kann dabei ganz schnell im zweistelligen Bereich liegen. Je kleiner die Services geschnitten werden, was derzeit in den Projekten tendenziell passiert, desto höher wird naturgemäß die Anzahl der Partnersysteme, die aufgerufen werden müssen. Es etabliert sich somit ein umfangreiches Kommunikationsnetz: ein sogenanntes Service Mesh.

Die Einführung neuer QL-Sprachen erfreut sich momentan großer Beliebtheit. Erst im Sommer machte Amazon mit der Einführung von PartiQL einen neuen Vorstoß in diese Richtung. Bei diesem QL-Wildwuchs darf man das Original aber nicht aus den Augen verlieren. Was wurde eigentlich aus SQL? Steckt es tatsächlich noch in den 90ern fest? Natürlich nicht. Ein Update für Entwickler.

Im Folgenden wollen wir ein mit Azure Functions – also serverless – implementiertes API mit modernen Mitteln absichern, indem wir eine JSON-Web-Token-(JWT-)Validierung hinzufügen. Vorkenntnisse in OAuth 2 [1], JWT [2] und Identity Provider (IDP) [3] sind von Vorteil, aber nicht zwingend notwendig.

Die sogenannten „Hooks“ sind bei React eine der spannendsten Neuerungen der letzten Zeit. Sie ermöglichen es, auch in Funktionskomponenten alltägliche Dinge wie lokalen Zustand zu managen und Seiteneffekte durchzuführen, was vorher nur mit Klassenkomponenten möglich war. Im Artikel schauen wir uns an, was es mit React Hooks auf sich hat und was das mit Funktionskomponenten zu tun hat. Wir betrachten einige der Standard-Hooks und sehen, wie eigene Hooks gebaut werden können. Zum Schluss werfen wir einen Blick auf Third-Party-Bibliotheken aus der React-Community und darauf, wie sie das neue Hooks API adaptieren.

Mit Bazel ist ein neues Build-Tool am bereits reich bestückten Himmel der Entwicklertools erschienen. Ein aufgehender Stern am Horizont, auf den wir alle lange gewartet haben. Äh, haben wir das?

Azure Functions ist das Serverless-Computing-Angebot von Microsoft Azure. Doch was genau ist Serverless Computing, und haben wir damit wirklich keine Server mehr? Diese Fragen soll dieser Artikel beantworten und erklären, wie und für was wir Azure Functions nutzen können.

Mobile Applikationen werden zurzeit häufig noch nativ für jede Plattform entwickelt. Für Android nutzt man beispielsweise Android Studio und schreibt mit Java oder Kotlin eine Applikationslogik. Für iOS wird dann die gleiche Logik in Objective-C oder Swift erneut implementiert. Doch das muss nicht sein.

Agile und DevOps sind Konzepte und Trends gleichermaßen. Sie stehen für eine maximale Flexibilisierung der Projektarbeit und das Zusammenwachsen von Development und Operations. Gibt es eine Schnittmenge zwischen diesen beiden Ansätzen?

Sobald man APIs entwickelt, steht man vor dem Problem, wie man sie testet. Mit Karate [1] gibt es ein Framework, das auf Basis von Cucumber [2] eine einfache Möglichkeit bietet, den Test in die Softwareentwicklung zu integrieren.