Kotlin full stack ?

Kotlin est à l’origine un langage qui compile en bytecode de la JVM et qui est pleinement compatible avec Java.
Cela fait maintenant quelque temps qu’il est possible d’écrire du Kotlin qui compile en JavaScript, mais, lors de la Kotlin conf, de 2017, Jet Brains a fait une démo utilisant React en Kotlin.
Lors de cette même conférence, il a été annoncé la possibilité de faire du multi-plateforme avec Kotlin. C’est-à-dire qu’il est désormais possible d’écrire du code qui visera la JVM et JavaScript.
Tout cela est très prometteur ! Et si l’on essayait de tout faire en même temps ?

Le projet

Dans le but de tester cette architecture, j’ai commencé à écrire une application de gestion de bibliothèque pour Zenika. Étant donné que cette application a pour but de vraiment être utilisée, le code continuera à évoluer après l’écriture de cet article. Cependant, j’ai créé une branche “article” pour conserver le code en l’état.
Le code ne fait pas grand-chose, mais permet de prouver les concepts.

Le build

Pour créer un projet multi-plateforme, il faut utiliser gradle et ses plugins kotlin-platform-**** fourni par JetBrains.
On peut alors utiliser l’instruction expectedBy dans les projets spécifiques à une plateforme pour faire référence au projet commun.
Sous le capot, cette instruction permet à gradle d’aller chercher les sources communes et de les compiler pour la plateforme spécifique. Autrement dit, lors de la compilation des sources communes, seules les métadonnées sont créées afin de permettre leur usage, mais la *vraie* compilation est réalisée dans les modules qui sont spécifiques à une plateforme.
Il est important de noter que seul Gradle peut être utilisé pour builder un projet multi-plateforme.
Pour ce qui est de faire du react en Kotlin, JetBrains fournit un générateur de projet. Le but de ce générateur est de permettre une mise en place rapide des outils nécessaires à ce type de projets. Dans ce but, beaucoup de complexité de build est cachée au développeur. Ce n’est pas un drame en soi, sauf que le build se fait via npm.
Le build npm fait quatre choses qu’il est important de noter :

• Gérer les dépendances Kotlin
• Compiler les sources Kotlin vers JavaScript
• Gérer les dépendances de build JavaScript
• Créer un bundle depuis les sources JavaScript via Webpack

Or, comme nous voulons faire du multi-plateforme, nous ne pouvons pas laisser les deux premier points à npm. Il faut que ce soit gradle qui s’en occupe !
Heureusement, JetBrains fournit également le plugin org.jetbrains.kotlin.frontend qui permet de faciliter ce pont.
Il faut alors démêler ces étapes et les répartir entre les deux outils de build (ce qui est chronophage) mais le principe est simple.

Les tests

Une fois le système de build mis en place, on peut commencer à écrire du code et donc des tests !
Sauf que les tests unitaires ne sont pas supportés en react-kotlin pour l’instant.
La bonne nouvelle est que les tests unitaires sans react (une fonction écrite dans un coin) fonctionnent parfaitement. La preuve, on peut même partager des tests entre les plateformes grâce à kotlin.test

Il “suffit” donc d’être capable de tester notre code react. Or, il existe déjà des frameworks pour ça ! L’équipe de JetBrains annonce travailler sur la solution Jest, j’ai voulu regarder une autre piste et essayer d’utiliser enzyme.
Kotlin permet d’importer des modules JavaScript grâce à @JSModule et external. Pour pouvoir utiliser la librairie, il suffit alors de traduire la documentation en signature de fonction kotlin et le tour est joué…
… pour les composants simples qui ne font pas d’appels asynchrones.
En effet, dans le cadre de ce projet, le front doit faire des appels au back ! Et ces appels sont provoqués par des actions utilisateur sur l’interface générée par react.
Afin de rester le plus unitaire possible, il faut éviter de faire réellement l’appel au serveur.
Heureusement, encore une fois, une librairie existe pour nous permettre de mocker notre serveur : fetch-mock. La technique est alors la même que précédemment.
Grâce à ces deux outils, il est désormais possible de tester nos composants react correctement.
Il y a cependant quelques points à connaître :

• Le code asynchrone JavaScript utilise les coroutines ce qui rend le code plus difficile à tester. En particulier, il est impossible de bloquer un thread en JavaScript. Ainsi, il est impossible d’utiliser runBlocking dans nos tests.
• Qunit est le framework de test utilisé actuellement et l’objet assert utilisé pour tester les fonctions asynchrones n’est pas passé aux méthodes Kotlin. J’ai donc utilisé une méthode dépréciée pour tester mon code asynchrone.

La délivrance

Une fois tous ces obstacles passés, place au plaisir !
C’est un vrai régal de faire du react avec du Kotlin ! On profite de toute la sécurité et le tooling (auto-completion, refactoring, etc…) que permet le langage.
L’intégration aux frameworks Java est toujours aussi parfaite et faire du spring boot est tout ce qu’il y a de plus naturel.
La promesse du partage de code est tenue et permet de transférer des données très simplement entre le back et le front!

Conclusion

Globalement, toutes les promesses sont tenues !
Cependant, il faut être conscient qu’il s’agit d’une technologie jeune et que l’outillage n’est pas encore présent, en particulier sur le front.
Je recommande donc de se lancer sur ces technos sauf en cas de projet où la part dédiée à l’apprentissage ne peut pas être importante. Néanmoins, même pour de tels projets, utiliser Kotlin sur la JVM est tout à fait envisageable.