DEV Community: TechniveK

Le cache dans les applications web : le secret des performances

TechniveK — Tue, 24 Sep 2024 20:25:12 +0000

Aujourd’hui, les utilisateurs n’ont pas de temps à perdre. Ils veulent des pages qui se chargent en un clin d'œil, une navigation rapide, et des performances de haut vol. Pour arriver à ce niveau de fluidité, les développeurs disposent d’une arme puissante : le cache.

Le terme "cache" est omniprésent dans les discussions sur la performance web. Le but, bien sûr, n'est pas d'appliquer du cache partout comme un sauvage ! Non, il faut comprendre quand, pourquoi et surtout comment implémenter le bon cache au bon endroit. Il en existe plein de types différents : cache navigateur, cache serveur, cache d’API et même cache en base de données, chacun jouant un rôle particulier.
Dans cet article, je te propose de passer en revue tout ça, pour que tu puisses faire de ton application un petit bolide ! 🚨 🚘

Le cache : essentiel pour plusieurs raisons

Amélioration des performances : en stockant des résultats souvent demandés, le cache permet d'éviter de répéter des calculs coûteux ou de recharger des données à chaque requête.
Réduction de la charge du serveur : en limitant les appels à la base de données ou aux services tiers, tu réduis la charge globale du serveur.
Meilleure expérience utilisateur : un site rapide améliore l’expérience des utilisateurs et les encourage à rester plus longtemps.

1. Le cache navigateur : garder les ressources localement

Commençons par le plus familier : le cache navigateur. Comme son nom l’indique, c’est le navigateur de l’utilisateur qui gère ce type de cache. C’est un mécanisme côté client qui stocke les ressources localement sur l'appareil de l'utilisateur. Lorsque quelqu'un visite ton site, son navigateur télécharge les ressources nécessaires (HTML, CSS, JavaScript, images, polices de caractères, etc.) et les garde en cache pour une durée déterminée. Si l'utilisateur revient plus tard sur cette page, le navigateur ne redemande pas ces fichiers au serveur : il les charge directement depuis le cache local.

Comment ça fonctionne ?

Lorsque tu fais une requête HTTP, le serveur peut ajouter des en-têtes HTTP (headers) qui indiquent au navigateur comment et combien de temps il doit conserver les ressources en cache.

Les headers principaux sont :

Cache-Control : il indique au navigateur pendant combien de temps conserver un fichier (ex. Cache-Control: max-age=86400 pour 24h).
ETag : une sorte d'empreinte numérique (hash) du contenu. Si le contenu ne change pas, l'ETag reste le même et le navigateur sait qu’il peut réutiliser la ressource.
Last-Modified : le navigateur compare la date de la dernière modification pour savoir s'il doit recharger une ressource.

Exemple avec Symfony : configuration des en-têtes de cache

Dans Symfony, tu peux facilement contrôler le cache navigateur au niveau des réponses HTTP. Voici comment ajouter des directives de cache dans un contrôleur :

Le navigateur se fie aux en-têtes HTTP envoyés par ton serveur pour savoir combien de temps il peut garder une ressource en cache avant de la retélécharger. En gros, ces en-têtes disent au navigateur : "Tu peux conserver ces fichiers pendant X temps", ou bien "Vérifie auprès du serveur si ce fichier a changé avant de l'utiliser".

Exemple concret : une page de FAQ statique

Imagine que tu gères une page de FAQ qui ne change pas souvent. Avec un cache navigateur, tu peux demander au navigateur de garder la page en mémoire pendant une journée, sans jamais revenir vers le serveur.

En ajustant les directives max-age et immutable, tu peux t’assurer que cette page ne sera téléchargée qu’une seule fois par jour.

Les avantages :

Rapidité pour l’utilisateur : il ne télécharge pas les fichiers à chaque visite.
Réduction des coûts serveurs : moins de requêtes signifie moins de charge.

Les limites :

Ça reste côté client : ce type de cache n'est accessible qu'à partir de l’appareil de l’utilisateur. Ce qui signifie que chaque nouvel utilisateur, ou chaque nouveau navigateur, doit d'abord télécharger les ressources avant que le cache ne soit utilisé.
Le cache navigateur ne peut rien faire pour accélérer la toute première visite d’un utilisateur.
Tu dois bien gérer les versions des fichiers pour ne pas que le cache garde des ressources obsolètes.

2. Le cache HTTP : l’optimisation côté serveur

Passons maintenant au cache HTTP. Là où le cache navigateur est une optimisation côté client, le cache HTTP se situe côté serveur.
Il est géré par des outils comme Varnish et il fonctionne comme un proxy qui s’interpose entre ton application web et l’utilisateur. Il peut servir des milliers de requêtes par seconde sans avoir à interroger PHP ou la base de données.

Comment ça marche ?

Varnish intercepte toutes les requêtes HTTP qui arrivent sur ton serveur et vérifie si une version de la page demandée est déjà disponible en cache. Si c'est le cas, il répond directement avec la page mise en cache, sans avoir à solliciter le serveur web ou la base de données. L’idée, c’est de stocker les réponses les plus fréquemment demandées pour éviter que ton application ne doive les générer à chaque fois. Résultat : des réponses ultra-rapides et un soulagement pour ton serveur.

Exemple de configuration Symfony pour Varnish :

Symfony te permet de contrôler facilement quels éléments doivent être mis en cache par Varnish grâce aux mêmes en-têtes HTTP que pour le cache navigateur.

Exemple concret : une liste d'articles de blog

Les articles de blog changent rarement une fois publiés. Tu peux donc utiliser un ETag pour permettre au cache HTTP de vérifier si le contenu a changé, sans que le navigateur ait besoin de télécharger à nouveau toute la page.

Lorsque l’utilisateur consulte la page, l’ETag généré à partir du contenu est comparé à celui que le cache a déjà stocké. Si rien n’a changé, la réponse 304 Not Modified est renvoyée, sans transférer le contenu à nouveau.

