Si vous développez avec Symfony, vous connaissez probablement le « Symfony Profiler ». Cette barre d’outils s’affiche en bas de vos pages web et fournit des pages dédiées pour analyser les données collectées par Symfony.
Saviez-vous qu’il est possible d’ajouter davantage d’informations au profiler ? C’est ce que nous allons explorer dans cet article.
Lorsque notre application interagit avec le monde extérieur (par exemple : HTTP, SQL, AMQP, API tierces, etc.), il est très utile de mettre en place un profilage pour observer facilement ce que notre application envoie et reçoit.
Cela évite d’avoir à appeler la fonction dump(). En un coup d’œil, nous disposons de toutes les informations nécessaires pour faciliter le débogage.
Voici ce que nous pouvons et allons faire :
Comme vous l’avez deviné, nous allons créer un data collector pour le SDK Stripe 🎉
Notez qu’un collecteur de données n’est pas limité à la collecte d’informations échangées avec le monde extérieur. Par exemple, Symfony dispose d’un profiler pour les workflows ou la configuration de l’application.
Avant de nous lancer tête baissée dans le code, il est essentiel de comprendre comment fonctionne la brique que nous souhaitons profiler et quels sont les points d’extension à notre disposition.
Stripe offre un point d’extension pour modifier l’ApiRequestor. Cette classe a pour but d’envoyer une requête HTTP et de retourner une réponse.
Bien que Stripe propose une API orientée objet, la manière de changer ce requestor est un vestige des temps anciens où l’API était uniquement statique :
$curl = new Stripe\HttpClient\CurlClient(); Stripe\ApiRequestor::setHttpClient($curl); Avec Symfony, nous préférons des approches entièrement orientées objet, mais ici nous n’avons pas le choix. Nous devrons utiliser une fabrique pour créer et configurer le client :
namespace AppBundle\Billing\Stripe; use Psr\Log\LoggerInterface; use Psr\Log\NullLogger; use Stripe\HttpClient\ClientInterface; us...
[Courte citation de 8% de l'article original]