Cas pratiques Quarkus

Contexte : L'API doit être consommée par un front-end hébergé sur un autre domaine. Le Problème : Les requêtes sont bloquées par le navigateur. Contraintes : Configurer CORS dans application.properties. Livrable attendu : Mettre en place une configuration CORS autorisant un domaine spécifique et tester son fonctionnement.

Contexte : Une route doit retourner un statut spécifique après création d'une ressource. Le Problème : L'endpoint retourne toujours un code 200 par défaut. Contraintes : Utiliser Response.status ou Response.created. Livrable attendu : Modifier l'endpoint POST pour retourner un code 201 Created avec entête Location approprié.

Contexte : L'application doit fonctionner en développement et en production avec des configurations différentes. Le Problème : Les paramètres sensibles sont codés en dur dans application.properties. Contraintes : Utiliser variables d'environnement et profils Quarkus. Livrable attendu : Configurer correctement la lecture des variables sensibles via environnement et profils dédiés.

Contexte : L'application doit persister des données dans une base relationnelle. Le Problème : Aucun modèle ni repository n'est configuré. Contraintes : Utiliser Hibernate ORM avec Panache. Livrable attendu : Créer une entité simple et implémenter des opérations basiques de persistance et récupération.

Contexte : Un endpoint Quarkus provoque une erreur lors de la sérialisation de la réponse. Le Problème : La méthode retourne un type non compatible avec la sérialisation JSON. Code actuel : @GET @Path("/test") public Object test() { return new Object(); } Contraintes : Retourner un objet sérialisable. Livrable attendu : Corriger la méthode pour retourner un objet DTO simple compatible JSON.

Contexte : Vous démarrez un microservice Quarkus dans le cadre d'une architecture cloud-native et devez vérifier rapidement qu'il répond correctement. Le Problème : Aucun endpoint personnalisé n'est encore exposé pour valider le bon fonctionnement de l'application. Contraintes : Utiliser JAX-RS natif avec annotations Quarkus. Ne pas ajouter de dépendances externes inutiles. Livrable attendu : Implémenter un endpoint GET /health retournant un JSON { "status": "ok" } avec code HTTP 200 et vérifier son accessibilité via curl ou navigateur.

Contexte : Une route doit récupérer une ressource via son identifiant unique. Le Problème : Le paramètre d'URL n'est pas correctement exploité dans la méthode. Contraintes : Utiliser @PathParam avec typage explicite. Livrable attendu : Implémenter une route GET /items/{id} retournant l'identifiant reçu dans une réponse JSON structurée.

Contexte : Une ressource demandée peut ne pas exister. Le Problème : L'application ne retourne pas d'erreur claire en cas d'absence de donnée. Contraintes : Utiliser ExceptionMapper. Livrable attendu : Implémenter un gestionnaire d'exception retournant un code 404 avec message JSON explicite.

Contexte : Une API Quarkus doit recevoir des données JSON structurées pour créer une ressource. Le Problème : Les données envoyées ne sont pas validées automatiquement. Contraintes : Utiliser Jakarta Bean Validation avec annotations comme @NotBlank et @Valid. Livrable attendu : Créer un endpoint POST acceptant un objet validé et retourner une erreur 400 si les contraintes ne sont pas respectées.

Contexte : La logique métier est placée directement dans la classe resource. Le Problème : Le code manque de séparation des responsabilités. Contraintes : Utiliser CDI avec @ApplicationScoped ou @Singleton. Livrable attendu : Extraire la logique métier dans un service injectable et l'injecter dans la resource via @Inject.

Contexte : L'application doit être déployée en production dans un environnement containerisé. Le Problème : Certaines configurations sensibles sont exposées ou mal paramétrées. Contraintes : Utiliser profils Quarkus et variables d'environnement sécurisées. Livrable attendu : Adapter la configuration pour un environnement production sécurisé et optimisé.

