Fiabiliser ses applications grâce à l’OpenAPI

Paul: [00:00:00] Eh bien salut Baptiste, salut à tous, et de nouveau pour un petit épisode de Parlons Dev. Alors disclaimer, j'ai les mains pleines de peinture, c'est parce que je change autant d'apportement que de framework JavaScript. Bref, pas d'inquiétude, tout va bien, j'aurais pu les laver, mais c'est peine perdue, honnêtement ça ne tiendra pendant encore quelques jours.

T'as

Baptiste: prévu de faire un bain de white spirit prochainement ?

Paul: Écoute, je vais me badigeonner d'huile d'olive bien provençale. C'était l'huile d'olive de Nyon. De Nyon. De Nyon. De Nyon. C'est un peu égaré de chez moi. Je ne me lave qu'à l'huile d'olive provençale au salon de Marseille. Enfin bref, du coup, pas d'inquiétude, j'aurai les mains un peu dégueulasses, je m'en excuse.

Comment

Baptiste: vas-tu mon cher Baptiste ? Écoute, je vais très bien, je te remercie. Je pensais que tu nous parles du sujet d'aujourd'hui, je suis sûr que ça va intéresser nos auditeurs aussi.

Paul: Bah écoute, j'espère, en tout cas si tu es là, c'est que toi aussi, sinon je demande à voir pour l'instant, je suis sceptique.

Ok, très [00:01:00] bien, j'ai à peine la pression, je vois, excellent. Bon, mais du coup, de quoi va-t-on parler aujourd'hui ? Je vais essayer de vous partager en tout cas une certaine forme de hype, qui est purement personnelle, ça n'a rien de nouveau, mais en ce moment je m'intéresse pas mal à la SpecOpenAPI, Au API, en français du coup, qui est une specification qui permet de décrire des API REST.

En

Baptiste: français, ça se dit API ouverte, le spec.

Paul: C'est vrai, l'interaction littérale, excusez-moi, c'est ton sang canadien qui ressort. C'est... je ne me rappelle plus de la phrase du joueur de hockey là. Je l'emmerde ton anglais je crois, enfin je ne sais plus, ceux qui ont la ref le savent, mais du coup oui, l'API ouverte du coup, qui est open bar, donc dernièrement je m'intéresse pas mal à ça, à savoir tout ce qui va être code génération autour de tout ça, les leviers d'automatisation que peuvent...

Procurer, autoriser, peu importe, débloquer une spec [00:02:00] OpenAPI rigoureusement écrite Mais aussi ne serait-ce que l'état, enfin comment en tant que développeur fronte, peu importe même bac en réalité Un développeur sera toujours quasiment exposé à une spec OpenAPI même s'il ne le sait pas Rapidement de l'historique, parce que je ne suis pas un expert de l'histoire d'OpenAPI L'idée ça va vraiment être de partager un peu mon retour d'expérience Mon retour d'expérience en devenir sur ces sujets là, parce que c'est des trucs que je...

Que j'aborde de plus en plus sur des réfacteurs de grande envergure. Est-ce que tu as quelque chose à rajouter mon cher ?

Baptiste: Je suis pressé d'entendre cette nouvelle histoire de Père Popole, qui vient de nous parler de Panapy High. C'est la première

Paul: et dernière fois que j'ai ce surnom désormais, Père Popole.

Je vais donc te raconter cette chère histoire. Qu'est-ce que l'OpenAPI ? En tant que développeur mortel comme tout le monde, tu es déjà allé sur un Swagger, tu vois ce que c'est qu'un Swagger UI même, à savoir que Swagger est l'ancien nom d'OpenAPI dans [00:03:00] sa globalité, l'OpenAPI a trois versions, je ne m'y connais pas du tout sur la première, j'ai itéré sur des specs 2.0 et majoritairement 3.0, à savoir que c'est réellement de ma connaissance, je ne suis pas un expert de cette migration ni de ces...

De cet upgrade là mais c'est vraiment un changement sémantique de cette spécification et il existe des outils en ligne officiels d'OpenAPI pour faire ces migrations là si tu veux. C'est à dire que tu lui envoies ta spec 2.0, il t'en génère une 3.0, c'est vraiment un changement dans l'architecture du modèle de données.

Surtout au niveau des security hosts je crois, enfin bref. Donc qu'est-ce qu'on retrouve dans une specOpenApi, on retrouve une définition de API REST, donc une description de route avec leurs méthodes, les paramètres, query, headers, passParameters, peu importe Et aussi une description, une signature de ces endpoints là donc à savoir leurs données en entrée et leurs retours si on parle d'une response, ça sera le bodyResponse et si on parle d'une requête, méthodePost, etc, [00:04:00] sauf si vous faites des gets avec des bodies ou des grandins vous fasse il pourrait y avoir ce genre de...

c'est autorisé en tout cas, tu vois, l'aspect OpenAPI permet de faire ce genre de truc là, après certains outils non enfin bon aussi dans cette specification Il y a plusieurs manières de faire les choses les plus idiomatiques et les plus propres, c'est vraiment presque un dom, enfin c'est pas un langage, mais il y a des leviers natifs à l'aspect qui permettent de la centralisation de schémas, de typage, de la mise en lien entre les différentes endpoints, savoir si on fait du crude à ses basiques.

Par exemple, lorsqu'un QA va aller sur un swagger, c'est cool quand même que lorsqu'il crée l'instance, ça puisse récupérer l'ID qui vient d'être créé et ça peut faire de l'autocomplétion sur d'autres endpoints qui permettront peut-être d'update la data ou de la delete, etc. En gros, tu peux avoir des workflows que tu décris dans ta spec qui peuvent être testés à la volée, etc.

C'est vachement cool, surtout si tu fais des pen tests [00:05:00] un peu avancés et que tu envoies ça à une boîte externe, ça leur permet de comprendre un peu mieux ton cœur métier et de ne pas avoir à chercher dans un swagger monstrueux. C'est toujours cool à avoir, c'est des outils qui existent et ça c'est assez récent, je crois que c'est même 3.1, c'est vraiment les entrées de Links.

Ou tu peux faire référence à des modèles de données, je ne sais

Baptiste: pas. Donc c'est quoi ça ? C'est des outils externes que tu… Pas du

Paul: tout, pas du tout. Non, excuse-moi. Là, c'est vraiment des entrées natives à l'aspect OpenAPI. Mais l'idée, la plus-value que je vois dans l'immédiat, c'est déjà que tu puisses faire des liens entre tes endpoints et faire transpiler d'une certaine manière ton cœur métier.

Dans une

Baptiste: ordonnance, dans une suite des points. Par exemple, dire que, je ne sais pas, une root get retourne, je ne sais pas, un utilisateur, user, tu définis son type et tu peux partager ce type dans plusieurs requêtes, c'est ça ? Dans plusieurs endpoints, oui, c'est ça.

Paul: Mais là, dans l'idée, c'est pas...

Imaginons que tu crées une entité en base, du code classique, sur un poste, soit ça va te permettre d'auto-complete avec les informations qui ont été créées, le request body d'un foot, un update, ou ne serait-ce que d'un delete, [00:06:00] etc. Pour avoir des... Des successions d'actions qui font sens dans leur logique métier.

Il y a plein de choses qui existent, principalement, ce qui m'intéresse le plus dans l'aspect Open API, c'est aussi le typage, c'est-à-dire que peu importe la stack de l'API, Qui fait tourner mon swagger, j'ai un point de data pivot spécifique qui est l'aspect OpenAPI et que je peux transpiler dans mon propre langage, ma propre stack, à savoir en règle générale personnellement ce qui m'intéressait le plus c'est de générer des types TypeScript Pour le front

Pour le front ou même d'autres services, typiquement des backend for frontend, des BFF ou en français Voilà, j'avoue, des serveurs pour front-end. D'ailleurs oui, tu m'as promis un super article sur la recrudescence un peu de ce mouvement des [00:07:00] BFF, à savoir rapidement, parce qu'on va quand même un peu aborder ce sujet-là après.

Le BFF, vraiment, va permettre de faire de la création de données entre plusieurs endpoints, et il existe même des outils d'autogénération de… Template, on va dire, OpenAPI dans quasiment tous les langages, et même des trucs officiels OpenAPI CodeGen, API Generator, qui permettent de générer, que ce soit côté client mais aussi back dans Spring Boot, dans Go, enfin peu importe, vraiment toute l'architecture de base, avec les différents contrôleurs, etc.,

de

Baptiste: l'aspect que tu utilises. Donc si je comprends bien, c'est une spec OpenAPI ? On fait tourner un outil dessus et ça génère du code qu'on peut exécuter alors c'est pas du plug

Paul: and play c'est à dire qu'il faut quand même coder la logique derrière mais ça va vraiment instancier tout ce qu'il y a

Baptiste: il faut quand

Paul: même le plugger à ce prompt là mais non c'est malgré tout un très gros avantage surtout [00:08:00] sur des migrations de stack ou sur la création d'un MFF typiquement imaginons je crée un nouveau site qui...

Va taper 6 ou 7 API, pas toutes les mêmes routes, etc. Dans ce cas-là, il faut faire un peu de tri. Et c'est là aussi qu'il y a une complexité intéressante, à savoir comment manipuler une spec open API de manière durable dans le temps. C'est-à-dire comment tu fais pour, par exemple, enlever certains endpoints d'une spec open API pour ensuite la donner à ton outil de code gen pour ne venir générer que les endpoints dont tu as besoin dans ton BFF, par exemple.

Ça, c'est le genre de complexité sur lesquelles... Je me suis intéressé et à savoir pourquoi pas un éditeur en temps réel Par exemple tu vois ton swagger UI plutôt que de pouvoir taper des endpoints tu peux dire ça par exemple je veux le supprimer de ma spec et ça va te pondre une spec open API que je pourrais appeler trimée, stripée, peu importe qui sera réduite à la seule utilité dont tu en auras besoin et l'idée ça serait quand même de pouvoir toujours la resynchroniser de tenter de faire des updates avec celle de base [00:09:00] c'est tout ce genre de truc c'est avancé comme besoin oui c'est super niche mais c'est typiquement le genre de besoin dont on a besoin actuellement à mon taf Et même très généralement, pour plein de raisons, pour de la sécu Sans rentrer trop dans les détails du coup, mais peu importe où est-ce que tu travailles Un BFF tu vas attendre en règle générale de la validation des entrées, mais aussi en règle générale des sorties C'est à dire que tu ne veux pas exposer des champs dont tu n'as pas besoin, donc tu veux extraire certaines réponses Donc il y a vraiment besoin d'un niveau de granularité dans cette stratégie Dans cette réécriture et cette surcharge d'une spec open API déjà existante, ne serait-ce que dans la définition des endpoints, mais aussi la signature des responses.

Donc

Baptiste: c'est des outils que tu utilises pour faire cette transformation ? Non, pour le moment

Paul: c'est de la R&D, et ça serait plutôt des choses custom, à savoir que du coup, si je devais décrire en deux étapes un peu ce... En tout cas c'est ce qui m'intéresse dans l'immédiat, c'est vraiment par exemple de prendre une spec open API brute, d'une [00:10:00] API que tu ne veux pas entièrement exposer, trouver un outil qui permet de transpiler cette spec open API dans une substance dont seulement toi as besoin, et enfin trouver un outil open source, qui là pour le coup, enfin même les deux pourquoi pas seraient open source, qui serait de la code gen pour pouvoir générer les premières fondations de ton API fondamentalement dont tu auras vraiment besoin.

Et qui serait donc un mashup de plusieurs specs open API. A voir, de nouveau c'est vraiment de la R&D pour le moment, mais je trouve vachement intéressant Et c'est ce qui me fait m'intéresser à l'écosystème, de tout le plein de projets open source qui existent déjà Et qui se basent sur une spec OpenAPI pour autogénérer des trucs On en a parlé tout à l'heure, il y a OpenAPI Awesome, qui n'est pas extrêmement à jour honnêtement Mais qui fait quand même une bonne synthèse de plein d'outils open source qui existent dans le milieu Par exemple OpenAPI TypeScript Qui permet vraiment de générer des types TypeScript en se basant sur des schémas, mais pas que, mais aussi une interface globale qui [00:11:00] permettra de récupérer Les endpoints exposés par cette OpenAPI, donc imaginons une interface PaaS qui est un record qui contient en réalité des routes qui contient sa méthode etc et qui pour telle méthode renverra tel modèle de données, aura tel paramètre etc donc il faut quand même construire tes services autour de ça, tu peux strictement les typer autour de ça mais malgré tout lorsque tu démarres une nouvelle fonctionnalité ou peu importe L'objectif que j'aurai personnellement, c'est avant toute chose, si j'ai un nouveau ticket, j'ai une migration côté back, une mutation d'un modèle de données, je mets à jour ce package, en réalité, parce que si dans un monorepo, ce sera un package, qui viendra lever des erreurs, peut-être à la fois dans mon BFF et dans mon front, en disant, là j'ai eu une mutation de mes modèles de données, il faut le gérer, ça va casser ici, ou c'est un bloc qui n'est pas couvert, etc.

Est-ce que je m'exprime correctement sur cette substance d'interface qui transpile une spec OpenAPI ?

Baptiste: [00:12:00] Là tu parles vraiment d'un outil qui permet, ça prend une spec OpenAPI, ça génère des types TypeScript qui représentent complètement l'interface j'allais dire l'API de l'API REST ce que ça prend comme paramètre, ce que ça retourne les différents statuts seulement les types

Paul: du coup on en parlait tout à l'heure rapidement aussi mais du coup ce package là précisément s'appelle OpenAPI TypeScript il existe aussi OpenAPI TypeScript Fetch qui peut Qui est en fait plus ou moins un set de fonctions qui accepte un générique Et qui en fonction de ses entrées va retourner automatiquement les bons typages Si tu lui balances telle route etc Dans l'idée là actuellement si tu lui consommes que le type Il faudra malgré tout toi même avoir donné à tes services, à tes fonctions, à tes features, tes services, peu importe je sais pas quoi La partie du code qui fait

Baptiste: la vraie requête HTTP derrière.

Exactement, totalement. En

Paul: fait tu n'utilises pas de feature, tu utilises un fetch natif, peu

Baptiste: importe. Ou XML HTTP request [00:13:00] quand on a un vrai. Du SOAP, allons-y. De ce que je comprends, moi je vois surtout un très gros intérêt pour les développeurs front-end. Parce qu'on parle de bff mais personnellement j'ai pas créé de tel service avec plein d'open API parce que derrière il faut mettre en lien plein d'API REST mais je vois très bien l'intérêt que ça peut avoir si on a une Une API qui est développée dans un autre langage que le javascript et qu'on veut quand même partager des types, parce qu'il existe des outils comme tRPC comme plein d'autres choses, par exemple il y a beaucoup de développeurs qui maintenant veulent créer leur API directement dans Next.js ils utilisent Next pour développer le front ils créent leur API aussi dans le dossier root anciennement, maintenant ça a été renommé avec l'app rooter mais de Next.js Et avec tRPC ça permet de partager des types entre le frontend et le backend c'est que du TypeScript partout donc c'est plus facile [00:14:00]

Paul: tRPC c'est vraiment du RPC je crois que c'est pas vraiment comment dirais-je C'est vraiment from scratch.

L'idée c'est aussi de pouvoir migrer un projet existant qui ne sera pas forcément strictement typé sur ces contract API ou ces signatures et de vraiment ajouter cette surcouche de strictness, de

Baptiste: rigueur en surcharge. DRPC c'est vraiment un outil qu'il faut utiliser de bout en bout sinon ça ne marche pas.

Il

