Lorsque l’on développe des tests API, il arrive fréquemment de devoir s’authentifier pour effectuer l’appel. Réécrire le code permettant de récupérer un token valide est non seulement fastidieux, source d’erreur, mais également une mauvaise pratique en termes de maintenabilité. Nous allons voir comment injecter un token valide directement en paramètre de test JUnit de manière à pouvoir l’utiliser simplement là où cela est nécessaire.
Dans le précédent article, nous avons vu comment lancer automatiquement un conteneur exposant une API et relié à sa propre base de données grâce à une extension Quarkus. Nous allons maintenant voir comment communiquer avec cette api depuis notre application principale.
Dans le précédent article, nous avons vu comment lancer une base de données automatiquement grâce à une extension Quarkus. Nous allons maintenant voir comment démarrer notre service de la même manière et lui faire utiliser la base de données que nous venons de déployer. Je ne reviendrai pas sur les points abordés dans le précédent article. Je vous invite donc à le lire avant de continuer.
Aujourd’hui, on s’attaque à un gros morceau avec un cas d’usage non documenté par Quarkus, mais qui est vraiment très pratique. Quarkus propose des extensions avec des “dev services”. Ces extensions, une fois incluses dans votre projet, lancent des services automatiquement au démarrage du projet en mode dev. Nous allons voir comment créer notre propre “dev service” pour nos applications Quarkus. L’idée est de fournir une extension pour chacun de nos services afin de les rendre utilisables facilement par des tiers.
Backstage est un formidable outil de tableau de bord pour les développeurs. Son système de plugin le rends particulièrement flexible. Cependant la configuration de ces plugins peut s’avérer fastidueuse.
Backstage est en constante évolution, ce qui fait que la documentation à parfois du mal à suivre. C’est le cas depuis la migration vers le nouveau Backend system. Backstage dispose de plusieurs plugin permettant de
se connecter à la majorité des providers d’identité via OIDC. Toutefois, si vous souhaitez connecter backstage à un provider personnalisé comme un Keycloak d’entreprise la documentation n’est pas vraiment clair. C’est ce que nous allons voir dans ce post.
Dans le précédent post sur le buildItem AdditionalBeanBuildItem, nous avons vu comment référencer un bean au gestionnaire de dépendance ARC.
Cela est très pratique, mais dans certains cas, nous voulons pouvoir que le gestionnaire injecte une instance spécifique d’un bean déjà configuré. L’AdditionalBeanBuildItem ne prenant qu’une classe de bean
en paramètre, il ne peut pas être utilisé pour cela. C’est ici qu’intervient le SyntheticBeanBuildItem
LE BARO Romain