Contexte : Les erreurs API sont retournées avec des formats incohérents. Le Problème : Aucun gestionnaire global d'erreurs JSON n'est configuré. Contraintes : Implémenter un ExceptionMapper personnalisé. Livrable attendu : Mettre en place une gestion centralisée garantissant un format JSON uniforme pour toutes les exceptions applicatives.

Contexte : Certaines actions métier doivent déclencher des traitements secondaires. Le Problème : La logique est dupliquée dans plusieurs resources. Contraintes : Utiliser CDI events ou Reactive Messaging. Livrable attendu : Mettre en place un système d'événements internes permettant de découpler les traitements métier et améliorer la maintenabilité.

Contexte : Une application multi-utilisateurs doit restreindre l'accès selon le rôle. Le Problème : Les contrôles d'accès sont gérés manuellement dans les méthodes. Contraintes : Utiliser annotations @RolesAllowed et configuration sécurité. Livrable attendu : Mettre en place un système d'autorisation basé sur rôles permettant de sécuriser dynamiquement les endpoints sensibles.

Contexte : Les utilisateurs doivent pouvoir téléverser des fichiers. Le Problème : Aucun contrôle strict n'est appliqué sur le type ou la taille des fichiers. Contraintes : Valider type MIME, taille maximale et sécuriser le stockage. Livrable attendu : Mettre en place un endpoint d'upload sécurisé avec validation complète et gestion d'erreurs adaptée.

Contexte : Une API doit protéger certains endpoints accessibles uniquement aux utilisateurs authentifiés. Le Problème : Aucun mécanisme d'authentification par token n'est configuré. Contraintes : Utiliser SmallRye JWT avec configuration appropriée dans application.properties. Livrable attendu : Mettre en place une authentification JWT complète incluant validation du token et protection des endpoints via @RolesAllowed.

Contexte : Une API retourne de grandes listes d'entités. Le Problème : Toutes les données sont envoyées en une seule réponse. Contraintes : Utiliser PanacheQuery avec pagination. Livrable attendu : Mettre en place une pagination efficace limitant le nombre d'éléments retournés et améliorant la performance globale.

Contexte : Certains endpoints exécutent des traitements coûteux répétés. Le Problème : Les temps de réponse augmentent sous charge. Contraintes : Utiliser l'extension Quarkus Cache avec backend Caffeine ou Infinispan. Livrable attendu : Implémenter un mécanisme de cache avec gestion de TTL permettant d'améliorer les performances.

Contexte : Une API retourne des entités avec relations associées. Le Problème : Les performances sont dégradées à cause de requêtes répétées générées par lazy loading. Contraintes : Utiliser fetch joins ou projections optimisées avec Panache. Livrable attendu : Refactoriser les requêtes afin de réduire le nombre de requêtes SQL et améliorer les performances globales.

Contexte : Votre application Quarkus a été développée rapidement et la logique métier est actuellement placée directement dans les classes Resource. Le Problème : Le code devient difficile à maintenir et à tester à mesure que le projet évolue. Contraintes : Mettre en place une séparation claire entre couche REST (Resource), services métier (@ApplicationScoped) et accès base via Panache ou repository dédié. Livrable attendu : Refactoriser l'application afin d'isoler la logique métier dans un service injectable et centraliser l'accès aux données dans une couche repository propre.

Contexte : Une application monolithique doit évoluer vers une architecture distribuée avec des microservices indépendants. Le Problème : Les services sont fortement couplés et déployés ensemble. Contraintes : Utiliser un message broker comme Kafka ou RabbitMQ pour la communication asynchrone. Livrable attendu : Concevoir une architecture microservices permettant une communication événementielle fiable, avec découplage des services et gestion des événements.

Contexte : Votre application Quarkus a évolué rapidement et mélange contrôleurs, logique métier et accès aux données dans les mêmes packages. Le Problème : Le couplage fort rend difficile la testabilité et l’évolutivité de l’application. Contraintes : Mettre en place une Clean Architecture en séparant clairement le domaine métier, les cas d’utilisation, les interfaces de repository et les adaptateurs d’infrastructure. Livrable attendu : Proposer une structure complète incluant les entités métier, les services applicatifs, les interfaces et les implémentations concrètes pour garantir la testabilité et l’évolutivité.