Les avantages du cache Varnish :

Optimisation pour tous les utilisateurs : contrairement au cache navigateur, Varnish agit pour tous les utilisateurs, même ceux qui visitent ton site pour la première fois.
Soulage le serveur : en servant directement des réponses en cache, Varnish évite de solliciter ton application ou ta base de données, ce qui améliore considérablement les performances sous charge.

3. Le cache système : optimiser les données à long terme

Le cache système intervient au niveau serveur et permet de stocker les résultats des calculs complexes, des requêtes lourdes en base de données, ou des réponses provenant de services tiers (API).

Dans Symfony, la manière la plus courante d’utiliser ce cache, c’est via le composant Cache qui te donne accès à une abstraction de plusieurs systèmes de cache (comme Redis, Memcached ou le file system).

Symfony propose une interface simple et efficace avec la fonction get(). Cette méthode permet d’accéder au cache si la clé existe déjà, ou de la créer si elle n’existe pas encore, tout cela en une seule ligne de code.

Exemple avec le FilesystemAdapter (cache sur disque)

Le FilesystemAdapter est une implémentation qui stocke les données en cache directement sur le disque de ton serveur. C’est pratique quand tu veux démarrer rapidement sans avoir besoin d'une solution de cache externe comme Redis.

Symfony te permet de gérer plusieurs types de cache via différents adaptateurs. Tu n’es donc pas limité au filesystem. Si tu veux passer à un cache en mémoire ultra-rapide, tu peux utiliser des services comme Redis ou Memcached.

Exemple avec RedisAdapter (cache en mémoire)

Redis est un excellent choix pour les applications qui ont besoin d'un cache performant. Avec Redis, tu stockes les données directement en mémoire, ce qui est beaucoup plus rapide que le disque dur.

Avantages :

Moins de requêtes externes : tu diminues la charge sur les serveurs API.
Meilleures performances : tes utilisateurs reçoivent des réponses plus rapidement.

4. Le cache en base de données : optimiser les requêtes

On ne peut pas parler de cache sans mentionner le cache en base de données. Dans Symfony, tu peux éviter de refaire constamment les mêmes requêtes SQL coûteuses en utilisant des systèmes comme Doctrine Cache ou Redis.

Comment ça fonctionne ?

L’idée est de stocker les résultats de requêtes fréquemment demandées en mémoire. Quand la même requête est effectuée à nouveau, plutôt que de l’envoyer à la base de données, Symfony renvoie la réponse depuis le cache.

Exemple : Cache des produits les plus vendus

Imaginons que tu veuilles afficher la liste des produits les plus vendus dans une boutique e-commerce, une requête qui peut être lourde à exécuter.

Autre méthode : utilisation du cache intégré à Doctrine (Result Cache)

Doctrine offre aussi son propre système de cache des résultats des requêtes. C’est particulièrement pratique pour cacher directement au niveau de l'ORM, en rendant le processus de mise en cache encore plus transparent.

Pour activer le Result Cache dans Doctrine, tu dois d’abord configurer un adaptateur de cache (comme Redis ou le système de fichiers) dans ton fichier doctrine.yaml :

Ensuite, tu peux mettre en cache le résultat d’une requête directement dans ton repository.

Exemple : caching avec Doctrine Result Cache

useResultCache(true, 3600, 'top_selling_products') : On active le cache pour la requête avec une durée d’expiration d'une heure. La clé du cache est top_selling_products.
Cache Redis via Doctrine : Doctrine enverra les résultats dans Redis (ou tout autre cache configuré), ce qui évite d'exécuter la même requête SQL plusieurs fois durant la période de cache.

Avantages :

Réduction de la charge sur la base de données : En mettant en cache les résultats, tu réduis considérablement la charge sur la base de données, surtout pour les requêtes lourdes ou fréquentes.
Amélioration des temps de réponse : En servant des résultats directement depuis le cache (qui peut être en mémoire avec Redis), tu réduis les temps d'accès par rapport à des requêtes SQL régulières.
Simplicité d’utilisation : Avec Symfony et Doctrine, la gestion du cache est rendue très facile grâce à des méthodes comme get() du composant Cache ou le Result Cache intégré à Doctrine.

Maintenant que tu maîtrises chaque type de cache, la question qui brûle les lèvres : comment tout ça fonctionne ensemble ?

En fait, c'est la complémentarité des caches qui te permet d’avoir une application vraiment performante. Le cache navigateur accélère les visites répétées d'un utilisateur en stockant les ressources directement sur son appareil. Le cache HTTP (Varnish), lui, optimise la charge côté serveur en servant les pages générées directement depuis sa mémoire.

L’objectif ? Gagner sur tous les tableaux. Le navigateur fait en sorte que l'utilisateur ne retélécharge pas inutilement des fichiers. Varnish, de son côté, fait en sorte que ton serveur ne soit pas surchargé par des requêtes redondantes.

Conclusion

Que ce soit côté client ou côté serveur, tout est une question de bon équilibre. Chaque type de cache a ses avantages et ses inconvénients, mais en les combinant judicieusement, tu peux atteindre des performances spectaculaires.

Alors, prends le temps de bien configurer tes caches, car ils peuvent faire toute la différence entre une application lente et une application rapide comme l’éclair !

Maîtriser les principes SOLID : pour un code propre et performant

TechniveK — Sat, 14 Sep 2024 06:36:22 +0000

Dans le monde du développement, il y a un grand fossé entre écrire du code et écrire du bon code. Tu sais, ce code que tu peux modifier dans 6 mois sans avoir à tout réécrire, ce code qui ne t’oblige pas à passer des heures à le comprendre avant de le débugger.

Et si je te disais qu’il existe une méthode pour structurer ton code de manière à le rendre facilement maintenable, modulaire, et sans prise de tête ? Accueillons sans plus attendre les principes SOLID.

