Fullstack-Entwickler kennen das. Das Backend wird in Java geschrieben und per Maven gebaut. Das Frontend wird in Javascript, HTML und CSS implementiert. Kommen nun auch noch Anwendungsteile wie Desktop-Applikationen oder Apps hinzu, welche nativ kompiliert werden müssen, werden noch weitere Sprachen und Bibliotheken benötigt. Wäre es nicht von Vorteil, all diese Aufgaben mit einer einzigen Programmiersprache erledigen zu können?
Kotlin hat sich dies zur Aufgabe gemacht. Dabei wird Kotlin jedoch nicht einfach nur für die einzelnen Umgebungen kompiliert, sondern stellt auch die Sprachfeatures für die einzelnen Umgebungen zur Verfügung. Egal ob JS, JVM oder Native, in allen Fällen kann der Entwickler wie gewohnt mit dieser einen Sprache und seinen Eigenheiten programmieren. Zu den Spezialitäten gegenüber Java zählen Null Safety, ein vollständig objektorientierter Ansatz, funktionale Programmierung, High Order Functions, DSLs, etc… Javascript profitiert vor allem von der Typsicherheit. Doch was heißt dies im Alltag? Kann ein Projekt vollständig und ohne signifikant erhöhten Mehraufwand einfach so in einer Sprache realisiert werden? In diesem Artikel möchte ich einen kleinen Überblick über das Thema Fullstack mit Kotlin gewähren und auf die Eigenheiten der Implementierung eingehen. Dabei werde ich auch einige Technologien vorstellen, die zusammen im Verbund mit Kotlin sehr gut harmonieren.
Als Demoprojekt kommt hier eine (sehr) rudimentäre Bibliotheksverwaltung zum Einsatz, die speziell als Begleitung zu diesem Artikel entwickelt wurde. Dabei gehen die Features eher in die Breite als in die Tiefe, um die einzelnen Besonderheiten der Implementierung zu beleuchten.
Allgemeines
Kotlin ist auf der JVM bereits kein Novum mehr und schon seit einigen Jahren im Einsatz. Ein Totschlagargument für Kotlin-Anhänger ist, dass Kotlin fast 100% kompatibel mit anderen Java-Klassen ist und somit (fast) schmerzfrei in eine bestehende Java-Applikation integriert werden kann.
Allerdings muss dazu erwähnt werden, dass Kotlin mehr als nur eine Erweiterung für Java ist. Einige Features der Sprache lassen Java ziemlich alt aussehen. In einigen Punkten kann man durchaus behaupten, dass Kotlin Java ein paar Schritte voraus ist. Sie ist über die letzten Jahre hinweg zu einem ernsthaften Konkurrenten gereift und steht Java in Sachen Funktionalität durch nichts nach. Auf der Android-Plattform hat Kotlin Java bereits als primäre Sprache verdrängt.
Doch was genau zeichnet Kotlin aus? Im Folgenden möchte ich eine kleine Übersicht über einige Interessante Features geben:
-
Cross-Compiler
- JVM
- Android
- Javascript / React
- Native
- Type-Safe-Builder für Domain-Specific-Languages (DSL)
- Null Safety
- Lambdas
- Extension Functions
- High Order Functions
- Eine erweiterte stdlib mit vielen Hilfsfunktionen
- Funktioniert nahtlos mit allen gängigen Java und JS Programmteilen
- Smart Casts
- Default- und Named Arguments
- Data Classes
- Objekt-Dekonstruktion
Viele dieser Features werden noch einmal im Detail in einem Grundlagenartikel genauer vorgestellt werden.
Server
Die Kotlin-Implementierung für die JVM ist definitiv kein Hexenwerk und bedarf lediglich einer guten Kenntnis der Sprache selbst. Dabei können auch auf bekannte Mechanismen (OOP etc...) und Frameworks aus der Javawelt zurückgegriffen werden. Dazu zählen u.a. Spring Boot, Vert.X und viele andere Serverlösungen. Die Kotlin-Entwicklung im Backend ist also kein großer Kunstgriff. Es gibt bereits zahlreiche Anwendungsfälle, in denen Kotlin zum Einsatz kommt.
Neben der eigentlichen Anwendung kann auch das Buildscript (Gradle) in Kotlin geschrieben werden. Dazu muss lediglich die entsprechende DSL verwendet werden.
Der Server der Beispielimplementierung dieses Projekts basiert auf dem Webserver von Vert.X und einer MongoDB als Datenbank. Beides zusammen bietet eine sehr leichtgewichtige, reaktive Lösung. Dabei wird weder ein Spring-Kontext noch ein Applikationsserver benötigt. Dies bietet sich gerade bei kleineren Webanwendungen an, in denen Spring und Co. einfach einen Overhead darstellen würden.
Client
Etwas spannender gestaltet es sich im Frontend. Der für dieses Projekt entwickelte Webclient nutzt eine von Kotlin zur Verfügung gestellte HTML-DSL. Dadurch kann HTML-Code in Kotlin geschrieben werden, ohne die Syntax wechseln zu müssen.