http client recommendation: Symfony?
tacman opened this issue · comments
we recommend using Guzzle 7:
FWIW, I like the Symfony client better. I believe it's faster, and a very clean API (via symfony/contracts), follows the PSR standards and has built-in error logging, async and retries.
Furthermore, anyone using the symfony framework gets http requests in the debug toolbar.
I'm glad installing Symfony is documented, but in 2024 I think it's also the better option and would recommend that it be the recommended way, and then showing an example with Guzzle 7.
In meilisearch-symfony lib of course it uses Symfony HttpClient:) if you have it
I close this issue then. Feel free to ask to re-open if needed 😊
Again, this is just a request to recommend Symfony rather than Guzzle in the documentation. I can make the PR if you'll accept it, but are you saying you prefer to recommend Guzzle?
I understand that the bundle using Symfony if you have it.
Sorry I went to fast and I was confused in my open tabs 😅 did not answer the right one!
@norkunas do you think we should recommend Symfony bundler instead?
We did not have any issue with recommending Guzzle so far, and we also mention the Symfony ones in the example right below in the README, so I personally don't see the point of changing this, but I might be wrong
As I come from Symfony ecosystem I'd recommend it's http client, but it's a biased opinion. Laravel ecosystem uses mostly guzzle and guzzle has more downloads, but that doesn't mean it's better than symfony http client. I'd remove the recommendation at all and instead just would leave the link to https://packagist.org/providers/psr/http-client-implementation so people can choose what they need.
Another option reword the examples:
If you want to use guzzle, do this: .., if you want to use symfony http client: do this ..
Or maybe just offer both equally, rather than a recommendation, based on your needs.
This is an interesting read, and it's hard to tell if it's still accurate in 2024, since both clients have improved.
All my projects are in Symfony, but many bundles require guzzle, leading to an extra configuration,e.g. KnpLabs/packagist-api#91
Fortunate, this library doesn't do that, so really it's just a matter of why encourage one over the other.
Symfony's HttpClient, on the other hand, does not provide built-in support for concurrency and is focused more on simplicity and ease of use.
bullshit :D from sf docs:
Concurrent Requests
Thanks to responses being lazy, requests are always managed concurrently. On a fast enough network, the following code makes 379 requests in less than half a second when cURL is used:
yes, sometimes there's no way to avoid additional deps because of some packages, but if you use very little of it's apis then you can just manually replace those calls directly with a http client.. but luckily we don't suffer from that problem here 🙂
Another option reword the examples:
If you want to use guzzle, do this: .., if you want to use symfony http client: do this ..
let's do with this
I'd remove the recommendation at all and instead just would leave the link to
https://packagist.org/providers/psr/http-client-implementationso people can choose what they need.
This is a good idea IMO, and I think you're already nearly there, since I see the Psr\Http\* interfaces being used. The only thing I would add is to remove the php-http/* packages, or at least these two. Requiring a Psr17/Psr18 implementation pretty much removes the need for this, as long as you have dependency injection set up.
@pkruithof I suggested removal of php-http/* packages in #653
What do we miss to close this issue @norkunas?
Not sure. Can be closed or we can recommend symfony http client, up to you.
Recommending the symfony client is a really tiny detail, and up to any developer to choose.
As long as we show symfony client works with this package, I'm ok with the current README.
Closing this issue then
we recommend using Guzzle 7:
Why?