Paul: faut aussi que ça soit un API Node.js. Oui. Oui, et

Baptiste: donc l'intérêt de l'OpenAPI du coup c'est que ça marche avec n'importe quoi, c'est une vraie standardisation, quel que soit l'écosystème, quel que soit le front, quel que soit le backend ou les backends, c'est censé permettre une uniformisation.

Totalement, totalement.

Paul: Et cet aspect de, dans les générateurs que vous trouverez sur internet et tous les officiels d'OpenAPI, il y aura ce, comment dirais-je, Cet état du générateur qui est est-ce qu'il est compatible [00:15:00] avec du multiserver ou pas c'est-à-dire est-ce qu'il accepte une multitude de specs OpenAPI en entrée à savoir qu'il y a un risque de surcharge du coup si deux specs OpenAPI décrivent la même route ça peut être un peu risqué tout ce genre de trucs c'est des complicités qu'il faut prendre en compte avant je pense, je suis quasiment sûr qu'il y a des perceurs là-dessus j'ai jamais utilisé exactement le multiserver j'ai déjà tenté de générer des trucs en Spring Mais malgré tout c'est des sujets à mon avis c'est vachement intéressant et c'est cette idée de Enfin moi, même encore plus, je trouve que l'aspect OpenAPI sans rentrer dans l'idée de GodGen, mais plus de réflexion de projet, de gestion, d'estimation dans le temps, de nouvelles fonctionnalités avec différentes équipes, même si vous travaillez dans la même équipe, c'est un moyen de communication, c'est-à-dire que c'est un prisme qui relate l'état d'un ticket, par exemple côté back et côté front, en règle générale, et c'est dans mon taf actuel, c'est ce qui se passe, [00:16:00] le front ne va démarrer sa tâche que lorsque le back l'aura déjà implémenté.

Sauf que je trouve que c'est dommage, parce que du coup déjà on ne travaille pas sur les mêmes sujets en même temps Du coup on est entre guillemets en retard, entre très gros guillemets, parce que du coup c'est juste comme ça qu'ont été priorisés les choses Mais aussi parce que si on avait une signature stricte, on pourrait mieux estimer déjà ce qu'il y a à faire côté front Et ça éviterait aussi des allers-retours où parfois il y a des mutations qui n'ont pas été attendues, donc on a des resizing etc Mais ça permettrait surtout de faire les tâches en même temps, et aussi Idéalement, de mettre à jour nos serveurs de mocks, nos tests end-to-end, en prévision de ces différentes évolutions-là, et donc en gros être synchronisés.

Et si on a vraiment des outils qui nous permettent, via la mutation de cette SpecOpenAPI, de auto-générer nos tipages, et de propager tous les break-in changes dans nos code-base, honnêtement la complexité de nos tickets est largement réduite. Enfin, largement réduite. Par un facteur 1 million. C'est une généralité.

Voilà, c'est ça. La suite de Fibonacci en [00:17:00] sueur, parce que c'est comme ça qu'on estime, t'as pas trop l'expérience de cette agilité là, mais enfin bref, ça serait malgré tout un gain de confiance aussi quant à la stabilité de notre appli et son coverage. C'est mon avis.

Baptiste: Et par rapport à ça, c'est vrai que cette idée pour les développeurs, principalement Front, parce que je suis surtout développeur Front donc je m'intéresse principalement à ça, mais sur Twitter j'ai pu voir des gens discuter du fait Qu'il faudrait que dans leurs équipes, avant de développer une fonctionnalité pour de vrai, côté back, côté front, on se mette d'accord sur ce que doivent recevoir les routes de l'API, ce qu'elles retournent.

Et derrière, les développeurs front peuvent développer en mettant en place un système de mocking avec API Mock, MSW. Qui permet directement de faire ses requêtes http parce que [00:18:00] c'est important il y a des problèmes de headers et des problèmes de réponses qu'il faut parser Donc faire sa requête HTTP dès le départ, plutôt que de moque ça de manière dégueulasse en ayant des données statiques dans son front ou ce genre de truc, avec un serveur de moque, après, dès que le back est implémenté, il n'y a plus qu'à retirer le moque et on fait les requêtes sur le vrai back et ça roule, zéro