Ces cinq principes, introduits par l'incontournable Robert C. Martin, aka Uncle Bob, montrent comment organiser tes classes et tes méthodes pour qu’elles puissent évoluer sans s’effondrer.

Tu es prêt à devenir un développeur plus SOLID 💪 que jamais ? On y va. 🚀

1. Le * S * ➡️ Single Responsibility Principle

"Une classe ne doit avoir qu'une seule responsabilité."

L'idée est simple : chaque classe doit avoir une seule raison de changer. Cela signifie qu'une classe ne doit s'occuper que d'une seule tâche ou d'une seule fonctionnalité. Si tu mélanges plusieurs responsabilités dans une même classe, tu finiras par complexifier ton code et rendre les modifications plus risquées.

Exemple avec Symfony

Prenons l'exemple d'une classe qui gère à la fois la validation d'un formulaire d'utilisateur et l'envoi d'emails de confirmation. Voici un exemple de ce qu'il ne faut pas faire :

Ici, la classe UserService viole le principe de responsabilité unique. Elle gère à la fois la création de l'utilisateur, la validation des données, et l'envoi d'un email. Chaque fois que l'une de ces responsabilités évolue, la classe doit être modifiée.

Solution : On divise les responsabilités !

Maintenant, chaque classe a une responsabilité distincte : UserValidator pour la validation, EmailService pour l'envoi d'emails et UserService pour la logique de gestion des utilisateurs. Ton code devient beaucoup plus facile à maintenir !

2. Le * O * ➡️ Open/Closed Principle

"Les entités doivent être ouvertes à l'extension, mais fermées à la modification."

Cela signifie que tu dois pouvoir ajouter de nouvelles fonctionnalités à une classe sans avoir à modifier son code existant.
Pourquoi ? Parce que chaque fois que tu modifies du code existant, tu risques d'introduire des bugs. Mieux vaut ajouter des fonctionnalités que de retoucher le code déjà écrit et testé.

Exemple avec Symfony

Imaginons que tu développes un service de paiement dans une boutique Symfony. Ce service gère différentes méthodes de paiement : carte de crédit, PayPal, etc. Si tu veux ajouter un nouveau mode de paiement (Bitcoin, par exemple), le principe Open/Closed te dit qu'il ne faut pas toucher au code déjà existant pour éviter les régressions.

Voici une mauvaise approche, où l'ajout de nouvelles fonctionnalités nécessite des modifications dans le code existant :

Le problème ici, c'est qu'à chaque fois que tu veux ajouter un nouveau moyen de paiement, tu dois modifier la méthode processPayment, ce qui viole le principe Open/Closed.

Solution : Utiliser l'héritage et les interfaces

Pour résoudre ce problème et respecter le principe Open/Closed, tu vas utiliser une interface et des classes spécifiques pour chaque type de paiement. Comme ça, tu pourras ajouter de nouvelles méthodes de paiement sans toucher au code existant.

Quelques explications

Chaque méthode de paiement implémente l'interface PaymentMethodInterface, ce qui garantit qu'elles ont toutes la méthode pay().
Dans chaque classe, on utilise l'attribut #[AsTaggedItem('payment.method')] pour dire à Symfony que ces classes représentent des méthodes de paiement. Elles sont toutes taguées sous le même nom, payment.method, pour être facilement récupérables.

Le service principal PaymentService

Maintenant, notre PaymentService doit savoir quelle méthode de paiement utiliser, celle qui a été sélectionnée par l'utilisateur par exemple. Voici comment créer le PaymentService pour qu'il prenne en compte la méthode de paiement envoyée par le contrôleur.

Dans ton contrôleur, tu vas récupérer la méthode de paiement depuis la requête (via un query parameter par exemple) et la passer au PaymentService. Ton controller pourrait ressembler à ça :

Il est important que chaque méthode soit taguée correctement pour être injectée dans le PaymentService grâce au TaggedIterator.

En résumé, l'itérable $paymentMethods dans le PaymentService permet de récupérer dynamiquement toutes les méthodes de paiement disponibles, et le contrôleur passe cette information en fonction de la requête. Le service choisit ensuite la bonne méthode en fonction de la requête et procède au paiement.

Cette approche respecte le principe Open/Closed tout en exploitant les fonctionnalités modernes de Symfony pour rendre le code plus flexible et extensible.

3. Le * L * ➡️ Liskov Substitution Principle

"Les objets d'une classe dérivée doivent pouvoir remplacer les objets de leur classe mère sans altérer le bon fonctionnement du programme."

Ce principe peut paraître un peu complexe à première vue, mais il est essentiel pour assurer la cohérence de ton code. En résumé, une classe fille doit pouvoir être utilisée partout où une classe mère est attendue, sans briser le comportement du programme.

Exemple avec Symfony

Prenons une classe Article et une classe FeaturedArticle, qui hérite de Article. Si FeaturedArticle ne respecte pas le contrat de la classe mère Article, tu risques d’avoir des problèmes lors de son utilisation dans certaines parties de ton code.

Voici un cas qui viole le principe de Liskov :

À première vue, ça peut sembler correct, mais si tu passes un FeaturedArticle dans une logique qui attend un Article, tu risques d’avoir des résultats inattendus.

Par exemple, imagine un système où les titres sont mis à jour automatiquement :

Le titre sera "Featured: Nouveautés", même si ce n'était pas prévu.

Solution

Pour respecter le principe de Liskov, tu dois faire en sorte que les classes dérivées n'altèrent pas le comportement attendu de la classe mère. Par exemple avec Symfony, si tu as un formulaire de base pour un Article, et que tu veux étendre son comportement pour un FeaturedArticle, tu peux étendre le FormType tout en conservant les propriétés de base.

1. Crée un `FormType` pour un article de base :

2. Crée un FormType pour un FeaturedArticle qui hérite de ArticleType :

Dans le contrôleur, utilise ce FormType pour un article à la une :

Avec cette approche, le principe de Liskov est respecté. Tu peux utiliser FeaturedArticleType partout où ArticleType est utilisé, tout en ajoutant des champs spécifiques sans casser le comportement de base.

