Utilisation de Kotlin pour le développement back-end : un aperçu rapide

Je n'ai pas à présenter Kotlin aux développeurs Android natifs, puisqu'en mai 2017, Google a annoncé qu'il serait le langage officiel pour le développement Android. Depuis lors, il a gagné en popularité en tant que premier choix de langage pour développer de nouvelles applications Android brillantes. Il résout de nombreux problèmes de Java, de sorte que les nouvelles applications y sont principalement écrites et les anciennes y sont réécrites.

Il ne fait aucun doute qu'il est excellent du côté frontal des applications, et lorsque vous mentionnez Kotlin pour la première fois, la plupart des gens l'associent au système d'exploitation Android. Cependant, dans cet article, je parlerais de Kotlin en tant que langage back-end et j'aimerais partager mon histoire sur la création d'un back-end Kotlin rapide, fiable et asynchrone pour mon projet de passe-temps Android. Je ne discuterai pas de l'objet du projet, car il sort du cadre de cet article; je vais plutôt m'attacher à expliquer pourquoi j'ai choisi Kotlin et pourquoi je pense que c'est un excellent langage pour écrire des applications côté serveur ou des API REST.

Pourquoi Kotlin ?

Permettez-moi de revenir au tout début de mon voyage. J'ai toujours eu des ambitions entrepreneuriales et je pensais que la première étape sur cette route était de créer quelque chose par moi-même. Rien d'énorme, rien qui change le monde, juste quelque chose de petit que moi et peut-être ma famille et mes amis pouvons utiliser. Après avoir eu une idée raisonnable, j'ai sauté dedans et j'ai commencé à l'implémenter. La première chose que vous faites au début de tout projet est de choisir vos outils. Après tout, le bon ensemble d'outils peut vous faire économiser beaucoup de temps et d'argent à long terme. C'est donc ce que j'ai fait.

Je suis avant tout un développeur Java. J'ai écrit plusieurs systèmes back-end et API REST en utilisant Java et Spring, et je pense que ces deux sont d'excellents outils pour faire de telles choses. Java en soi est un langage complet, mais combiné avec Spring, il n'y a rien que vous ne puissiez implémenter.

Cependant, il n'y a qu'un seul petit cheveu dans la soupe. Verbosité. Bien que Spring et les dernières versions de Java aident beaucoup à cela, vous devez toujours gérer beaucoup de code passe-partout. Et comme me l'a dit un jour un gars formidable - le code le plus sûr, le plus fiable et le plus exempt de bogues est le code qui n'est pas écrit. Prenons, par exemple, cette classe Java triviale :

 public class Person { private final String name; private final int age; public Person(String name, int age) { this.name = name; this.age = age; } public String getName() { return name; } public int getAge() { return age; } }

À mon avis, cela fait beaucoup de code pour simplement dire : « Je veux une classe avec deux champs en lecture seule ». Le pire, c'est que le constructeur et les méthodes ont été générés automatiquement. Pourtant, lorsque vous examinez une pull request, vous les parcourez toujours parce que, eh bien, vous ne savez jamais si elles correspondent à ce dont vous avez besoin ou non. Bien sûr, cela peut être raccourci avec des bibliothèques tierces comme Lombok, mais ne serait-ce pas bien si nous pouvions le faire hors de la boîte ? Voyons cette même classe exacte dans Kotlin :

 class Person( val name: String, val age: Int )

C'est certainement plus court et plus simple. Les variables sont finales car nous utilisons le mot-clé val ; le constructeur et les getters sont générés au moment de la compilation. Si nous préférons ne pas avoir d'objet personne immuable, nous pouvons simplement changer val en var , et le tour est joué, nous avons une personne mutable, et tout ce que nous avons à faire est de changer une seule lettre.

Ma deuxième partie préférée dans une classe Java POJO simple est les equals() et hashCode() remplacés. Celles-ci sont à nouveau générées automatiquement la plupart du temps, mais vous devez toujours les parcourir, juste pour vous en assurer. La bonne nouvelle est que Kotlin peut également gérer cela. Changez simplement votre class en une data class et vous obtenez equals() et hashCode() à l'emploi.

 data class Person( val name: String, val age: Int )

