Repository navigation
Ship the SDK with its own HTTP client instead of relying on HTTPlug #1384
Description
Problem Statement
We're currently using Httplug to allow people to use their HTTP client of choice with the SDK.
This creates confusion about why we offer two composer packages sentry/sentry vs sentry/sdk.
I also have the feeling that this is rarely used and slightly over-optimized.
Solution Brainstorm
Two good examples of other SDKs/libraries shipping with an HTTP client are the AWS PHP SDK (they use Guzzle) and Stripe (they implemented their own client).
While I do not think that Guzzle is necessary in our case, what other HTTP clients we could look into using in our SDK?
Activity
[-]Ship the SDK with it's own HTTP client instead of relying on HTTPlug [/-][+]Ship the SDK with its own HTTP client instead of relying on HTTPlug [/+]stayallive commentedon Sep 29, 2022
I would vote to go for a very simple interface like the one Stripe uses.
https://github.com/stripe/stripe-php/tree/master/lib/HttpClient
They use a very simple interface so the user can implement their own and ship with a cURL client by default. The cURL extension is by and large a default and available almost always and has no composer dependencies.
If we would go that route it's trivial to implement a Guzzle or whatever implementation that can be given to the SDK to do it's HTTP work without needing the full plumbing Htttplug provides which we workaround quite a lot already for timeouts and proxy configurations for example. Frameworks like Laravel and Symfony could also by default replace the client with the default shipped by their framework with a simple client implementation.
ste93cry commentedon Sep 29, 2022
I would love to see
Httpluggo as it is a relic of the past when a PSR standard wasn't available for HTTP clients. However, I don't see the point in implementing our client interfaces: the code is already decoupled from any HTTP client, and you can already use whatever lib you want. Moreover, if we want to to provide an HTTP client out the box, we should just choose one (I would recommendsymfony/http-clientgiven that we already use other components from that framework) and certainly not reimplement one (it was like that in the past, and it didn't work well)cleptric commentedon Sep 29, 2022
What is Symfony's statement on how long they will support v5.0 of their HTTP client library?
Their current v6.0 major already requires PHP 8.1 and up.
Jean85 commentedon Sep 29, 2022
Symfony has its how LTS schedule, so that's not a problem: https://symfony.com/releases#symfony-releases-calendar
IMHO we should still rely on PSR-18 as a decoupling interface to allow everyone to either use the provided client or swap-it-out with another custom one. This should give us the best of both worlds, because we can rely on any common HTTP client in PHP (even the Symfony one) to implement that one.
cleptric commentedon Sep 30, 2022
Using/building something PRS 18 compatible is definitely a good idea.
I just want to iterate that we should ship some HTTP client by default, and let people use something else if they really want to, or, use the one that ships with Symfony/Laravel for our other SDKs.
@stayallive Is the Laravel HTTP client PSR 18 compatible?
Maybe @richardm-stripe or @dcr-stripe are open about telling us about the reasoning behind Stripe opting into implementing their own HTTP client in their SDK 🙏