4. Le * I * ➡️ Interface Segregation Principle

"Une classe ne doit pas être obligée d'implémenter des méthodes qu'elle n'utilisera jamais."

Si tu veux garder ton code flexible, ce principe est primordial. Il dit que si une classe implémente une interface, elle ne doit implémenter que ce dont elle a besoin. Si l'interface est trop générale et oblige une classe à implémenter des méthodes inutiles, elle deviendra plus complexe et difficile à maintenir.

Exemple avec Symfony

Imaginons que tu aies une interface pour un export de données, avec plusieurs types d’export (CSV, JSON, XML). Si tu crées une interface unique pour tout, tu ne respectes pas le principe de ségrégation des interfaces :

Si tu implémentes cette interface dans une classe qui n'a besoin que de JSON, tu te retrouves à devoir définir des méthodes inutiles, comme exportToCSV() et exportToXML().

Solution : Créer des interfaces spécifiques

La solution est de diviser cette interface en plusieurs petites interfaces qui sont spécifiques à chaque besoin :

Maintenant, chaque classe implémente seulement les interfaces dont elle a besoin :

Ton code est plus léger et maintenable, sans méthodes superflues !

5. Le * D * ➡️ Dependency Inversion Principle

"Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Tous deux doivent dépendre d'abstractions."

🔔 Dernier principe ! 🔔
Si tu es arrivé jusque là, je te félicite car ce n'était pas simple !

Alors, qu'est-ce qu'il nous dit ce dernier principe ?
Il nous dit tout simplement de ne pas dépendre de classes concrètes, mais plutôt d’abstractions (des interfaces ou des classes abstraites).

Exemple avec Symfony

Imaginons un service qui envoie des notifications. Une mauvaise approche serait de faire dépendre directement ce service des implémentations concrètes :

Ici, on voit que ce service dépend directement des implémentations concrètes d'email et de SMS (les classes EmailService et SmsService). Si tu veux changer le système d'envoi d'email, il faudra que tu modifies cette classe.

Solution

Une meilleure approche est de faire en sorte que NotificationService dépende d'une abstraction (une interface), plutôt que d'implémentations concrètes :

Interface pour les services de notification :

Implémentation pour les emails 📧 :

Implémentation pour les SMS 📱 :

Le service NotificationService dépend maintenant de NotificationInterface, ce qui te permet de changer facilement l'implémentation sans toucher au service principal.

Maintenant on va injecter dynamiquement ces services dans un NotificationManager :

Utilisation dans le contrôleur

Dans le contrôleur, on peut choisir dynamiquement le service de notification à utiliser :

On injecte toutes les implémentations de NotificationServiceInterface automatiquement grâce au tag #[AsTaggedItem('notification.service')] sur chaque service.
Le contrôleur peut choisir dynamiquement quel service utiliser via une query string dans la requête.

Cette solution suit parfaitement le dernier principe SOLID car :

Le NotificationManager ne dépend que de l'interface NotificationServiceInterface, et non des implémentations spécifiques.
Le code est ouvert à l'ajout de nouveaux services (par exemple, une notification par push) sans modifier le NotificationManager.

Conclusion

Et voilà ! Tu as maintenant une solide 😉 compréhension des principes SOLID et de leur application dans un projet Symfony. Le but de ces principes est de rendre ton code plus flexible, facile à maintenir, et surtout testable.

Ces concepts peuvent parfois sembler abstraits, mais lorsqu'ils sont appliqués, ils t'offrent un énorme gain en termes de qualité et de durabilité du code !

Le Design Pattern Observer : un système de notification puissant

TechniveK — Thu, 12 Sep 2024 11:55:50 +0000

Dans le développement de tes applications, tu auras souvent besoin que ton application puisse réagir à des événements de manière flexible. Par exemple, imaginons que tu souhaites notifier plusieurs systèmes lorsque certaines actions se produisent (comme l'inscription d'un utilisateur). C'est là que le Pattern Observer entre en jeu. Ce pattern te permet d'établir une relation entre des objets, afin que lorsque l'état de l'un change, tous les autres soient automatiquement informés et mis à jour.

Symfony implémente déjà efficacement ce pattern grâce à l'Event Dispatcher, ce qui le rend bien pratique et puissant à utiliser dans tes projets.

Qu'est-ce que le Pattern Observer ?

Le Pattern Observer permet de définir une relation entre le sujet observé et un ou plusieurs observateurs. Lorsqu'un changement d'état survient sur l'objet observé, tous les observateurs sont notifiés pour qu'ils puissent réagir en conséquence.

Voilà comment ça fonctionne :

👨 Sujet (Observable) : L'objet principal qui change d'état.
👀 Observateurs (Observers) : Les objets qui réagissent aux changements de l'observable.

Exemple

Imaginons que tu as un site où un utilisateur peut s'inscrire. À chaque inscription, tu veux envoyer un email de bienvenue, ajouter l'utilisateur à une liste de newsletters et informer un système d'analytics.

Plutôt que de tout coder de manière rigide au même endroit, tu peux déléguer ces tâches à différents observateurs qui seront informés dès que l'événement "utilisateur inscrit" est déclenché.

Implémentation du Pattern Observer dans Symfony

Dans Symfony, tu vas utiliser l'Event Dispatcher pour mettre en place le Pattern Observer. Ca va te permettre d'organiser le code proprement et de le rendre extensible sans modification de la logique de base.

Étape 1️⃣ : Déclarer l'Événement

On va commencer par créer un événement qui sera dispatché lorsqu'un utilisateur s'inscrit. Ce dernier contiendra les informations de l'utilisateur.

Étape 2️⃣ : Dispatcher l'Événement

Maintenant, dans ton contrôleur ou service, tu vas dispatch cet événement quand un utilisateur s'inscrit.

Étape 3️⃣ : Créer des Observateurs (Listeners)

