Introduction
Nous avons récemment annoncé la disponibilité générale de Kiota, un générateur de clients open source pour les API REST avec une description OpenAPI. Je suis le co-fondateur de ce produit, et ce lancement correspond à mon 3eme anniversaire chez Microsoft, j’ai pensé que je prendrais le temps d’écrire à propos de mon expérience vécue en bâtissant un produit de sa genèse à sa première version chez Microsoft.
Tout au long de ma carrière, j’ai été impliqué dans plusieurs « produits » : une place de marché d’occasion pour du matériel industriel, une solution de réseau social d’entreprise, une solution de localisation et de traduction pour SharePoint et une solution d’optimisation de la gestion de la température basée sur l’IoT.
Historique
Fondation
Kiota a commencé comme une preuve de concept avec Darrel Miller pendant les vacances d’hiver de 2020. Nous voulions valider s’il était possible de construire un autre générateur de code client basé sur OpenAPI, car après avoir effectué une évaluation approfondie des solutions existantes, aucune ne convenait.
Microsoft Graph est l’une des plus grandes API publiques au monde en termes d’opérations, ce qui entraîne des exigences supplémentaires pour la génération de code. Notre équipe est responsable des expériences client (SDK, outils, etc.) et plusieurs points nous ont motivés à bâtir un nouveau générateur :
- Le générateur de code existant était difficile à entretenir et rendait toute innovation coûteuse.
- Notre équipe était la seule à contribuer à cet ancien générateur de code et la formation de nouvelles personnes était difficile.
- Il y avait une demande pour des langages supplémentaires et des « types d’API » supplémentaires.
- Nous sommes toujours confrontés à des défis causés par l’adoption d’un autre générateur de code basé sur OpenAPI.
Nous avons établi quelques règles de base pour éviter de répéter les erreurs du passé :
- Utiliser au maximum aux normes de l’industrie et y contribuer.
- Le code généré ne doit reposer que sur un ensemble d’abstractions.
- Séparation des responsabilités entre la sérialisation, l’authentification et HTTP.
- L’open source est la seule approche afin de réussir un tel outil.
- Simple à utiliser. Les API sont compliquées, gardons l’outil simple.
- Construit de manière à supporter un ensemble diversifié de langages de programmation.
Une chose qui m’a positivement surpris chez Microsoft est le fait que même s’il s’agit d’une grande entreprise, elle encourage ces initiatives. Bien que le navire prenne du temps à se diriger dans n’importe quelle direction, il y a de la puissance sous le pont. Trouver les bons interlocuteurs peut aussi parfois être complexe, mais après quelques discussions, notre organisation s’est engagée dans kiota.
Montée en puissance
Bien que l’obtention du soutien de professionnels de l’expérience utilisateur / de la documentation / juridique / confidentialité / sécurité / marketing aboutisse à un produit mieux fini, cela a un prix en coordination. Heureusement, nous travaillons avec d’excellents gestionnaires de programme, et ils s’assurent que tous les canards sont alignés.
Nous avons passé du temps à intégrer d’autres développeurs, ce qui représentait un défi, car nous déterminions également les aspects fondamentaux de Kiota. Ces aspects vont de la transposition des modèles exprimés dans les descriptions OpenAPI à l’implémentation de solutions transverses (gestion des nouvelles tentatives/redirections, authentification…). Pour se faire, nous avons développé trois langages à la fois afin d’évaluer nos solutions et de nous assurer que nous ne prenions pas de décisions dans moteur de génération de base qui favorisaient langage parmi d’autres.
Innovation
Kiota a débloqué une innovation rapide pour notre équipe. J’ai initialement implémenté la génération Go en seulement deux semaines de Fix Hack Learn (FHL) tout en apprenant le langage lui-même. Cette démonstration de la portabilité du moteur vers d’autres langages a permis de débloquer des ressources pour PHP, Python. Depuis lors, nous avons constaté une adoption significative de la version préliminaire du SDK Go.
Deux stagiaires ont principalement développé le support du Ruby. Bien que la génération de code soit complexe par nature, elle a montré que le moteur était accessible même aux membres les plus juniors de l’équipe.
Bien que Kiota restera d’abord une CLI car les CLI permettent aux utilisateurs d’être efficaces lorsque les tâches sont répétitives, la plupart des gens préfèrent les expériences graphiques (GUI). Garder les développeurs dans leur éditeur préféré contribue grandement à la découvrabilité et à la productivité. Au cours de la dernière semaine FHL, j’ai exploré la création d’une extension Kiota Visual Studio Code. La démo de cette extension a déclenché des conversations, et nous avons modifié nos plans initiaux afin de pouvoir accélérer sa publication.
Contributions open source
Travailler sur kiota m’a permis de contribuer à nos dépendances. Voir comment les communautés en dehors du domaine Microsoft collaborent se comportent fut rafraîchissant.
Récemment, Red Hat a commencé à BEAUCOUP contribuer à kiota au cours des derniers mois. Ils ne sont pas les seuls bien sûr, et nous avons d’autres « grands noms » qui évaluent kiota pour leur stratégie d’expérience client. Avoir l’opportunité de collaborer avec un tel mastodonte du monde open-source est une expérience d’apprentissage.
Livraison
Livrer un produit en version finale a quelque chose d’amer.
La livraison vient avec l’angoisse de la réception, l’inquiétude de bien faire les choses, la fierté d’avoir construit quelque chose et l’espoir que les gens remarqueront votre travail. Je suppose que toute personne créative éprouve des sentiments similaires lorsqu’elle révèle son œuvre au public.
La constante évolution du développement logiciel est probablement la différence majeure avec les autres domaines créatifs. Avant la sortie, l’équipe de développement perçoit « v1 » comme la ligne d’arrivée, alors qu’il ne s’agit en réalité que d’une autre étape du cycle de vie du produit. Bientôt, vous commencez à planifier la prochaine version mineure et à remarquer les choses qui exigent une version majeure que vous auriez souhaité ne pas manquer.
Bien que je sois un ardent défenseur du travail à distance, ne pas avoir la possibilité d’aller célébrer la sortie avec l’équipe en personne par la suite était un peu décevant. Les membres de notre équipe sont basés à Nairobi, Bristol, Montréal, Redmond et ailleurs. Nous aurons des célébrations à rattraper lors du prochain hors site.
Travaux de standardisation
Pour travailler sur le moteur interne de génération de kiota (la partie que tous les langages partagent), j’ai dû apprendre de nouvelles normes et même eu l’occasion de contribuer en retour. Il y a quelque chose d’humble à améliorer, même de manière mineure, le travail des fondateurs d’Internet.
OpenAPI et schéma JSON
Kiota s’appuie sur OpenAPI pour comprendre n’importe quelle API REST et générer des clients. OpenAPI lui-même exploite un schéma JSON pour décrire la structure des requêtes et des réponses, même si le schéma JSON n’est pas un IDL à proprement parler. J’ai eu l’occasion d’acquérir de l’expérience avec ces deux standards et d’identifier leurs lacunes lorsqu’elles sont utilisées dans le but de générer des clients. J’ai d’abord présenté une session sur ce sujet lors de la conférence API Specifications.
Des conversations ont suivi la session et m’ont amené à aider à nettoyer et à documenter les formats largement utilisés et à transmettre ces commentaires aux gens d’OpenAPI alors qu’ils travaillent sur la prochaine version. Au fur et à mesure que j’en apprends davantage sur ces normes et sur le fonctionnement de ces communautés, je cherche à m’impliquer davantage au fil du temps et à contribuer plus activement.
OData
Microsoft Graph s’appuie sur OData comme « langage » de conception pour décrire les API, les modèles et les conventions. Lorsqu’une équipe produit souhaite ajouter un nouvel ensemble d’API à Microsoft Graph, elle le fait via CSDL, le langage de descriptif d’OData. OData vient avec des conventions, et les apprendre afin de comprendre leurs implications peut être difficile. Je ne me souviens pas combien de fois j’ai été confus au sujet de l’attribut ContainsTarget au fil des ans… Les ressources de formation en conception OData sont rares. Travailler chez Microsoft a été un grand avantage car je travaille avec l’un des concepteurs d’OData.
RFC 6570
Kiota utilise des modèles d’URI pour créer des URI avant d’envoyer les requêtes au service. J’ai eu la chance de repérer une erreur dans le standard et de soumettre un erratum.
À retenir sur la normalisation
En travaillant sur Kiota, j’ai approfondi ma compréhension du Web en lisant des normes supplémentaires telles que IEEE 754, RFC 3389, RFC 9110 et plus encore. Je crois que chaque développeur devrait lire les normes dont dépendent ses outils. Oui, il s’agit d’une vaste littérature qui peut parfois être difficile à lire, mais ne pas le faire est généralement plus coûteux à réparer. L’école ne m’a pas appris grand-chose sur la lecture des normes (l’accent était mis sur les compétences pratiques et le contexte théorique) et cela semble être un moyen important de grandir techniquement.
Conférences et ressources en ligne
Conférence
Certains d’entre vous savent peut-être que je participais à environ 12 à 15 conférences par année. Depuis que j’ai rejoint Microsoft, je n’ai présenté qu’une poignée d’événements : conférence API Specifications, Collab Days Belgique et conférence des développeurs des Caraïbes. Je ne prétendrai pas que le voyage me manque, mais les gens et les conversations enthousiastes qui ont suivi me manquent.
J’ai encore du mal à concilier le temps passé dans les transports avec la portée limitée de ces événements par rapport aux événements en ligne. Mon dos va considérablement mieux à force de ne plus être entassé dans un siège d’avion de ligne plusieurs fois par mois. Je pense que je continuerai à voyager à seulement quelques événements en personne à l’extérieur de la ville par an.
Groupes d’utilisateurs
Les groupes d’utilisateurs semblent être complètement passés à un mode hybride en Amérique du Nord et ne reviendront pas aux événements en personne uniquement. Le passage au travail à distance explique ce changement, les personnes qui venaient au bureau travaillent maintenant à domicile et les groupes d’utilisateurs ont conservé la possibilité d’assister en ligne par habitude.
Cette tendance élargit l’audience, réduit l’impact environnemental et redonne du temps aux gens. J’ai eu l’occasion de passer plus de temps avec les communautés locales, c’est un moyen fantastique de « tester » de nouvelles sessions en tant que conférencier.
Événements en ligne
J’ai eu la chance de faire des présentations lors de plusieurs événements en ligne au cours des deux dernières années. J’apprécie vraiment l’efficacité de ces événements car le public est plus large et ils partagent l’enregistrement par la suite. Cependant, ne pas voir la réaction du public et ne pas pouvoir parler aux gens par la suite est frustrant pour moi.
Conclusion
Merci d’être allé jusqu’au bout. N’hésitez pas à laisser des commentaires, et à la prochaine fois !