AbstractRequest performs the actual Guzzle call on execute(). The only override of the default Guzzle config is the base_uri.
public function execute(Response $response): void
{
// ...
try {
$guzzleClient = $this->getClient();
// ...
$guzzleConfig = $guzzleClient->getConfig();
# This also will override the version
$guzzleConfig['base_uri'] = $url;
$guzzleClient = new Client($guzzleConfig);
// ...So, the Guzzle client is tightly coupled to the abstract request. There seems to be no way to inject your own client instance, your own config on the client, and so on.
What we need to do, on our project, is be able to set a timeout and connect_timeout config value on the Guzzle client. That's the biggest issue. Some of our calls to the Pay API take over 20 or even 30 seconds, and we need to time out way before that.
So being able to inject, or configure through a config file, some of the typical Guzzle config values is pretty important.
Another consideration is that it helps testing to be able to determine the Guzzle stack, so that mocked responses and history may be used to do automated testing on projects that use this SDK. Being able to determine the Guzzle client that lives in the request would make it easy to do this and to set a custom default config.
My take would be to use a GuzzleClientFactoryInterface injected into the request (or better yet, to let the request be performed by a dedicated service, instead of a tightly coupled execute() on the request itself), so that developers might use their DI solutions to override the default factory and determine the Guzzle client that way.
AbstractRequest performs the actual Guzzle call on
execute(). The only override of the default Guzzle config is thebase_uri.So, the Guzzle client is tightly coupled to the abstract request. There seems to be no way to inject your own client instance, your own config on the client, and so on.
What we need to do, on our project, is be able to set a
timeoutandconnect_timeoutconfig value on the Guzzle client. That's the biggest issue. Some of our calls to the Pay API take over 20 or even 30 seconds, and we need to time out way before that.So being able to inject, or configure through a config file, some of the typical Guzzle config values is pretty important.
Another consideration is that it helps testing to be able to determine the Guzzle stack, so that mocked responses and history may be used to do automated testing on projects that use this SDK. Being able to determine the Guzzle client that lives in the request would make it easy to do this and to set a custom default config.
My take would be to use a GuzzleClientFactoryInterface injected into the request (or better yet, to let the request be performed by a dedicated service, instead of a tightly coupled
execute()on the request itself), so that developers might use their DI solutions to override the default factory and determine the Guzzle client that way.