BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Retour Sur Le Débat Tenu Lors De La QCon Plus Sur L’Architecture API

Retour Sur Le Débat Tenu Lors De La QCon Plus Sur L’Architecture API

Favoris

 Le débat sur l'Architecture API qui a eu lieu lors de la QCon Plus le 9 novembre réunissait six conférenciers et panélistes. Ensemble, ils ont discuté de sujets pertinents pour les ingénieurs logiciels et les architectes qui conçoivent, construisent et maintiennent des API. Ils ont d’abord échangé sur les concepts généraux tels que l’extensibilité et les cycles de vie des API puis ont débattu sur REST, GraphQL et gRPC, afin de déterminer la meilleure technologie à utiliser lors de la création d’une API.

Christi Schneider, ingénieur logiciel chez Square, a présenté "Construir avec l'Exensibilité", qui permet de comprendre de façon intense ce que signifie avoir un système extensible et les défis spécifiques qu'il crée. Schneider a bien expliqué pourquoi l'extensibilité doit être prise en compte dès le début du processus de conception et pourquoi l'extensibilité nécessite plus de réflexion que le simple espoir de cocher une case "API publique" sur votre liste de fonctionnalités. La planification des produits doit considérer l'extensibilité comme une capacité fondamentale afin de permettre au logiciel d'être facilement étendu que ce soit par d'autres équipes internes ou des partenaires externes et des tiers.

Cependant, elle prévient néanmoins que rien de tout cela n'est gratuit et qu'un système véritablement extensible entraîne des problèmes supplémentaires. Par exemple, le support aux développeurs doit inclure une documentation publique, une formation et des forums. Par ailleurs, le support client doit pouvoir déterminer si un problème fait partie du système principal ou d'un tiers. S'il est correctement mis en œuvre, un système extensible offre une satisfaction accrue aux développeurs ainsi que de nouvelles opportunités de croissance du produit.

Le cycle de vie d'une API est un sous-ensemble du cycle de vie de développement d'un système logiciel, il a des besoins similaires mais plus ciblés en matière de conception, de développement et de maintenance. Selon Kin Lane, évangéliste en chef chez Postman, l'utilisation des normes et des spécifications de l'API améliore la communication et facilite la gestion du cycle de vie de l'API. OpenAPI (anciennement Swagger) est la norme de facto pour décrire les API basées sur http. AsyncAPI est basé sur OpenAPI et ajoute une syntaxe pertinente pour les API pilotées par les événements. Les deux utilisent JSON Schema pour décrire les contrats de message qui entrent et sortent d'une API.

Le cas d'utilisation le plus courant des spécifications d'API est la documentation, mais Lane affirme que les dernières innovations vont beaucoup plus loin. Étant donné que les spécifications sont à la fois lisibles par l'homme et la machine, de nouveaux outils sont constamment créés pour améliorer le cycle de vie des API. Cela peut commencer par des tests de validation de base quand une API implémente le contrat jusqu'à des tests de santé, de sécurité et de performances générées automatiquement et qui peuvent être exécutées pendant un pipeline CI/CD. Lane pense que les améliorations et les outils futurs se traduiront par plus d'automatisation et de répétabilité, réduisant ainsi l'effort requis pour avoir un cycle de vie d'API bien entretenu.

Fran Mendez, fondateur de l'initiative AsyncAPI, a donné une démontration de codage dans laquelle il a utilisé AsyncAPI pour créer une application pilotée par les événements. Il a utilisé une version bêta d'AsyncAPI Studio, un éditeur basé sur un navigateur mais qui pouvait également modifier manuellement le YAML pour sa spécification AsyncAPI. Le contrat a défini les canaux de publication et d'abonnement et il a créé un serveur Mosquitto MQTT qui a implémenté la spécification. Le contrat a également été utilisé pour générer une application Web frontale qui utilisait des sockets Web pour communiquer avec le serveur. Le dernier élément consistait à envoyer des notifications push à Slack en fonction d'un événement spécifié. La démo était un aperçu très rapide et succinct de l'état actuel d'AsyncAPI et de certains outils qui existent actuellement. Dans les années à venir, Mendez s'attend à voir l'outillage continuer à se développer comme cela s'est passé avec OpenAPI.

Vers la fin du débat on a assisté à une confrontation d'API, une tentative pour déterminer s'il existe vraiment une technologie que nous devrions tous utiliser pour créer des API. Les trois panélistes avaient chacun une expertise dans une pile technologique spécifique, ils ont été invités à présenter les faits autour de ses capacités. Matt McLarty, le leader mondial de la stratégie API chez Mulesoft, representait REST. Alex Borysov, ingénieur logiciel chez Netflix, représentait gRPC. Et Michelle Garrett, ingénieur logiciel chez Twitter, représentait GraphQL.

Après une discussion qui a couvert les histoires d'origine, les bons scénarios de mise en œuvre, les mauvais scénarios et d'autres technologies, le résultat a été "it depends." Chaque technologie a des avantages et des inconvénients clairs mais il n'y a pas de solution miracle.

REST a la plus faible barrière d'entrée et est couramment utilisé, mais il n'est pas optimisé pour les performances ou les requêtes complexes. GraphQL nécessite un certain effort pour être configuré, y compris un serveur et ce qui décris vos schémas, offrant un résultat beaucoup plus flexible à vos clients. Il peut réduire considérablement la quantité de données transférées mais peut également être utilisé de manière incorrecte et entraîner un traitement inutile. Le cas d'utilisation idéal pour gRPC est lorsque vous devez transférer rapidement des données bien définies, de préférence entre deux serveurs. Parce que le contrat, souvent défini à l'aide de Protobuf, doit être compris des deux côtés, il ne peut pas facilement s'adapter aux modèles de données dynamiques.

Même lorsqu'on leur a demandé de choisir l'une des autres technologies à associer, les panélistes ont donné des arguments convaincants pour les deux options. Comme pour toute décision d'architecture, il n'y a jamais une seule bonne réponse. Décider quelle technologie utiliser revient à analyser les compromis et à choisir la technologie qui possède plus d'attributs positifs que négatifs pour votre cas d'utilisation.

Un récapitulatif complet de la conférence QCon Plus de novembre 2021 est désormais disponible. La prochaine conférence QCon Plus se tiendra virtuellement du 10 au 20 mai 2022 et le prochain QCon à Londres aura lieu du 4 au 6 avril 2022.

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT