Comparaison des bibliothèques de construction de l'interface de programmation

Nexmo dispose d'un CLIque nous utilisons comme alternative au tableau de bord. Il vous permet de gérer votre Account Nexmo et d'utiliser les produits Vonage à partir de la ligne de commande. Nous avons cet outil depuis environ 4 ans, et il est écrit en Node.js.

La semaine dernière j'ai expliqué pourquoi nous prenons le temps de le réécrireet j'ai partagé quelques informations sur le processus que nous utilisons pour réécrire l'interface de commande Nexmo.

Aujourd'hui, je vais entrer dans les détails, partager les cadres que nous avons analysés et les critères que nous avons utilisés pour le faire. Je vais également vous montrer les avantages et les inconvénients de ceux que nous avons choisis pour construire nos preuves de concept.

Critères de référence

Après avoir effectué une rétrospective de notre interface de ligne de commande interne et identifié un ensemble d'exigences, nous avons dressé une liste d'exemples de commandes. Ces commandes nous ont aidés à définir un ensemble de critères pour évaluer les bibliothèques utilisées pour créer des interfaces de ligne de commande. Nos critères visaient à répondre à quelques questions :

• Quelle langue est prise en charge par la bibliothèque ?

• Est-il activement entretenu ?

• Prend-il en charge les sous-commandes ? nexmo app list

• Prend-il en charge plusieurs formats de sortie ?

• Dispose-t-il d'un mécanisme d'extension ?

• Les commandes peuvent-elles avoir plusieurs alias ?

• Peut-il générer des binaires ?

• Comment se présente la gestion de la configuration ?

• Est-il multiplateforme ?

• A-t-il une fonction d'autocomplétion des commandes ?

• Peut-il avoir des commandes interactives ?

• Peut-on définir des drapeaux mondiaux ?

Armés de cette liste de questions brûlantes, nous nous sommes mis en quête d'un maximum de bibliothèques de construction CLI qui cochaient la plupart des cases et vérifiaient leurs caractéristiques par rapport à notre liste de critères de qualification. Au final, nous avons réduit notre liste à six bibliothèques, pour JavaScript, TypeScript et Go, en nous basant sur les compétences linguistiques disponibles dans l'équipe : oclif, gluegun, ink, caporal, cli et cobra.

Comparaison des caractéristiques

Nous avons parcouru la page d'accueil de chaque framework et relevé les fonctionnalités qu'il prenait en charge, créant ainsi une matrice d'analyse. Nous avons utilisé pour signifier que le framework supporte totalement cette fonctionnalité, ❎ pour signifier que le framework ne supporte pas cette fonctionnalité et ✳️ pour signifier qu'il n'y a qu'un support partiel. Voici à quoi ressemblait notre matrice pour les six cadres que nous avons identifiés :

En examinant la liste des fonctionnalités, nous n'avons pas pu identifier un vainqueur clair, d'autant plus qu'il y avait encore quelques inconnues. Nous avons donc décidé de choisir 3 frameworks et de construire une preuve de concept avec chacun d'entre eux.

PoCs

Notre premier choix pour construire une preuve de concept a été oclif. La raison principale pour laquelle nous l'avons choisi est qu'il semblait cocher la plupart de nos cases, certaines même deux fois (il supportait les plugins, et il y avait un plugin pour construire des plugins).

Le deuxième choix a été caporal parce que la bibliothèque semblait raisonnablement similaire à notre cadre actuel, commander. Cela signifie que la courbe d'apprentissage et le temps nécessaire à la réécriture auraient été considérablement réduits.

Enfin, notre dernier choix pour la preuve de concepts était inkNous l'avons choisi parce qu'il cochait suffisamment de cases pour que cela en vaille la peine et qu'il bénéficie d'un écosystème massif.

Une fois les cadres identifiés, nous avons défini le champ d'application de la validation des concepts. Nous voulions quelque chose de représentatif de l'interface de programmation finale plutôt que de construire un exemple. Hello World exemple. En même temps, il devait être suffisamment petit pour que nous ne nous sentions pas gênés de jeter la preuve de concept à la fin de cet exercice. Nous avons opté pour la construction de la version actuelle de nexmo setup et nexmo number:list . Cela signifiait que nous pouvions tester les drapeaux globaux, la gestion de la configuration, les sous-commandes, les formats de sortie, l'interactivité et les différents cadres linguistiques.

Choisir notre prochaine bibliothèque de construction CLI

Lorna, Dwane et moi-même avons pris chacun un des trois frameworks, et nous avons commencé à construire nos preuves de concepts. Une fois que nous avons terminé, nous avons présenté les avantages et les inconvénients de travailler avec chaque bibliothèque et la façon dont ils sont liés à certaines de nos autres exigences.

Caporal

Lorna a construit le caporal PoC. Le plus grand avantage était qu'il était possible de migrer notre CLI actuel de commander vers caporal sans nécessiter une réécriture complète. Cela nous a permis de gagner du temps.

Les inconvénients étaient pour la plupart similaires à nos commander et le projet n'est pas maintenu aussi activement que nous l'aurions souhaité. Nous devrions probablement forker le projet et maintenir une communauté autour de lui, ce qui annulerait une partie de la vitesse que nous avons gagnée si nous n'avions pas à réécrire. Cela signifierait également que certains de nos besoins, comme les plugins, devraient être créés à partir de zéro.

Encre

Dwane a construit le ink PoC. Le plus grand avantage était qu'il utilisait React comme framework, ce qui apporte une communauté et un écosystème massifs. Il y avait beaucoup de plugins disponibles pour la plupart des choses que nous voulions pour notre prochain CLI, mais certains d'entre eux n'étaient pas encore compatibles avec la dernière version. ink version. Il y avait aussi un diffing de type React pour la sortie du terminal, ce qui signifie que nous pouvions non seulement construire des commandes interactives mais aussi avoir une sortie dynamique. Les inconvénients n'étaient pas rares, l'un d'entre eux étant le fait qu'il était basé sur React, et que l'équipe devait se familiariser avec lui. Un autre inconvénient était que ink n'était pas adapté à une grosse CLI comme la nôtre.

pastelD'un autre côté, il y avait un cadre mieux adapté, construit au-dessus de inkqui nous offrait les mêmes avantages, Dwane a donc construit un PoC en l'utilisant. pastel Cependant, ce framework avait ses propres inconvénients, notamment le fait qu'il n'avait pas été activement maintenu au cours de l'année écoulée, la dernière version datant de 10 mois.

Oclif

J'ai construit le oclif PoC. Le plus grand avantage est que oclif répondait à la plupart de nos exigences et fonctionnait comme annoncé. Nous n'avions donc pas besoin de construire une grande partie des fonctionnalités pour les besoins non liés à l'utilisateur, comme un système de plugins. Il était également mieux adapté à la construction de CLIs de grande taille. Les conventions de structure de code qu'il utilise facilitent la maintenance du code.

Cependant, il y a aussi un certain nombre d'inconvénients. Même si le site web annonce que JavaScript et TypeScript sont pris en charge, la documentation est très axée sur TypeScript, au point que la plupart des cas d'utilisation avancés ne sont pas documentés en JavaScript.

Le fait que j'ai choisi TypeScript pour construire le PoC signifie également que l'importation du SDK de Nexmo Node.js SDK Nexmo Node.js tel quel serait problématique, nous devrions donc d'abord consacrer du temps à l'ajout du support TypeScript.

Quelle est la prochaine étape ?

Après avoir soigneusement étudié les avantages et les inconvénients, nous avons choisi d'aller de l'avant et de construire le prochain CLI Nexmo en utilisant oclif.

Nous l'avons choisi parce qu'il bénéficie d'un support et d'une documentation de qualité, ainsi que d'une communauté croissante de personnes qui l'utilisent. Il est également activement maintenu. Nous ajoutons également un support complet de TypeScript à notre SDK Node.js, il nous a donc semblé judicieux de conserver la même pile pour notre SDK et notre CLI.

Pendant que nous travaillons à l'amélioration de notre CLI Nexmo, vous pouvez suivre nos progrès à l'adresse suivante https://github.com/nexmo/nexmo-cli. Si vous avez des suggestions ou des problèmes, n'hésitez pas à les soulever dans GitHub ou dans notre communauté slack.