Replace Guzzle with PSR-18 HTTP client

[garak]

Describe the feature

It would be nice not to force the developers using this library to use the Guzzle HTTP client.
The choice of the HTTP client should be left to the developer.
Of course, Guzzle can still be used and declared as a dev dependency, reducing the amount of work for the change (being Guzzle itself fully compatible with PSR-18)

Use Case

I'd like to use this library, but I already use a different HTTP client that is PSR-18 compatible. Currently, I'm forced to use two clients to achieve the same result.

Proposed Solution

Replace the injection of GuzzleHttp\ClientInterface with Psr\Http\Client\ClientInterface

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

SDK version used

3.349.3

Environment details (Version of PHP (php -v)? OS name and version, etc.)

8.4.5 (but it's not relevant here)

[stobrien89]

Hi @garak,

Thanks for the feedback. Overall, I agree with the sentiment. I think we should be more flexible with regard to PSR implementations. We are pretty tightly coupled with guzzlehttp\promises and guzzlehttp\psr7 (edit: flexible in that regard). The client situation is a little more nuanced— if we were to move this to a dev dependency, we'd end up breaking a lot of people. GuzzleHandler is used by default, so we would need to overhaul how default handlers are determined. But I suppose it's feasible.
 

Currently, I'm forced to use two clients to achieve the same result.

Curious to know what your current workflow looks like. We might be able to do something that could make this a bit easier for people

[garak]

The point is exactly that people using Guzzle won't be affected by the change, because they already have a PSR-compatible HTTP client (which is Guzzle itself). They only need to explicit the requirement (which could be easily covered in an upgrade documentation)

For example, I use the Symfony client instead of Guzzle. When I install the AWS SDK, I end up with Guzzle too, so I have two clients doing the same things. Moreover, I lose client integration (since the Symfony client logs every HTTP call in its profiler, but obviously, HTTP calls made by Guzzle are not logged).

[stobrien89]

Thanks for clarifying - the Symfony profiler integration issue is a valid concern.

The blocker is that PSR-18 only provides synchronous sendRequest(), while GuzzleHandler requires Guzzle's sendAsync() for promise-based operations. Switching to the PSR-18 ClientInterface without changing how default handlers are resolved would cause fatal errors because sendAsync() doesn't exist on PSR-18 interfaces.

[garak]

I see.
If the change is not possible or overcomplicated, feel free to close this issue.

[stobrien89]

I think it's possible and probably a bit complicated, but something worth investigating. We may be able to find a way to expose this in aws-sdk-php-symfony. I'll leave this open for the time being— we'll look into it as soon as we have the bandwidth to do so. In the meantime, we'd be open to accepting a PR for something like this if you also want to take a look

[GrahamCampbell]

It's worth noting that Amazon originally created Guzzle so that this SDK could use it, and there's little value for most users in being able to swap this out. For those wanting the Symfony's HTTP client, there's https://github.com/async-aws/.

[stobrien89]

@garak,

Explored this a few months ago and the added overhead just isn't worth it. I've had discussions about a more 'transport-agnostic' architecture and have mixed feelings about it, but if that's something you'd like to see in the future, definitely drop a comment in #3017. Closing for now, but reach out if anything else comes up.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.