-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http client recommendation: Symfony? #611
Comments
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? |
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 |
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. |
bullshit :D from sf docs:
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 🙂 |
let's do with this |
This is a good idea IMO, and I think you're already nearly there, since I see the |
@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. |
Why? |
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.
The text was updated successfully, but these errors were encountered: