Aller au contenu
API — Back — Tools — REST — OSS

Use Bruno 🐶

Plongez dans l'univers de Bruno : le client d'API open source qui transforme l'art de gérer les API, promettant liberté, efficacité, et surtout une indépendances vis-à-vis du cloud, plus en phase avec la manière dont les développeurs interagissent avec leurs outils.

Photo de Pavan Trikutam sur Unsplash

Face aux récentes mises à jour, aux limitations ajoutées et aux évolutions du modèle économique du client d’API Postman, de nombreuses entreprises et développeurs reconsidèrent leur utilisation de cet outil, en quête d'alternatives.

Dans ces alternatives, un candidat semble tirer son épingle du jeu : Bruno.

Histoire

Bruno est un client d’API open source sous licence MIT, en d’autres termes, une application qui vous permettra de faire des appels REST ou GraphQL à vos API et d’en automatiser le test, entre autres.

Il a été créé par Anoop comme une alternative open source par rapport à d’autres produits du marché, en s’appuyant sur un certain nombre de principes qu’il a synthétisé dans un manifeste disponible sur le site de l’outil.

Pourquoi il est intéressant

Plusieurs critères font que Bruno est différent des autres produits.

Tout d’abord, on ne le dira jamais assez, il est open source, ce qui implique que tout le monde peut y contribuer pour l’enrichir et utiliser cet outil de manière gratuite.

Bruno proposera à l’avenir une autre version payante et s’est engagé à ce que tout contributeur bénéficie d’une licence payante gratuitement.

Les principaux atouts de Bruno sont énoncés dans son manifeste que vous pouvez retrouver sur le site de l’outil Manifesto.

Les points importants de ce manifeste sont les suivants : 

  • Aucun outil propriétaire ne doit être imposé pour tester et utiliser ses API de manière décentralisée et offline (pas besoin de cloud, du local uniquement).
  • Les collections de manipulation d’API doivent être colocalisées avec leur code et permettre de mieux manipuler les API. Les collections sont “first class citizen” avec le code qui leur est associé.
  • Un format de collection simple et modulaire qui facilite les revues de code et l’intégration proche du code source des projets : Bru Markup Language (.bru)
  • Un outil simple, efficace et libre.

L’auteur s’est aussi exprimé via une issue du repository de son projet sur les orientations qu’il souhaite donner à son produit : 

  • Son projet a démarré en 2021 et n’a pas suscité un grand intérêt pour les communautés de développeurs avant 2023 et les évolutions Postman.
  • Il souhaite poursuivre dans la voie de l’open source mais aimerait aussi pouvoir vivre de son projet et réfléchit à un modèle économique sans : 
    • créer d’entreprise et sans fond d’investissement
    • avoir à vendre son projet
    • devoir ajouter une infrastructure cloud à son produit
    • vendre d’abonnement
  • La pistes à suivre pour le développement de son produit : 
    • du sponsoring via Github ou des entreprises utilisatrices
    • être rémunéré pour du support ou du consulting
    • créer une édition payante avec des features entreprises sans dénaturer le produit de base.

Installation 

Il n’y a pas de prérequis particulier pour utiliser Bruno. Il s’installe par téléchargement mais arrive aussi packagé pour les principales distributions du marché (Mac/Linux/Windows) :

  • Linux : snap, apt,
  • MacOS : homebrew,
  • Windows : chocolatey ou encore scoop.

 

Page d'installation pour MacOS

Prise en main

Si vous êtes habitués à un client d’API, pas de grand changement dans l’utilisation de ce type d’outil. On construit ses API et vient alors le temps de les tester et de les partager avec l’équipe. C’est là que Bruno entre en jeu.

En se laissant guider par Bruno et en lisant la documentation, voici un exemple rapide de mise en place à partir d’une API existante :

  1. Création d’un répertoire contenant la collection avec le code source du projet
Création d'une nouvelle collection locale
  1. Import possible d’une collection existante (Bruno, OpenAPI ou d’autres outils)
Import de collection existante
  1. Création d’une première requête, HTTP, GraphQL ou à partir d'une commande cURL existante. On a également le choix du body, des en-têtes, etc.
Nouvelle requête
Configuration du body de la requête
  1. Exécution d’une requête.
Exemple d'exécution d'une requête
  1. Exécution de toute une collection : les runners sont intégrés et permettent de lancer toutes les requêtes depuis l’application.
Lancement d'un runner complet sur une collection
  1. On peut définir différents environnements pour y gérer des configurations spécifiques telles que les URL des services ou les mots de passe. Cela permet de différencier le développement de la production par exemple. On accède ensuite à ces variables avec une notation en “moustaches” {{var}}. Un sélecteur permet ensuite de changer d’environnement au besoin.
Définition des variables pour un environnement
Utilisation des variables dans vos requêtes
  1. Bruno dispose également d’une fonctionnalité de gestion des secrets.
Définition de secret à partir d'un .env
Utilisation des secrets

Bruno permet en effet de gérer ses secrets de 2 manières : 

  • à partir de fichiers .env (KEY=value), qu’on évitera de commiter avec le bon .gitignore dans son projet
  • ou grâce à l'attribut “secret” de l’interface qui conservera le mot de passe dans Bruno lui-même.

Quitte à faire du  “As Code” je vous recommande d’opter pour la première solution afin de pouvoir manipuler ses mots de passe dans un fichier également.

Voici à quoi peut ressembler les fichiers de Bruno dans votre projet après cette première prise en main. Il ne restera plus qu’à sauver ces fichiers avec votre code et à vos collègues d’importer cette nouvelle collection afin de prendre en main cette API que vous venez de développer.

Layout des fichiers de Bruno

Pour terminer, Bruno dispose également d’un CLI qui vous permettra d'exécuter vos collections en ligne de commande pour du test par exemple, à l’instar de newman.

Lancement de la collection via la CLI

Vous pouvez récupérer les résultats d'exécution sous forme de fichier JSON pour automatiser vos rapports de test par exemple.

Résultat de test JSON

Conclusion

Vous l’aurez compris, Bruno en est à ses débuts, beaucoup de grandes entreprises sont actuellement en pleine réflexion sur l’utilisation d’une solution commerciale ou de l’adoption et du support d’une solution open source. De mon point de vue, les fonctionnalités attendues d’un client d’API sont bien présentes : 

  • Création de collection, migration possible d’outils existants
  • Création de nouvelles requêtes facilitées
  • Gestion de la persistance “As Code”
  • Ecriture de tests avec du Javascript et des lib complémentaires
  • Exécution en CLI pour une intégration dans une usine de développement
  • Utilisation offline by design.

Je vous laisse l’essayer et probablement l’adopter à votre tour. Et pour ceux qui se demandent depuis le début de l’article d’où vient ce nom et ce qu’il signifie, c’est simple la réponse avec cette photo du chien du créateur de l’outil !

Bruno, le chien d'Anoop

Références et alternatives : 

Alternatives client API

Dernier