Bref, même si j'adore Java, je voulais créer un produit minimum viable pour mon projet le plus rapidement possible en peu de temps. Et dans le cas du développement de logiciels, le moyen le plus simple d'y parvenir est d'écrire moins de code. Ainsi, ma recherche d'un meilleur langage pour le développement back-end s'est poursuivie. Avec cette pensée à l'esprit, je me suis d'abord tourné vers Node.js. Il présente des avantages significatifs : quelques lignes et votre serveur Express est opérationnel, écoute sur le port 8080 et répond avec Hello World ! chaque fois que vous envoyez une requête get.

 let express = require('express') let app = express(); app.get('/', (req, res) => res.send('Hello World!')); app.listen(8080);

Facile, simple et rapide. Exactement ce que vous attendez de l'un des langages de programmation les plus populaires. J'aime travailler avec JavaScript, et pendant un bref instant, j'ai pensé que j'avais trouvé le bon outil, mais ensuite j'ai été hanté par le fait que JavaScript est typé dynamiquement. Ne vous méprenez pas, je pense que le typage dynamique est excellent sur le front-end, mais d'après mon expérience, le fait d'avoir un back-end typé statiquement vous donne simplement une confiance supplémentaire dans le fait que votre serveur est moins susceptible de planter au moment de l'exécution en raison des incompatibilités de type . Et soyons honnêtes ici, lorsque votre back-end dessert plusieurs centaines de milliers d'utilisateurs, vous ne voulez vraiment pas que cela se produise. Node.js, cependant, offrait une fonctionnalité intéressante que je souhaitais conserver, à savoir la possibilité d'écrire facilement du code et des services asynchrones.

Avec ces exigences à l'esprit, j'ai choisi d'écrire mon back-end Kotlin Android également en Kotlin.

Kotlin : un aperçu rapide

Pour ceux d'entre vous qui n'en ont jamais entendu parler auparavant, Kotlin est un langage de programmation open source à typage statique qui prend en charge à la fois la programmation orientée objet et fonctionnelle. Il fournit une syntaxe et des concepts similaires à ceux de C #, Java ou Scala et cible principalement la JVM, mais possède également des variantes qui ciblent JavaScript ou le code natif. Il est très similaire à Java dans la mesure où Kotlin/JVM se compile en bytecode Java, donc pour les ingénieurs back-end qui ont une formation JVM, Kotlin sera facile à comprendre.

Comme l'indique sa page officielle, le but de Kotlin n'est pas d'être unique mais de s'inspirer et de tirer les meilleures pratiques de décennies de développement du langage. Il peut être utilisé avec n'importe quel IDE Java ou à partir de la ligne de commande, mais personnellement, je préfère et recommande de l'utiliser avec IntelliJ. Il est activement maintenu et mis à jour par l'équipe JetBrains, et ne vous inquiétez pas d'acheter la version payante - si vous venez de commencer avec Kotlin, la version communautaire d'IntelliJ répondra à tous vos besoins. Les trois aspects les plus importants de Kotlin que je voudrais souligner sont qu'il est : a) concis (il réduit considérablement le code passe-partout), b) sûr (d'une part, il est conçu pour éviter les exceptions de pointeur nul), et c ) interopérable (vous pouvez tirer parti des bibliothèques existantes pour la JVM, Android ou le navigateur).

Coroutines Kotlin

Tout le monde veut avoir des services qui servent les utilisateurs rapidement. Pour atteindre la capacité maximale de votre serveur, la première chose que vous pouvez faire est d'avoir une application multithread. Java est assez lourd avec ça. Lorsque vous apprenez Java, vous apprenez d'abord que si vous voulez une application multithread, vous devez soit étendre la classe Thread, soit implémenter l'interface Runnable. Les débutants ne comprennent jamais vraiment quelle est la différence (s'il y en a), mais pour ajouter à la confusion, on leur dit également de toujours démarrer un thread avec la méthode run, de ne jamais utiliser la méthode start. Ou attendez, était-ce l'inverse? Après tout, ce n'est pas grave, il ne faut de toute façon pas démarrer un thread manuellement, c'est trop cher, utilisez plutôt un pool de threads. Simple, sauf que ça ne l'est pas.

Heureusement, Kotlin a une solution encore plus simple appelée coroutines. En termes simples, les coroutines permettent d'écrire du code asynchrone et non bloquant de manière très fluide. L'idée centrale est d'avoir des fonctions qui peuvent être suspendues ; en d'autres termes, le calcul peut être suspendu à un moment donné et repris plus tard. La meilleure partie est que lors de l'écriture de code non bloquant, le modèle de programmation ne change pas vraiment, donc l'écriture de code non bloquant est essentiellement la même que l'écriture de code bloquant. Voyons deux exemples :

 fun sendRequest(): Int { /* do some heavy work */ return 1; }

