Vous le savez, à ARCA on est fan de Kotlin. Mais un langage ne devient intéressant que lorsque de bons frameworks ou librairies viennent nous aider à en tirer le meilleur. Pleins feux sur ce framework backend plein de promesses.
#1. Ktor, c’est quoi ?
Ktor, c’est le framework backend écrit en Kotlin pour du Kotlin (si vous voulez en savoir plus, nous avons un article entier consacré à ce langage), par l’équipe de JetBrains. Oui, ceux-là même qui ont créé Kotlin, c’est qu’ils ont de la suite dans les idées ! 😄 Ktor permet de créer facilement des APIs REST ou GraphQL, des applications web HTTP (en s’appuyant sur le Server Side Rendering), des applications en temps réel avec des websockets… Bref, ce framework se pose en sérieux concurrent face aux géants de l’écosystème Java (comme, au hasard, SpringBoot). Surtout qu’il tire pleinement profit de toutes les optimisations offertes par le Kotlin, comme les Coroutines. Ce projet est relativement récent (v1.0.0 en novembre 2018), mais toujours en développement actif, et la v2.0.0 est sortie il y a à peine un mois. De plus, il est totalement Open Source et disponible sur leur GitHub, encore une bonne raison de l’aimer.
We're extremely excited to announce the release of Ktor 2.0.0. Check out the summary for a list of everything new! https://t.co/T7R0hy3zmH
— JetBrains Ktor (@JetBrainsKtor) April 11, 2022
#2. Prendre partie de Kotlin pour mieux séparer le code
Avec Ktor, il faut savoir utiliser les extensions de fonctions et les Coroutines ! Des mots barbares qui font peurs, mais qui se montrent à l’usage d’une incroyable efficacité sans sacrifier la lisibilité. En prenant pleinement avantage des fonctions d’extension, Ktor vous offre une modularité excessive : c’est vous qui décidez où sont définis les comportements. Il suffit ensuite d’enregistrer ces comportements dans leur plugin associé, et de définir ces plugins dans l’Application principale. Prenons un exemple : une bête application qui va nous servir de bibliothèque. Évidemment, c’est extrêmement simpliste, le but n’est pas de vous expliquer comment développer une API, mais les spécificités de Ktor.
Tout d’abord, il faut ajouter dans le fichier de build les plugins du framework que l’on veut utiliser. Il y en a facilement plus que dans d’autres frameworks, mais ceux-ci sont plus petits en moyenne, ce qui rend le tout très modulaire. Par exemple, on trouvera un plugin pour la compression zip lors des échanges avec un client, un plugin pour la sérialization json, etc. Voici un exemple:
Ensuite, l’architecture : chaque entité aura son propre package, contenant l’entité à proprement parler, et son controller HTTP. Un package plugin pour configurer tout ce petit monde, et enfin, l’application.
L’application est extrêmement simple : elle définit le serveur, les plugins, et c’est tout.
Ensuite, le plugin de routing permet de définir les différentes routes, ou controller.
Enfin, le controller définit sa route, ses comportements, etc. Pour les besoins de l’exemple, nous somme devant un CRUD classique, mais qui permet de voir comment récupérer un PathParam (ligne 8), retourner une erreur (ligne 10) ou encore recevoir un body sous la forme JSON sérialisé automatiquement en l’entité Kotlin correspondante (ligne 20).
En moins de 50 lignes de code, nous avons définit un CRUD, en positionnant le code spécifique aux Book uniquement dans le package associé. Et bien sûr, il est possible de définir des sous routes, il suffit de ré-étendre Route et d’appeler cette méthode au bon endroit :
On peut remarquer que chaque plugin est initialisé dans son propre fichier, facilitant la séparation du code par focntionnalité. Ainsi le code s’occupant de l’authentification sera séparé de celui s’occupant du routing, de la sérialization, etc.
Pour en savoir plus, Ktor propose de nombreux exemples et une doc complète pour bien démarrer, au hasard Créer une API HTTP.
#3. Léger et personnalisable
Dans la même veine que ce qui se passe dans l’écosystème frontend, Ktor prend le parti de la légèreté et de la souplesse. Fini les usines à gaz qui font à boire et à manger quand on a seulement besoin d’une serviette : Ktor embarque le strict minimum, et c’est à chacun de construire son application brique par brique en empilant les plugins nécessaires et uniquement ceux là. Ce qui nous donne au final des artefacts plus légers, et mieux optimisés en terme de charge de calcul machine (donc, plus rapides et plus écologiques !).
Le framework ne dépend que du runtime de kotlin, ce qui évite de télécharger des centaines de Mo au démarrage d’un projet. Le démarrage d’un projet se fait en quelques secondes, bien plus rapidement qu’un projet similaire sous Spring Boot ou Micronaut. Cela permet une boucle de feedback très rapide et agréable pendant le développement. Pas besoin de « HotReload » bancal dans lequel on n’est jamais sûr de ce qui a été rechargé.
Photo by Nadin Mario on Unsplash
Certes, cela peut-être déstabilisant pour les personnes habituées aux projets « clés en main ». Mais rassurez vous, l’écosystème de plugins de Ktor est déjà riche en fonctionnalités, et vous si vous ne trouvez pas votre bonheur il suffit de créer votre propre plugin comme décrit sur cette page. D’ailleurs, voici une liste de plugins qui nous semble intéressants, recommandés par Ktor :
- Authentification Basic, OAuth, JWT, à vous de choisir
- CORS et HttpsRedirect, pour sécuriser les appels
- Sérialisation JSON au choix : kotlinx, GSON, ou Jackson
- KGraphQL-Ktor, pour passer à GraphQL
- Dependency Injection avec Kodein
- …
Et une liste non exhaustive des plugins est disponible sur le generateur web ou dans IntelliJ IDEA à la création du projet.
#4. Presque parfait?
Même si très attrayant, il y a au moins un point que Ktor n’aborde pas: l’injection de dépendances. Il faudra se tourner vers une librairie tierce, comme Kodein. C’est dommage que ce composant ne fasse pas partie des briques officielles du framework. En revanche, on apprécie de pouvoir, comme toutes les autres plugins, choisir celui qui nous plaît le plus, ou d’utiliser une solution a nous.