Paul: problème.

A savoir que ce mock dont tu parles, tu parles de mock statique, donc dans l'idée j'imagine que tu penses à le retour d'un service auquel tu aurais enlevé le fetch et tu renvoies juste une donnée statique tant que le truc n'est pas implémenté, c'est que quand tu intègres un mock, même s'il renvoie de la donnée statique ton truc MSW, si c'est vraiment des lookups ou des trucs statiques, tu renvoies des trucs statiques, ça fait sens.

Mais c'est que tu peux le réutiliser. J'en sais rien, pour une raison x ou y Le bac n'est pas stable dans un moment précis Et t'as besoin de faire une démo, t'as besoin de tester un truc avant de faire une release Bon bah hop, petit air sur tourmoc [00:19:00] Mais ne serait-ce que tes tests d'intégration, tes tests end-to-end etc Ça dépend de la capacité que t'as à gérer tes tests flakies Défauts positifs ou peu importe sans trop passer de temps sur cette définition-là, que je ne maîtrise pas d'ailleurs, mais ça te permet d'être plus sûr et confiant dans ce que tu vas livrer.

Après du coup, ce n'est pas aussi simple, c'est-à-dire qu'il y a des risques. En tout cas, j'en vois personnellement, à savoir que l'aspect OpenAPI, c'est comme n'importe quoi. Il y a plein de choses qui peuvent être cool et ça peut être bien fait. Mais tout ce qui peut être bien fait peut être mal fait, et c'est pas rare du tout, genre vraiment pas, de tomber sur des swagger qui sont pas typés, qui décrivent juste des entrées de route, et encore, c'est à dire que bah du coup, en fait soit souvent l'excuse c'est bah notre donnée elle est dynamique, c'est à dire que tu peux pas la prédire.

On peut retourner soit en chien,

Baptiste: soit en chat, soit en voiture, soit en [00:20:00] portable. Du

Paul: coup, ça s'appelle un union, ou à la limite un onion, et ça s'appelle any of, one of. En gros, tu peux vraiment retourner n'importe quoi, c'est-à-dire que tu peux même typer comme quoi un arrêt peut être un tuple, peu importe, tu peux vraiment tout strictement typer quasiment, je ne suis pas non plus un expert, il doit y avoir des use case un peu relous.

Le seul truc un peu chiant parfois, c'est vraiment les fichiers, etc. Ça peut être un peu chiant, je balance souvent des binaires, des octet binary, bref. Mais du coup, le gros souci de ces outils de code generation, c'est que ça ne va pas créer de la data. Tu ne peux que transpiler une substance qui est déjà en place.

C'est-à-dire que tu ne peux pas prédire, tu ne peux pas anticiper. Ça ne peut pas augmenter la maturité d'une API, c'est ça. C'est-à-dire que tu ne peux pas créer de rigueur sur un truc qui ne l'est pas. Donc il faut en avoir conscience et lorsque tu fais des réfracteurs de grande envergure sur [00:21:00] plusieurs API sur des centaines d'endpoints, plusieurs centaines d'endpoints ben avant même de regarder si c'est quelque chose que tu veux faire c'est de regarder quelle est la qualité des specs open API que tu consommes à

Baptiste: partir de ça j'ai une question à te poser est ce que tu penses que dans le meilleur des mondes euh Il faudrait générer une spec OpenAPI à partir de son code.

J'ai vu pas mal d'outils, par exemple pour Adonis, pour Laravel, pour Django, qui permettent de faire de l'analyse du code, et à partir du code, générer une spec OpenAPI. Les repos sont plutôt bien stars, donc j'ai l'impression que pas mal de gens utilisent ça. Ou est-ce que tu penses qu'il vaut mieux se servir de la spec OpenAPI comme d'une spec, c'est-à-dire quelque chose qu'on suit quand on fait l'implémentation, donc que l'implémentation doit se conformer à la spécification

