{"version":"https:\/\/jsonfeed.org\/version\/1","title":"Scripting-Base - Blog about TYPO3 and stuff","home_page_url":"https:\/\/www.scripting-base.de\/blog","feed_url":"https:\/\/www.scripting-base.de\/blog.json","description":"Scripting-Base - Blog about TYPO3 and stuff","author":{"name":"Andreas Fernandez"},"items":[{"title":"Configure Guzzle via Dependency Injection","date_published":"2022-04-03T07:00:00+02:00","id":"https:\/\/www.scripting-base.de\/blog\/configure-guzzle-via-dependency-injection","url":"https:\/\/www.scripting-base.de\/blog\/configure-guzzle-via-dependency-injection","content_html":"

With Guzzle v7, its class GuzzleHttp\\Client<\/code> became annotated as @final<\/code> as it will be a real final<\/code> class in Guzzle\nv8. Extending Guzzle clients to enrich them with custom functionality or to pass configuration (e.g. API credentials) is\nnow discouraged and static code analysis tools like PHPStan may report this as an error. Depending on how\nGuzzleHttp\\Client<\/code> is extended, migration may be cumbersome. I got your back, and I'll cover some common cases in this\nblog post.<\/p>\n\n

Simple client with custom configuration<\/h2>\n

In a project, we heavily extended GuzzleHttp\\Client<\/code> for all our cases as we wanted to make use of dependency injection\nvia the client's class names. Please see the example below how our clients were implemented.<\/p>\n

We defined our class App\\Client\\GithubClient<\/code> that extends GuzzleHttp\\Client<\/code> without any further logic:<\/p>\n

\/\/ src\/Client\/GithubClient.php\nnamespace App\\Client;\n\nclass GithubClient extends \\GuzzleHttp\\Client\n{\n}<\/code><\/pre>\n
The client App\\Client\\GithubClient<\/code> is injected into the service App\\Service\\GithubService<\/code>:<\/p>\n
\/\/ src\/Service\/GithubService.php\nnamespace App\\Service;\n\nclass GithubService\n{\n    public function __construct(\n        private readonly GithubClient $client\n    ) {\n    }\n}<\/code><\/pre>\n
The client App\\Client\\GithubClient<\/code> is configured with the API key in the project's services.yaml<\/code> file:<\/p>\n
# src\/config\/services.yaml\nservices:\n  App\\Client\\GithubClient\n    class: App\\Client\\GithubClient\n    arguments:\n      $config:\n        headers:\n          Authorization: 'token %app.github.api_key%'<\/code><\/pre>\n
Migration time<\/h3>\n
This is the most simple way a Guzzle client may be configured. A client just takes some configuration (like the\nAuthorization<\/code> header from the example) above, and it's ready to use. The whole class can be replaced by a simple\nGuzzleHttp\\Client<\/code> instance, which is configured in our services.yaml<\/code> file:<\/p>\n
services:\n  guzzle.client.github\n    class: GuzzleHttp\\Client\n    arguments:\n      $config:\n        headers:\n          Authorization: 'token %app.github.api_key%'<\/code><\/pre>\n
\n
This requires another change! Since we are using GuzzleHttp\\Client<\/code> now, autowiring the correct Guzzle client via its class name does not work anymore.<\/p>\n<\/div>\n
Now, we have to configure our service to use the guzzle.client.github<\/code> service explicitly:<\/p>\n
services:\n  App\\Service\\GithubService:\n    class: App\\Service\\GithubService\n    arguments:\n      $client: '@guzzle.client.github'<\/code><\/pre>\n
Finally, we have to adjust the constructor<\/code> of our service to expect an instance \\GuzzleHttp\\Client<\/code> as argument:<\/p>\n
\/\/ src\/Service\/GithubService.php\nnamespace App\\Service;\n\nclass GithubService\n{\n    public function __construct(\n        private readonly \\GuzzleHttp\\Client $client\n    ) {\n    }\n}<\/code><\/pre>\n
This migration is pretty easy, the key changes are:<\/p>\n