Contexte : Une plateforme SaaS doit gérer des rôles hiérarchiques et des permissions dynamiques. Le Problème : Les règles d'autorisation actuelles sont statiques et ne sont pas adaptées à des contextes d’utilisation complexes. Contraintes : Implémenter un moteur RBAC (Role-Based Access Control) ou ABAC (Attribute-Based Access Control) pour gérer les permissions dynamiques. Livrable attendu : Concevoir un système d’autorisation flexible capable de gérer des rôles et des permissions dynamiques basées sur le contexte utilisateur, avec Quarkus Security.

Contexte : Plusieurs services doivent effectuer des opérations coordonnés sur différentes bases de données. Le Problème : Les transactions globales ne sont pas cohérentes en cas d'échec partiel. Contraintes : Implémenter un pattern Saga avec orchestration ou choreography et gestion des compensations en cas d’échec. Livrable attendu : Concevoir un système garantissant la cohérence des données entre les microservices en utilisant le pattern Saga, avec gestion des compensations si nécessaire.

Contexte : Une API doit gérer des sessions longue durée de manière sécurisée. Le Problème : Les tokens actuels ne permettent pas de rotation sécurisée ou d’invalidation fine. Contraintes : Mettre en place un système d'authentification avec access token court et refresh token stocké en base, incluant rotation automatique et invalidation des tokens compromis. Livrable attendu : Concevoir un système complet avec génération, stockage, rotation et révocation des tokens tout en garantissant la sécurité de l’application.

Contexte : L’application est déployée sur plusieurs instances dans un environnement cloud. Le Problème : Le suivi des erreurs et des performances entre services est difficile. Contraintes : Intégrer OpenTelemetry pour assurer le tracing distribué, les logs et les métriques dans les microservices Quarkus. Livrable attendu : Mettre en place une solution complète de monitoring et de tracing permettant d’analyser les performances et d’assurer une visibilité sur l’application distribuée.

Contexte : Une plateforme SaaS doit gérer plusieurs organisations avec une séparation stricte des données. Le Problème : Les données des tenants sont stockées dans les mêmes tables sans mécanisme d’isolation systématique. Contraintes : Implémenter un système multi-tenant avec un champ tenantId ou une base de données dédiée, et gérer dynamiquement l’identification du tenant. Livrable attendu : Concevoir une architecture garantissant l’isolation complète des données entre tenants et empêchant tout accès croisé non autorisé.

Contexte : L’application doit être déployée sur Kubernetes dans un environnement cloud. Le Problème : L’architecture actuelle dépend d'états locaux et n’est pas optimisée pour la scalabilité. Contraintes : Rendre l’application stateless, externaliser sessions, cache et données. Livrable attendu : Proposer une architecture cloud-native complète pour Kubernetes, permettant de garantir la scalabilité horizontale et haute disponibilité.

Contexte : Certains endpoints critiques subissent une forte charge. Le Problème : Les requêtes base de données deviennent un goulot d’étranglement. Contraintes : Utiliser Redis ou Infinispan comme backend de cache distribué avec stratégie d’invalidation fine et gestion de TTL. Livrable attendu : Mettre en place un cache distribué performant garantissant la cohérence des données et réduisant la latence des requêtes.

Contexte : L'API est exposée publiquement et doit répondre à des exigences élevées de sécurité. Le Problème : Certaines protections contre injection SQL, XSS, ou autres attaques ne sont pas suffisantes. Contraintes : Mettre en place des mécanismes avancés de sécurité (rate limiting, validation stricte des entrées, protection des headers). Livrable attendu : Concevoir une stratégie complète de sécurisation de l’API, alignée avec les meilleures pratiques de sécurité (OWASP) et intégrée dans Quarkus.