Quel est ton avis de grand Manitou ?

Paul: Je ne suis pas un grand Manitou, [00:22:00] au contraire. C'est une très bonne question, et je pense que la réponse de juriste, ça dépend. J'aurais tendance à te dire que tout dépend de comment tu as conçu ton API dans l'état actuel des choses En fait ça dépend de si tu me parles de gérer un problème de rigueur dans la définition d'une spec open API déjà existante Ou si tu me parles de la création d'un nouveau projet J'aurais tendance à dire que sur un nouveau projet, je n'ai jamais vraiment bossé à 100% dans une équipe BAC sur la création d'une nouvelle API C'est toujours des trucs côté BFF en général Mais à savoir que lorsqu'on réfléchit à ce genre de problématique, on se demandait exactement quelle allait être la gueule de ce qu'on allait exposer.

Et ce truc-là, littéralement, peut être transcrit dans une spec OpenAVI. C'est-à-dire que j'aurais plutôt tendance à dire que tes équipes métiers, tes PO, tes managers, etc. devraient arriver vers toi avec un besoin fonctionnel, mais aussi Peu importe qui transpile ce besoin fonctionnel mais avec une spec OpenAPI [00:23:00] qui décrit les attentes et qui permet de se mettre en lien avec malgré tout le métier qui va consommer cette spec là Même si ils n'ont pas forcément de connaissances techniques mais tu sais malgré tout que tu as besoin d'un endpoint pour créer une entité, tu as besoin d'un endpoint pour enlever une etc, il y aura des mutations etc En principe, j'aurais même tendance à te dire, est-ce qu'il n'est pas possible d'automatiser dans une CI-CD le fait que pour une API donnée, elle relate d'une autre spec OpenAPI donnée

Pour vérifier que tu es forcément synchronisé entre ta spec OpenAPI source et l'état actuel de ton serveur. Je ne sais pas. Enfin, j'imagine que c'est... Je ne sais pas trop comment ça pourrait se transpirer techniquement dans une CI-CD, est-ce que tu autogénères des tests end-to-end qui permettraient de vérifier ça, je ne sais pas.

En tout cas je pense que dans une

Baptiste: ça veut dire que tu voudrais un outil qui permette de vérifier que l'implémentation est conforme à une spec open API c'est ça ou j'ai pas du tout compris si vraiment

Paul: on mettait dans le workflow de livraison en prod ou peu [00:24:00] importe dans le workflow de fonctionnement d'une équipe en interne qu'elle soit API front ou quoi On mettait sur un piédestal l'aspect OpenAPI comme faisant foi de l'état de notre application, c'est-à-dire qu'avant même qu'on ait à réfléchir de ce qu'on veut faire, on sait que notre application doit être comme ça à la fin d'un sprint ou à la fin d'une tâche, etc.

Bah ouais, je pense que c'est quelque chose de faisable. Après, je dois me fourvoyer, j'en sais rien, c'est une idée qui me traverse l'esprit, je n'y avais jamais pensé avant d'en discuter avec toi dans les médias. Mais ce que je veux dire, c'est que... C'est censé donner l'idée de l'aspect OpenAPI. En règle générale, tu peux l'importer dans n'importe quel outil de DevOps, dans du cloud, par exemple de l'API Management, de la PIM sur Azure, quand tu dois exposer des endpoints sur une fonde d'or ou peu importe.

Si t'aspect OpenAPI ne relate pas de la réalité, t'auras un problème en prod en fait Parce que c'est à dire que soit t'exploses un endpoint qui ne devrait pas, soit t'exploses un endpoint qui n'existe pas et vice versa Donc malgré tout j'aurais tendance à dire que oui

Baptiste: [00:25:00] Et donc tu partirais plus du fait qu'il faut que l'OpenAPI soit une spécification que le code doit respecter.