Cet exemple montre une fonction de blocage. Le thread exécutant cet extrait de code n'effectuera aucun autre travail jusqu'au retour de la fonction, ce qui, dans le cas d'un appel d'API ou de base de données, peut prendre quelques secondes. Nous ne voulons vraiment pas bloquer notre thread en attendant un autre service, transformons donc cette fonction en une fonction non bloquante.

 suspend fun sendRequest(): Int { /* do some heavy work */ return 1; }

Cet exemple montre comment nous pouvons transformer notre méthode en une fonction non bloquante pouvant être suspendue. Cela signifie que si, pour simplifier, le travail lourd est un simple appel de fonction delay() de 10 secondes, le thread d'exécution continuera à travailler sur d'autres tâches pendant ce temps et il reprendra l'exécution de la fonction après le passage de 10 secondes. Code agréable et non bloquant réalisé avec un seul mot-clé.

Service asynchrone avec Ktor

Lorsqu'il s'agit d'écrire des API REST, il y a quelques étapes supplémentaires à suivre, comme démarrer un serveur intégré ou analyser la requête, et bien sûr, personne ne veut le faire manuellement. Java a Spring Boot, ce qui rend les choses vraiment faciles, et heureusement, Kotlin a un framework appelé Ktor. Ktor est un framework Web pour la construction de serveurs asynchrones. Comme son site Web l'indique, Ktor est "facile à utiliser, amusant et asynchrone". Maintenant, le plaisir est subjectif, donc je ne voudrais pas le prouver, cependant, voyons un extrait qui s'avère facile à utiliser et asynchrone.

 fun main() { embeddedServer(Tomcat, 8080) { routing { get { call.respond("Hello world!") } } }.start(wait = true) }

L'exemple ci-dessus présente un serveur Kotlin Ktor entièrement fonctionnel qui s'exécute sur un serveur Tomcat intégré, écoute sur le port 8080 et répondra de manière asynchrone avec "Hello world!" pour recevoir des demandes. Tout cela en moins de 10 lignes de code.

Ktor peut évidemment faire bien plus que cela. La présentation de toutes les fonctionnalités de Ktor nécessite son propre article, mais entre autres choses, cela facilite la connexion et l'authentification. En savoir plus sur ce que Ktor peut faire côté serveur et comment le configurer ici.

Autres avantages de Kotlin sur le back-end

Le premier avantage que je voudrais souligner est que vous pouvez utiliser les bibliothèques Java dans Kotlin, et croyez-moi, il existe de nombreuses bibliothèques tierces étonnantes pour Java qui peuvent vous faciliter la vie. Pourquoi écririez-vous votre propre implémentation alors qu'il existe une bibliothèque open source prête à l'emploi qui fait parfaitement le travail ? Leur utilisation avec Kotlin fonctionne parfaitement.

Un autre avantage majeur de Kotlin et Ktor est les vastes bibliothèques et frameworks de test que vous pouvez utiliser. Le framework Junit fonctionne comme un charme avec Kotlin, et Ktor ajoute en plus sa propre bibliothèque de tests qui vous permet d'écrire des tests de bout en bout et des tests d'intégration en un rien de temps. Vous pouvez utiliser un moteur de test personnalisé qui exécutera l'intégralité de votre application et pourra gérer les demandes comme le ferait l'application en direct.

Conclusion

Comme je l'ai mentionné précédemment, je suis principalement un développeur back-end Java ayant plusieurs applications côté serveur et des API REST derrière moi. Bien que j'aime programmer en Java, je pense qu'il n'y a pas de meilleur langage ou framework qui soit parfait pour n'importe quel travail et qui puisse résoudre n'importe quel problème. Mon approche consiste à se familiariser avec autant d'outils que possible et, lorsqu'un problème survient, à choisir le meilleur outil capable de résoudre parfaitement ce problème particulier.

Comme l'indique le site Kotlin, le but de Kotlin n'est pas d'être unique ; au lieu de cela, il s'inspire et s'inspire des meilleures pratiques de décennies de développement de langage, et je crois qu'en matière de développement back-end, Kotlin, Coroutines et Ktor forment un trio incroyable pour faire le travail. Vous pouvez en savoir plus sur Kotlin et son utilité en tant que langage de programmation ici.