Monaco 2026 🏁🏎️ #F1 #MonacoGP

Injecter des variables d'environnement dans application.yml avec #SpringBoot. Plutôt que de coder en dur les valeurs sensibles ou spécifiques à l'environnement, Spring permet de les injecter au démarrage via la syntaxe ${VARIABLE}. Deux comportements selon le besoin : → ${VAR} : variable obligatoire. L'application échoue au démarrage si elle n'est pas définie. → ${VAR:defaut} : variable optionnelle avec valeur de repli. Règle simple : → Secrets et valeurs critiques : sans valeur par défaut, échec immédiat si manquante → Valeurs techniques avec un fallback raisonnable : avec valeur par défaut Bonne pratique : Le fichier application.yml versionné décrit la structure. Les valeurs sensibles viennent de l'environnement, jamais du code. #Java #Configuration

De la France à l'Egypte : hommage à l'écrivain Taha Hussein radiofrance.fr/franceculture… via @franceculture

Les profils #Spring permettent d'adapter la configuration selon l'environnement, sans changer le code. Spring sélectionne automatiquement le fichier de configuration en fonction du profil actif. Structure recommandée : → application.yml : configuration commune à tous les environnements → application-dev.yml : surcharges pour le développement local → application-staging.yml : surcharges pour la pré-production → application-prod.yml : surcharges pour la production #Spring fusionne automatiquement le fichier commun avec celui du profil actif. Les valeurs du profil actif écrasent celles de la configuration commune. Pour activer un profil : utilisez la variable d'environnement : SPRING_PROFILES_ACTIVE=prod @Profile permet de charger un bean uniquement pour un profil :

#MySQL vs #MariaDB

En JPA, TOUTES les relations doivent être LAZY. ​Rappel des valeurs par défaut : ✅ @OneToMany / @ManyToMany : Lazy (bon comportement) ❌ @ManyToOne / @OneToOne : Eager (le piège classique) ​Pourquoi forcer le LAZY partout ? Une relation EAGER est chargée à chaque requête, même lorsque vous n'en avez pas besoin. Résultat : requêtes SQL superflues, surconsommation de mémoire et apparition du fameux problème N 1. La règle : @ManyToOne(fetch = FetchType.LAZY) @OneToOne(fetch = FetchType.LAZY) Chargez ensuite explicitement les données nécessaires via @EntityGraph ou JOIN FETCH. ​Principe d'architecture à retenir : Le chargement d'une relation doit être une décision explicite du code appelant, et non un comportement caché ou subi depuis l'entité.

Le problème N 1 en JPA/Hibernate : Vous chargez N entités, puis vous accédez à une relation lazy (@OneToMany, @ManyToOne). Hibernate déclenche 1 requête pour la liste, puis 1 requête par entité pour charger la relation. 100 commandes avec leurs lignes → 101 requêtes SQL au lieu d'1 seule. 3 façons de l'éviter, de la plus utilisée à la moins utilisée : → @EntityGraph sur la méthode du repository : Déclaratif, lisible, directement sur le Spring Data Repository. Solution par défaut aujourd'hui. @EntityGraph(attributePaths = "items") → JOIN FETCH en JPQL : Requête explicite qui charge la relation en un seul SELECT avec JOIN. Utile dans les requêtes custom. SELECT o FROM Order o JOIN FETCH o.items → Projection JPA : Si vous n'avez pas besoin des entités complètes, sélectionnez directement les champs utiles via un DTO ou une interface de projection. Plus performant, moins de mémoire, mais demande plus de code. Comment le détecter : → spring.jpa.show-sql=true en développement pour voir les requêtes générées → Hibernate Statistics pour compter les requêtes par transaction Règle simple : Si le nombre de requêtes dépend de la taille du résultat, c'est un problème N 1. #Java #SpringBoot #Hibernate #Performance

En #Spring, préférez l'injection par constructeur à @​Autowired sur champ. ​@​Autowired sur champ → pratique mais problématique : pas de final, dépendances cachées (surtout au code appelant), classes difficiles à tester sans Spring. La solution : injection par constructeur. → Dépendances explicites et contractuelles → Champs immuables (final) → Testable sans démarrer Spring Recommandée officiellement par l'équipe #Spring depuis longtemps.

Hâte de voir ce que Opus 4.7 apporte côté raisonnement et contexte. 🤖

Piège courant avec @Transactional : Vous mettez l’annotation sur une méthode private → aucune erreur, aucun warning. Le code compile et s’exécute normalement. Pourtant, aucune transaction n’est créée. Spring utilise un proxy AOP pour gérer les transactions. Ce proxy ne peut pas accéder aux méthodes private → l'annotation est simplement ignorée. À retenir : @Transactional ne fonctionne que sur les méthodes public. #SpringBoot #Java #Transactional

#softwarearchitecture #microservices #backend

@​Transactional par défaut, ce n'est pas toujours suffisant. readOnly = true Indique à Hibernate qu'aucune modification n'est attendue → pas de dirty checking inutile → optimise les requêtes SELECT. rollbackFor = Exception.class Permet le rollback aussi sur les checked exceptions. Par défaut, Spring ne rollback que sur les RuntimeException. Deux attributs simples pour plus de fiabilité et de performance. #SpringBoot #Java #Transactional

Pour une entité #JPA, évitez @​Data de Lombok ! @​Data génère equals(), hashCode() et toString() sur tous les champs → risques de bugs avec les proxys Hibernate, relations lazy et collections. Utilisez plutôt : @​Getter @​Setter (si nécessaire) @​NoArgsConstructor Et si besoin (entités détachées, Sets, Maps…), implémentez equals()/hashCode() manuellement sur l’ID métier. Pour un modèle de persistance stable et maîtrisé. #Java #SpringBoot #Hibernate #Lombok

Développeur Full Stack Senior Java & Angular. Sujets principaux : architecture microservices, performances et Clean Code. Je partage ici mes retours d'expérience techniques. #Java #Angular #Microservices #CleanCode