Et ça me fait penser à quelque chose que j'avais vu dans AdonisJS, ils ont un test runner qui s'appelle Jappa. Et je crois que Jappa a un module qu'on peut installer qui permet de vérifier que quand on fait une requête, Et bien elle suit bien une open API. J'avais vu ça, je ne m'en suis pas servi, mais j'avais vu ça, c'était assez impressionnant.

Paul: Alors,

Baptiste: je pourrais peut-être le retrouver, mais en gros... Je

Paul: n'ai pas API Client. C'est-à-dire que quand tu dis je suis la spec, même le modèle de données en entrée, c'est-à-dire qu'il y a une validation en runtime ?

Baptiste: Je pense que c'était plutôt le retour, à moins que je dise des bêtises Mais c'était pour vérifier que le retour d'une requête qu'on faisait était bien conforme à ce que l'aspect OpenAPI définissait

Paul: Ok, c'est vachement intéressant OpenAPI testing en effet [00:26:00] Configure plugin blablabla, schéma blablabla, blablabla, blablabla, isValidResponse Ah, d'accord Donc en effet, apparemment, du snippet de code que je vois, il fait vraiment une requête supertest et ensuite il utilise de la certe contextuelle à ton test, qui à mon avis doit prendre en compte le root qui a été tapé par supertest et qui doit se synchroniser.

À Poole c'est carrément mieux. Parce que si ça existe dans Java, ça existe très probablement dans d'autres écosystèmes. Et c'est... je sais pas si on peut parler de pattern matching. On mettra le

Baptiste: lien dans la description de l'épisode,

Paul: c'est pas mal. C'est sûr que là, c'est un peu dur à décrire, mais ouais, carrément, carrément, mais en tout cas voilà, c'est un peu la hype que j'ai actuellement sur ces sujets là, savoir aussi que l'open API permettrait d'auto-générer des serveurs de mocks, d'auto-générer des serveurs, ça permet aussi d'auto-générer des serveurs de mocks, en tout cas d'accélérer leur mise en place, [00:27:00] pour pouvoir par exemple avoir des default handler sur l'ensemble de tes serveurs.

De tes routes, ce qui te permet de commencer à écrire des tests end-to-end ou d'intégration sans trop te soucier de certaines features dont tu n'as pas connaissance qui sont nécessaires au bootstrapping de ton application mais dont tu ne veux pas, dont ce n'est pas l'objectif de tester ce besoin métier-là.

Sur des applis déjà existantes, c'est très intéressant d'arriver à cette stabilité-là parce que sinon c'est un temps fou de… Imaginons que ton appli prend 50 endpoints pour se bootstrapper, ce que je ne conseille à personne. Mais bref, ça te permet quand même d'accélérer les choses, de tester, de faire du POC aussi.

Bref, et ce truc-là s'appelle MSW Automock, c'est génial du javascript par contre. Enfin bref, je vous invite à regarder. Et donc c'était ma passion actuelle pour l'aspect OpenAPI, je reviendrai vers vous et vers toi mon Baptiste, mon cher Baptiste, à propos de tout ça parce que du coup c'est un sujet d'actu qui devrait pas tarder à vraiment rentrer dans mes prio, à savoir donc un refactor un peu de grande ampleur.

Avec pour objectif de [00:28:00] récupérer un peu de strictness sur un projet donc avec une forte legacy L'idée étant d'attaquer donc le contract API et le coverage global de mon appli Pour ensuite vraiment avoir confiance dans des refacteurs invasifs Et leur détection de régression au runtime Voilà voilà Rien que ça Non mais c'est beaucoup pour pas...

Voilà, ça sera d'autres sujets, et j'ai hâte de vous en parler, et hâte de t'avaler dessus aussi.

Baptiste: Bah écoute, merci à toi Paul pour tous tes conseils, ton avis aiguisé sur l'OpenAPI. Ce ne sont pas

Paul: des conseils, c'est vraiment juste des retours très basiques. En tout cas, je te remercie mon cher Baptiste, pour cette découverte aussi, déjà pas OpenAPI.

Eh oui,

Baptiste: merci à tous nos éditeurs, et à très bientôt. Allez, see you, ciao ciao.