I'd like to get some feedback on the following idea:
Currently this library is using Guzzle 5, 6 or 7, making it hard for consumers to upgrade to newer Guzzle versions once they come out until this library has been upgraded (with all the major version upgrades of this library to worry about as well), or potentially making it slightly harder to use another HTTP client library. Since we have PSR-17 and PSR-18, this should no longer be needed.
Currently this package relies on guzzle 5, 6 or 7, even though currently sufficient PSR standards are available to completely decouple from any particular HTTP client.
I'd like to propose (and get feedback on) the idea of removing Guzzle entirely, and to provide a way for users to provide their own PSR-18 compatible HTTP client, and a PSR-17 compatible request factory.
Rely solely on psr/http-client and psr/http-factory, and let users provide their own implementations
See:
https://www.php-fig.org/psr/psr-17/
https://www.php-fig.org/psr/psr-18/
Yes please, moreover guzzle is a pretty heavy http client and they've been BC break a lot over years. Would be a good thing to mover over. The most important part to be discussed here is probably the way to remove guzzle while trying to not be BC break into the SDK.
I can contribute if you need some help.
There is another problem. This sdk is build around guzzle promises. Every method has an async variant. Removing guzzle would probably mean to remove the promises as well.
The symfony http client has an interesting way handling async which is exploited by the async-aws project but that would probably be a hard dependency again.
Hi @Intrepidity, thanks for reaching out to us and I do apologize for the delay in response on our end. As @Nemo64 mentions the majority of our service clients' functions contain an asynchronous variant that relies on Guzzle promises which would be rendered unusable if we removed our dependency on this HTTP client by default.
That being said, if you'd prefer not to use Guzzle with the AWS SDK for PHP you can define your own HTTP handler for the SDK as mentioned in our developer guide. If implementing your own HTTP handler as described above doesn't fit your use case, please give us more details about your use case that prevents this solution from fulfilling your needs so we can improve the usability of the SDK in cases such as your own.
This issue has not recieved a response in 1 week. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.
Most helpful comment
Yes please, moreover guzzle is a pretty heavy http client and they've been BC break a lot over years. Would be a good thing to mover over. The most important part to be discussed here is probably the way to remove guzzle while trying to not be BC break into the SDK.
I can contribute if you need some help.