Ensuite, tu vas devoir créer les observateurs, qui seront appelés à chaque fois que l'événement d'inscription est dispatché. Ici, tu as l'exemple où on envoie un email et on ajoute l'utilisateur à une liste de newsletters.

Observateur 1 : Envoyer un email de bienvenue

Observateur 2 : Ajouter l'utilisateur à une liste de newsletters

Étape 4️⃣ : Configuration des Observateurs

Tu dois maintenant enregistrer les listeners dans la configuration pour qu’ils écoutent l’événement user.registered.

Dans config/services.yaml, il faut ajouter les observateurs comme services :

ℹ️ Depuis la version 5.3 de Symfony, tu peux utiliser des attributs PHP pour configurer les services et les écouteurs d'événements (event listeners). C'est une approche plus moderne qui te permet de déclarer les événements directement dans les classes, au lieu d’utiliser le fichier services.yaml.
Tu peux donc utiliser l'attribut #[AsEventListener] directement sur la méthode de ton listener.

Je vais te montrer comment adapter les deux observateurs avec des attributs (donc plus besoin de config particulière dans config/services.yaml 😉 :

Observateur 1

Observateur 2

Petite explication

L'attribut #[AsEventListener] indique que la méthode est un listener pour un événement spécifique.
Le premier argument de l'attribut est le nom de l'événement que l'observateur écoute (UserRegisteredEvent::NAME).
Et enfin, le paramètre method précise la méthode de la classe qui sera exécutée lorsque l'événement sera déclenché (dans notre cas, onUserRegistered). 😄

Étape 5️⃣ : Tester l'implémentation

Lorsque tu enregistres un utilisateur avec le contrôleur RegistrationController, l'événement est dispatché et Symfony appelle automatiquement les observateurs correspondants. L'email est envoyé, et l'utilisateur est ajouté à la liste de newsletters sans que ces actions/logiques ne soient mélangées à ton code métier.

Pourquoi Utiliser le Pattern Observer ?

Parce que c'est un indispensable ! Il permettra à ton application d'être :

Plus flexible : tu peux ajouter ou modifier des observateurs sans toucher à ton code principal. Il suffit d'ajouter un listener !
Moins couplée : les différentes parties de ton appli ne sont pas étroitement liées. Par exemple, l'envoi d'emails et l'ajout à la newsletter ne sont pas codés directement dans le contrôleur d'inscription.
Plus scalable : ce pattern permet de réagir facilement à des événements qui pourraient impliquer plusieurs systèmes ou services (notifications, analytics, envois, etc.).

Bonus : Le lien avec le DDD (Domain-Driven Design)

Le Pattern Observer trouve souvent sa place dans les architectures basées sur le DDD (Domain-Driven Design), où les événements sont des éléments clés (Domain Events). Ces événements permettent de faire réagir différentes parties du système, souvent en dehors du domaine principal. Mais ça, c’est une discussion pour un prochain article complet sur le DDD !

Découverte de l'Architecture Hexagonale : l'hexa c'est carré !

TechniveK — Wed, 11 Sep 2024 19:48:47 +0000

Dans le développement logiciel, on cherche souvent à résoudre les problèmes d'évolutivité, de maintenabilité et de testabilité du code. C’est là qu’entre en scène l'Architecture Hexagonale, aussi appelée "Ports and Adapters".

L'idée de cette approche développée par Alistair Cockburn est que le domaine métier (le cœur de ton application) soit isolé du reste du système et puisse être utilisé indépendamment des technologies externes (framework, base de données, UI, API externes).

Allez, on va plonger dans les concepts fondamentaux de l'Architecture Hexagonale et voir ensemble comment elle peut transformer la manière dont tu conçois ton code ! 😉

C'est quoi exactement l'Architecture Hexagonale ?

L'Architecture Hexagonale est une façon de structurer une application pour qu’elle soit indépendante des détails externes. Elle insiste sur la séparation des préoccupations en découpant l'application en plusieurs couches distinctes.

Le but est de rendre l'application indépendante des technologies spécifiques, en organisant les interactions entre le cœur de l'application (la logique métier) et le monde extérieur (base de données, interfaces utilisateur, API, frameworks, etc.), tout ça via des Ports et des Adapters.

Le concept de base

Imagine ton application comme un hexagone avec, au centre, le domain (la logique métier). Ce cœur métier ne doit pas être directement lié aux détails d'implémentation (comme Symfony, Doctrine, une API tierce, etc.). Pour y arriver, il va falloir créer des interfaces appelées Ports, et ces interfaces vont être implémentées par des Adapters, qui s'occupent de la communication avec les services externes.

🛂 Ports : autrement dit, les interfaces par lesquelles le monde extérieur peut interagir avec le noyau métier. Les ports, ce sont les points d’entrée ou de sortie de l’application (API, requêtes HTTP, commandes CLI, etc.).

🎯 Adapters : les adapters sont les implémentations concrètes de ces interfaces. Ils traduisent les demandes ou réponses externes en actions compréhensibles pour la logique métier. Cela inclut les interactions avec les bases de données, les frameworks, les API, etc.

Structure d'une application hexagonale

Pour mieux comprendre, on va se baser sur un exemple simple en Symfony. Imaginons que ton application doit permettre à des utilisateurs de passer des commandes, et qu'elle doit interagir avec une base de données pour stocker ces commandes.

Eh bien, regarde comment tu pourrais structurer ton application selon l'architecture hexagonale. 👀

1. Le Cœur Métier

C’est le noyau de ton application, la partie qui n'a aucune dépendance externe. C’est là que réside la logique métier, comme la création d’une commande, la validation de ses données, etc.

Ici, la classe Order représente le modèle de base d'une commande. Tu remarqueras que cette classe ne sait rien de la manière dont elle sera stockée, ni d’où viennent les données.

2. Les Ports (Interfaces)

Les Ports définissent les interfaces que les adaptateurs vont devoir implémenter pour que la logique métier puisse fonctionner. Ils peuvent être des points d'entrée dans le système (comme des requêtes HTTP) ou des points de sortie (comme les appels à la base de données).

L'interface OrderRepositoryInterface va servir de port de sortie. Elle ne fait que définir les méthodes dont la logique métier a besoin pour interagir avec la base de données. Le domaine ne sait pas comment ces données vont être sauvegardées.

3. Les Adapters (Implémentations)

L'Adapter, c'est tout simplement l'implémentation concrète d'un Port. L'Adapter va permettre de traduire :

toutes les interactions externes vers la logique métier
la logique métier vers des actions concrètes (comme sauvegarder dans une base de données).

L’adapter ici traduit l’appel à OrderRepositoryInterface en une interaction avec Doctrine (bibliothèque de gestion de base de données) mais ta logique métier n'a aucune idée que Doctrine est utilisé.

4. Un exemple de contrôleur dans Symfony

Le contrôleur va agir comme un point d’entrée pour notre application. C’est lui qui interagit avec l’utilisateur via les requêtes HTTP, puis délègue les tâches au domaine via les Ports et Adapters.

Ici, tu peux voir que le contrôleur ne connaît que l’interface OrderRepositoryInterface et pas l’implémentation concrète. Ca permet de rendre le code testable, extensible, et indépendant des frameworks et technologies externes (Symfony, Doctrine, etc.).

Pourquoi utiliser l'Architecture Hexagonale ?

En séparant ta logique métier des implémentations externes (base de données, HTTP, API externes), tu rends ton code plus flexible. Changer de base de données ou de framework devient plus simple et moins risqué.
Comme la logique métier n'est pas liée à des éléments externes, tu peux facilement mock ou remplacer les adaptateurs dans tes tests.
Avec cette séparation claire, il est plus facile d'ajouter de nouvelles fonctionnalités, de modifier des comportements ou de réutiliser certains composants sans toucher à la logique métier.
Tu peux réutiliser le même cœur métier avec différents types d'adaptateurs. Par exemple, la même logique métier peut être utilisée pour une application web, une API REST ou encore une interface en ligne de commande.

Mais attention !

Même si l'architecture hexagonale est puissante, structurer ton application de cette façon peut être un peu overkill, surtout pour des petits projets. Pour des petites applications, l'architecture hexagonale peut ajouter une complexité inutile, car tout découpler n’est pas toujours nécessaire.

Simplifier la gestion des permissions avec le Pattern Decorator en PHP et Symfony

TechniveK — Tue, 10 Sep 2024 11:35:02 +0000

Gérer les permissions dans une application peut vite devenir compliqué, surtout quand tu dois ajouter des couches d’autorisations supplémentaires au fil du temps. Plutôt que d’avoir une classe géante qui gère tous les types d’autorisations possibles, le Pattern Decorator te permet d’ajouter ou modifier dynamiquement les permissions en empilant des décorateurs. Intéressant non ?

Pourquoi le Pattern Decorator ?

Le Pattern Decorator permet d'enrichir un objet avec de nouvelles fonctionnalités sans modifier sa structure de base. Dans le cas de la gestion des permissions, il te permet d’ajouter des règles ou des couches d’autorisation au fur et à mesure que tu en as besoin. Et le gros avantage, c’est que tu n’as pas à modifier ton code existant à chaque fois que tu ajoutes une nouvelle règle.

En gros, tu peux partir d’un objet simple et lui « coller » des fonctionnalités au fur et à mesure que tu en as besoin. Tu ne me crois toujours pas ? Check la suite !

Exemple concret : Gestion des permissions utilisateur

Disons que ton application doit gérer différents types d'utilisateurs (admin, éditeur, lecteur). Chaque utilisateur a des permissions différentes : un admin peut tout faire, un éditeur peut modifier du contenu, et un lecteur ne peut que consulter.

Plutôt que d'enfermer ces règles dans une énorme classe conditionnelle, on va utiliser le Pattern Decorator pour gérer les permissions d'accès dynamiquement.

Étape 1 : L'interface de base

On va commencer par définir une interface PermissionInterface qui représente le concept de "permission". Chaque permission va offrir la méthode checkAccess(), qui vérifie si l'utilisateur a accès à une ressource spécifique.

Étape 2 : La classe de base (utilisateur sans privilèges)

Ensuite, on va créer une classe de base pour un utilisateur avec un accès basique, sans permissions spécifiques.

Étape 3 : Les décorateurs pour les permissions

Et maintenant, on va créer des décorateurs pour ajouter différentes permissions à notre utilisateur. Par exemple, un décorateur pour un utilisateur avec un accès administrateur :

Tu commences à comprendre le principe... On va créer un autre décorateur pour un éditeur, qui peut seulement modifier du contenu, mais pas tout :

Et enfin, on peut avoir un décorateur pour un utilisateur en mode lecture seule (comme un lecteur) :

Étape 4 : Utilisation dans Symfony

Il est temps d'utiliser ces magnifiques décorateurs dans un contrôleur Symfony pour gérer les permissions d’un utilisateur en fonction de son rôle.

On va utiliser un cas classique : un utilisateur veut accéder à la page d'édition d'une page (ou d'un article, peu importe). Selon ses permissions (admin, éditeur, etc.), il peut avoir accès ou non à cette page. C'est ici que l'empilement des permissions avec le PatternDecorator va intervenir.

Création de l'utilisateur : On commence par un utilisateur basique sans permissions particulières (BasicUser).
Ajout des permissions via les décorateurs : À chaque étape, tu peux "décorer" cet utilisateur en lui ajoutant des permissions.
Empilement des permissions : Chaque décorateur s'ajoute dynamiquement à l'utilisateur, enrichissant ses droits d'accès.
Au final, le système va vérifier toutes les permissions cumulées via les décorateurs.

Les avantages du Pattern Decorator

Gestion flexible des permissions : Grâce au Pattern Decorator, tu peux facilement ajouter ou retirer des permissions sans toucher au code existant. Si demain tu ajoutes un nouveau type de rôle, il te suffit de créer un nouveau décorateur.
Meilleure séparation des responsabilités : Chaque rôle ou permission est encapsulé dans une classe distincte. Le code est donc plus clair, mieux organisé, et facile à maintenir.
Extension facile : Le jour où tu as besoin d’un rôle supplémentaire (par exemple, un modérateur), tu crées simplement un nouveau décorateur et le reste de ton système de gestion des permissions reste intact.

Mais prudence

Même si ce pattern est très pratique, fais attention à ne pas abuser du nombre de décorateurs. Trop de couches peuvent rendre ton code plus difficile à suivre. Assure-toi que chaque nouvelle permission ajoute vraiment de la valeur et évite de complexifier inutilement ton architecture.

En résumé

Le Pattern Decorator est une solution idéale pour gérer des permissions de façon dynamique dans une application Symfony. En empilant des décorateurs, tu peux ajouter des rôles et des règles d'accès de manière modulaire, tout en gardant ton code propre et facile à maintenir.

Si tu as apprécié cet article, n'hésite pas à me suivre et commenter !

Optimiser la gestion des comportements avec le Pattern Strategy en PHP et Symfony

TechniveK — Mon, 09 Sep 2024 15:24:04 +0000

Parfois, tu as un morceau de code qui peut se comporter différemment selon la situation. Par exemple, tu peux avoir besoin de calculer un tarif différemment en fonction du type de client, ou appliquer un algorithme de tri spécifique. Au lieu d'enfermer ces comportements dans de gros if ou des switch, tu peux utiliser le Design Pattern Strategy pour mieux structurer ton code.

Pourquoi le Pattern Strategy ?

Le Pattern Strategy te permet de séparer la logique d'action du reste du code, pour que tu puisses facilement changer ou remplacer cette logique sans avoir à modifier tout ton programme. Si tu as plusieurs façons d’exécuter une action, c’est ici que ce pattern devient très utile. Plutôt que d'avoir un gros bloc conditionnel, tu délègues le comportement à un objet spécifique.

Exemple concret : Calcul de réduction en fonction du type de client

Imaginons que tu développes une boutique en ligne et que tu aies besoin de calculer une réduction pour différents types de clients (standard, premium, VIP). Au lieu d’écrire des conditions pour chaque type de client un peu partout dans ton code, tu vas pouvoir utiliser le Pattern Strategy pour encapsuler chaque calcul de réduction dans une classe dédiée.

Étape 1 : Interface de la stratégie

On va commencer par créer une interface DiscountStrategy qui définit une méthode calculate() que chaque stratégie de calcul de réduction devra implémenter.

Étape 2 : Stratégies spécifiques

Ensuite, on va créer les différentes stratégies de calcul de réduction. Par exemple, pour les clients standards, il n’y a pas de réduction :

Pour les clients premium, on va appliquer une réduction de 10 % :

Et pour les clients VIP, une énorme réduction de 20 % :

Étape 3 : Classe de contexte

Maintenant, on va créer une classe qui utilisera ces stratégies. Cette classe ne se préoccupe pas du type de réduction à appliquer, elle délègue cette logique à la stratégie qu’on lui passe.

Étape 4 : Utilisation dans Symfony

Génial ! On va voir maintenant comment on peut intégrer tout ça dans un contrôleur Symfony. Tu vas choisir une stratégie en fonction du type de client, mais toute la logique du calcul reste dans les classes de stratégie, ce qui rend ton contrôleur bien plus simple et propre.

Ce que ça t'apporte

Flexibilité : Grâce au Pattern Strategy, tu peux facilement ajouter ou modifier des comportements sans toucher à ton code principal. Il te suffit d’ajouter une nouvelle stratégie de calcul.
Code propre et lisible : Ton code devient beaucoup plus lisible en éliminant les blocs de if ou switch massifs. Chaque stratégie a sa propre classe avec une seule responsabilité, ce qui respecte le Single Responsibility Principle (SRP).
Évolutivité : Si un jour, tu dois ajouter une réduction pour les super VIP avec une réduction indécente de 50 %, tu crées simplement une nouvelle stratégie et le reste de ton code ne change pas !

En résumé

Le Pattern Strategy est un excellent choix lorsque tu as plusieurs façons d’exécuter une même action et que tu veux que ton code reste flexible et évolutif. Plutôt que de te retrouver avec des conditions à n’en plus finir, tu encapsules les comportements dans des classes dédiées, ce qui te permet de les interchanger facilement.

Et toi tu as déjà utilisé le Pattern Strategy dans tes projets Symfony ? N'hésite pas à commenter cet article !

Comprendre le Design Pattern Factory en PHP et Symfony

TechniveK — Mon, 09 Sep 2024 11:18:19 +0000

Si tu cherches à rendre ton code plus flexible et maintenable, le Design Pattern Factory est une excellente solution. Il te permet de déléguer la création d’objets à une méthode spécialisée, ce qui peut être super utile lorsque tu dois gérer différents types d’objets qui partagent une interface commune.

Pourquoi choisir le Pattern Factory ?

Imaginons que tu as plusieurs types d'objets à instancier dans ton projet, chacun avec sa propre logique spécifique. Si tu commences à multiplier les new ClassName() partout, ton code devient rapidement difficile à maintenir. Et c'est là qu'intervient le Pattern Factory.

Tu vas voir, c'est très simple : au lieu d'instancier directement un objet avec new, tu passes par une méthode factory qui se charge de choisir et de créer l’objet qu’il te faut. Ça permet de découpler la logique de création du reste de ton code. Plus facile à maintenir, plus flexible.

Exemple concret : Notification Factory

Imaginons une application qui envoie des notifications. Tu pourrais avoir besoin d’envoyer des emails, des SMS, ou des notifications push. Plutôt que d’ajouter plein de if dans ton code pour savoir quelle classe instancier, tu délègues ça à une factory.

Étape 1 : Interface commune

D'abord, tu vas définir une interface que chaque type de notification doit implémenter. Chaque notification doit avoir une méthode send().

Étape 2 : Implémentations spécifiques

Chaque type de notification a sa propre classe, qui implémente cette interface. Par exemple, pour envoyer un email :

Pareil pour les SMS :

Et pour les notifications push :

Étape 3 : La Factory

Maintenant, on va créer la factory. C’est elle qui va décider quelle notification instancier selon le type que tu lui passes.

Étape 4 : Utilisation dans Symfony

Et voilà comment tu peux utiliser cette factory dans un contrôleur Symfony. Plutôt que d’écrire une tonne de if pour savoir quel type de notification envoyer, tu laisses la factory décider.

Ce que ça t’apporte

Séparation des préoccupations : Le contrôleur n’a pas à connaître la logique de création des notifications. Il s'occupe juste de son boulot : envoyer un message. Tout le reste est géré par la factory.
Facilité de maintenance : Si un jour tu dois ajouter un nouveau type de notification (par exemple une notification via Slack), il te suffit d’ajouter une nouvelle classe et de l’intégrer à la factory. Tu n’as pas à toucher au reste du code.
Extensibilité : Le Design Pattern Factory te permet d’ajouter facilement de nouveaux types de notifications sans casser ce qui fonctionne déjà. C’est du pur Open/Closed Principle du SOLID : ton code est ouvert à l’extension, mais fermé à la modification.

Mais attention !

Le Pattern Factory peut ajouter un peu de complexité, surtout dans des projets simples où un new classique ferait largement l'affaire. Il faut donc savoir l’utiliser quand c’est vraiment pertinent. Si tu sais que ton projet va évoluer et que tu vas devoir ajouter de nouveaux types d'objets régulièrement, c'est un excellent choix.

En résumé

Le Design Pattern Factory te permet de centraliser la création d’objets et de rendre ton code plus flexible. En déléguant la création d'objets à une méthode dédiée, tu facilites la maintenance et tu prépares ton projet à évoluer. Ce pattern s'intègre très bien dans un projet Symfony et peut vraiment t’aider à garder ton code propre et organisé.

Alors, prêt à intégrer ce pattern dans ton prochain projet Symfony ? Si tu as déjà utilisé le Factory, n’hésite pas à partager ton expérience. Toujours curieux de savoir comment les autres s’y prennent !

DEV Community: TechniveK

Le cache dans les applications web : le secret des performances

Le cache : essentiel pour plusieurs raisons

1. Le cache navigateur : garder les ressources localement

Comment ça fonctionne ?

Les avantages :

Les limites :

2. Le cache HTTP : l’optimisation côté serveur

Comment ça marche ?

3. Le cache système : optimiser les données à long terme

Exemple avec le FilesystemAdapter (cache sur disque)

Exemple avec RedisAdapter (cache en mémoire)

4. Le cache en base de données : optimiser les requêtes

Comment ça fonctionne ?

Exemple : Cache des produits les plus vendus

Autre méthode : utilisation du cache intégré à Doctrine (Result Cache)

Conclusion

Maîtriser les principes SOLID : pour un code propre et performant

1. Le * S * ➡️ Single Responsibility Principle

Exemple avec Symfony

2. Le * O * ➡️ Open/Closed Principle

Exemple avec Symfony

Quelques explications

3. Le * L * ➡️ Liskov Substitution Principle

Exemple avec Symfony

Solution

1. Crée un FormType pour un article de base :

2. Crée un FormType pour un FeaturedArticle qui hérite de ArticleType :

4. Le * I * ➡️ Interface Segregation Principle

Exemple avec Symfony

Solution : Créer des interfaces spécifiques

5. Le * D * ➡️ Dependency Inversion Principle

Exemple avec Symfony

Solution

Utilisation dans le contrôleur

Conclusion

Le Design Pattern Observer : un système de notification puissant

Qu'est-ce que le Pattern Observer ?

Exemple

Implémentation du Pattern Observer dans Symfony

Étape 1️⃣ : Déclarer l'Événement

Étape 2️⃣ : Dispatcher l'Événement

Étape 3️⃣ : Créer des Observateurs (Listeners)

Observateur 1 : Envoyer un email de bienvenue

Observateur 2 : Ajouter l'utilisateur à une liste de newsletters

Étape 4️⃣ : Configuration des Observateurs

Observateur 1

Observateur 2

Petite explication

Étape 5️⃣ : Tester l'implémentation

Pourquoi Utiliser le Pattern Observer ?

Bonus : Le lien avec le DDD (Domain-Driven Design)

Découverte de l'Architecture Hexagonale : l'hexa c'est carré !

C'est quoi exactement l'Architecture Hexagonale ?

Le concept de base

Structure d'une application hexagonale

1. Le Cœur Métier

2. Les Ports (Interfaces)

3. Les Adapters (Implémentations)

4. Un exemple de contrôleur dans Symfony

Pourquoi utiliser l'Architecture Hexagonale ?

Mais attention !

Simplifier la gestion des permissions avec le Pattern Decorator en PHP et Symfony

Pourquoi le Pattern Decorator ?

Exemple concret : Gestion des permissions utilisateur

Étape 1 : L'interface de base

Étape 2 : La classe de base (utilisateur sans privilèges)

Étape 3 : Les décorateurs pour les permissions

Étape 4 : Utilisation dans Symfony

Les avantages du Pattern Decorator

Mais prudence

En résumé

Optimiser la gestion des comportements avec le Pattern Strategy en PHP et Symfony

Pourquoi le Pattern Strategy ?

Exemple concret : Calcul de réduction en fonction du type de client

Étape 1 : Interface de la stratégie

Étape 2 : Stratégies spécifiques

Étape 3 : Classe de contexte

Étape 4 : Utilisation dans Symfony

Ce que ça t'apporte

1. Crée un `FormType` pour un article de base :