Maîtriser le découplage piloté par les événements dans Laravel

Vos contrôleurs Laravel deviennent souvent des décharges pour la logique métier.

Vous commencez par un simple flux d'inscription. Rapidement, vous ajoutez des notifications par e-mail, des alertes Slack, des journaux d'audit et des appels API au sein d'une seule et même méthode. Cela crée un "fat controller" (un contrôleur trop chargé).

Les contrôleurs trop chargés rendent votre code fragile. Ils sont difficiles à tester. Ils violent le principe de responsabilité unique (Single Responsibility Principle).

Vous n'avez pas besoin d'outils complexes comme RabbitMQ pour corriger cela. Laravel dispose d'un système d'événements intégré qui répond à la plupart des besoins.

Le problème du couplage fort : Si une API de newsletter est lente, l'inscription de votre utilisateur ralentit. Si un service de messagerie échoue, toute la requête échoue.

La solution : l'architecture pilotée par les événements (Event-Driven Architecture).

Les événements agissent comme une couche intermédiaire. Votre contrôleur annonce une action. Les écouteurs (listeners) réagissent à cette action de manière indépendante.

Un contrôleur léger ressemble à ceci :

public function register(RegisterRequest $request)
{
    $user = User::create($request->validated());

    UserRegistered::dispatch($user);

    return response()->json(['message' => 'Success'], 201);
}

Le contrôleur ne gère désormais que la persistance des données. Il ne se soucie pas des effets de bord.

Vous obtenez trois avantages majeurs :

  • Performance : Les utilisateurs reçoivent une réponse immédiatement. Les tâches lourdes s'exécutent en arrière-plan en utilisant l'interface ShouldQueue.
  • Résilience : Si un service est indisponible, l'écouteur peut retenter la tâche sans interrompre l'application principale.
  • Extensibilité : Vous pouvez ajouter de nouvelles fonctionnalités, comme des notifications push, en ajoutant un nouvel écouteur. Vous ne touchez pas au contrôleur d'origine.

Bonnes pratiques à suivre :

  • Concentrez-vous sur les effets de bord : Utilisez les événements pour le post-traitement. Ne les utilisez pas pour la logique métier principale qui doit s'exécuter instantanément.
  • Utilisez des noms descriptifs : Utilisez des noms au passé comme OrderPlaced ou UserRegistered. Cela indique que l'action a déjà eu lieu.
  • Évitez la sur-abstraction : Si un morceau de code est simple et utilisé à un seul endroit, un appel de fonction est préférable à un événement.

Utilisez les Eloquent Observers pour les changements de base de données. Utilisez les Événements pour les actions métier.

Le refactoring vers les événements est une question de durabilité. Cela rend votre code plus facile à déboguer et plus rapide à tester.

Choisissez un effet de bord encombrant dans votre contrôleur et déplacez-le vers un écouteur dès aujourd'hui.

Essayez cet exemple dans un bac à sable : https://onlinephp.io/c/1f7b2

Source: https://dev.to/codecraft_diary_3d13677fb/beyond-fat-controllers-mastering-event-driven-decoupling-in-laravel-2dd6