Sérialisation Kotlin – sur le backend | par Mark Ng | Août 2021
Poursuivant notre parcours à partir de l’article “Commencer votre parcours multiplateforme Kotlin – Changer vos microservices” que j’ai écrit l’année dernière, j’aimerais mettre à jour nos progrès et partager quelques enseignements. Nous n’étions jamais sûrs que notre stratégie de partage de nos modèles d’API avec nos clients fonctionnerait réellement, non pas parce que c’était une mauvaise idée, mais parce que nous savions qu’il serait difficile de faire participer nos développeurs d’API.
Douze mois plus tard, nous avons maintenant 7 API utilisant la sérialisation Kotlin pour l’analyse JSON, ces modèles sont publiés dans notre référentiel Enterprise Nexus et utilisés par notre application Android – cela représente environ 20% de toutes les API utilisées dans notre application. Nous avons encore quelques API à convertir, plus d’équipes à qui parler, et peut-être que nous n’arriverons jamais à 100%, mais c’est définitivement un bon début. Je considère toujours la stratégie de génie logiciel comme un marathon, pas un sprint de 100 mètres, les changements prennent du temps à mettre en œuvre.
Mon article précédent se concentrait principalement sur le client, regardons donc en détail les changements nécessaires sur le backend. Les microservices d’Auspost suivent le style de l’API RESTful, utilisent JSON et sont écrits principalement en Java et Kotlin à l’aide de divers frameworks Java tels que Spring Boot et Spark Java. La stratégie de notre train de versions consiste à écrire toutes les nouvelles API en Kotlin, car cela présente de nombreux avantages par rapport à Java. Jusqu’à présent, les 7 API qui ont été converties pour utiliser la sérialisation Kotlin utilisent Spring Boot pour nos API plus grandes et Kotlin de base (pas de framework) pour les API plus petites déployées en tant que lambdas AWS.
Bien que le concept de partage de nos modèles soit assez simple, nous rencontrons toujours un certain nombre de problèmes pour le mettre en œuvre.
- Le code API a été structuré pour être utilisé dans un seul module.
- Nos scripts de construction ne pouvaient pas facilement publier nos artefacts de plusieurs modules vers notre référentiel Enterprise Nexus
- Nous ne voulions pas que les options d’analyse de sérialisation Kotlin par défaut soient définies par Spring Boot
De plus, comme la plupart de nos API étaient empaquetées sous forme de fichier WAR, nous devions décider où notre fichier WAR devait être construit. Nous avions deux options – dans le répertoire de construction racine ou dans le répertoire de construction de l’un des modules enfants. Nous avons décidé de conserver l’artefact WAR dans le répertoire de construction racine afin de ne pas avoir à modifier nos scripts de déploiement existants.
Lors de la modification du code Java pour utiliser des modèles Kotlin, nous suivons ces étapes ;
- Ajout du plugin Kotlin et des dépendances pour prendre en charge Kotlin.
- Conversion de classes Java en classes de données Kotlin. Dans certains cas, les classes contenaient des annotations pour la persistance de la base de données et la sérialisation JSON, nous avons donc divisé les classes en entités et modèles
- Suppression de tout code Jackson et ajout de la sérialisation Kotlin tout en corrigeant les échecs de test
- Divisez le projet en 2 modules appelés application et modèle
Étant donné que la dernière version de Spring Boot prend en charge la sérialisation Kotlin et Kotlin depuis un certain temps, vous n’avez vraiment pas besoin de faire quoi que ce soit de spécial pour que cela fonctionne. Spring Boot détecte automatiquement l’annotation @Serializable dans vos classes et utilise le bon analyseur pour toutes vos demandes et réponses d’API.
Cependant, si les options d’analyse JSON par défaut sont trop restrictives ou ne répondent pas à vos exigences, vous devrez ajouter du code supplémentaire à votre application Spring Boot. Voici le code ;
Configurez votre analyseur JSON
Configuration de l’analyseur JSON
Utilisation de l’analyseur JSON pour la communication API à API
Ce référentiel contient un exemple d’API qui montre comment nous structurons notre application Spring Boot et configurons la sérialisation Kotlin.
Une fois le code terminé et nos tests réussis, notre prochain défi consistait à transférer nos artefacts de divers modules dans notre référentiel Enterprise Nexus. Nos API existantes ont été configurées à l’aide des plug-ins de publication Maven et de publication Gradle pour créer des versions et publier nos artefacts sur Nexus. Bien que le plugin de lancement Gradle prenne en charge les projets Gradle multi-modules, nous l’avons trouvé assez compliqué à configurer et avons décidé d’écrire notre propre script bash pour incrémenter le numéro de version et l’enregistrer dans Git. Nous avons ajouté ce script à nos référentiels git à l’aide d’un sous-module git pour nous assurer qu’il est toujours à jour.
Une fois nos modèles sur notre Enterprise Nexus, la dernière étape consistait à changer nos clients pour les utiliser. Lors de l’ajout de nouvelles API à notre application, l’essentiel de l’effort consiste à définir les modèles, car les mêmes en-têtes et codes d’erreur sont utilisés par toutes nos API. En fait, je pense qu’il y a beaucoup d’avantages à utiliser des modèles partagés dans un SDK. Si vous y réfléchissez, un SDK
- nécessite plus de frais généraux pour maintenir
- moins flexible
- ne peut pas utiliser la technologie / les cadres préférés du client, par exemple Coroutines, RxJava
- implémenter un client réseau différent tel que OkHttp, client Apache Client afin que vous vous retrouviez avec des technologies en double qui font la même chose
Dans l’ensemble, nous sommes très satisfaits de cette initiative et continuons de l’implémenter dans davantage d’API pour partager leurs modèles Kotlin. Voici un résumé de nos principaux avantages
- L’API Java existante est maintenant activée pour Kotlin
- Le client et le serveur partagent le même code de sérialisation JSON
- La sérialisation Kotlin est un analyseur JSON beaucoup plus rapide et suit plus strictement la norme JSON.
- Possibilité de partager des modèles sur d’autres plateformes comme iOS, javascript à l’avenir. Tous les types de données, y compris les dates, sont portables sur toutes les plateformes.
Bien que toutes les API de notre équipe utilisent Spring Boot, je voulais créer une API avec Ktor depuis un certain temps. Voici un exemple d’application Ktor avec les mêmes fonctionnalités que l’application Spring Boot que j’ai partagée plus tôt. Ktor a l’avantage d’être construit à partir de zéro pour prendre en charge la sérialisation Kotlin et les coroutines Kotlin, ce qui signifie essentiellement moins de code et un développement plus rapide. C’est incroyable le peu de code dont vous avez besoin pour accomplir la même chose.
Comme de nombreux développeurs aiment utiliser l’injection de dépendances, j’ai également inclus une autre version de l’application Ktor utilisant le framework Koin dans ce référentiel. Il est structuré de la même manière que l’exemple d’application Spring Boot afin que vous puissiez faire une comparaison similaire.
Comme les autres composants, vous devez installer Koin pour l’utiliser. Lors de l’installation de Koin, vous devez définir le Modules qui définissent comment vos objets sont injectés.
La douane Module définir comment nos interfaces sont implémentées.
Injecter et utiliser le GreetingService dans notre API.
Soit dit en passant, cette initiative fait partie de notre feuille de route d’ingénierie pour supprimer les parseurs JSON en double de notre application Android.
Commentaires
Laisser un commentaire