Please don't encroach on your team's happiness by choosing Net::HTTP. Ruby as a language was created to make developers happy. It comes as no surprise that this opinion is also shared by the Ruby toolbox. It has the best support, the biggest community, it is widely popular, shockingly-well maintained, fast and performant in terms of memory. Now that I have provided an overview, code snippets, and metrics of all gems, as well as Ruby community updates connected to them, I would like to offer a quick suggestion: if you are wondering which gem to use for your code base or a passion side project, do go with Faraday. Not surprisingly, Net::HTTP is not leading the way in any of the categories. NOTE: The memory allocation comparison comes from this gist and concerns the memory allocation for download.Īs you see above, Faraday is leading the way in almost all respects: number of downloads (which indicates its popularity), issue closure rate (which indicates maintainer support) and POST performance. Now that you have seen the five main Ruby clients, let's zoom out and compare them: Name There seem to be no good reason to submit any developr to this monster of a gem, especially that is not not fast and has just a disastrous memory allocation rates (see the table in the next section). This is definitely a long-winded way to make a request. If it had existed 10 years ago, we wouldn't have all these different clients in the first place I don't think.Response = Faraday. Personally, I think in 2021 you should just go with http-rb as a default. And personally I find it's API very weird for when you actually want an HTTP client. I think it's a disservice to recommend to people as a default.
I don't know if they've fixed their performance issues or there are just very different ways to measure performance, in other benchmarking it's done very poorly, as other comments below suggest too. I also don't understand why httpparty is so popular. Although it's got some issues (pun intended) in it's maintenance/unclosed issues. I also don't know why these comparisons never include one of my favorites, HTTPClient. I think it comes from the days where there kind of was no good HTTP client so everybody chose something different and didn't trust their choice. I'm not sure how often that's a use case these days. I think the only reason to use faraday is it's actual motivation - to let you "wrap" other http clients, and switch back and forth between differnet clients without changing your calling code. I don't find a quick "do some metrics and write a blog post" super useful in navigating this landscape. Ruby HTTPClient version The first program prints the version of the library and of the Ruby language. sudo gem install httpclient The module is installed with the sudo gem install httpclient command. I wonder if the author has used any of these in real projects over a long term, I think that's pretty invaluable in making recommendation/review, what you've actually run into in real use. Ruby HTTPClient provides methods for accessing Web resources via HTTP.The gem was created by Hiroshi NAKAMURA. It doesn't make sense to me to recommend it based on these kinds of metrics in this article. And you have the complexity/issues/bugs of whatever it wraps, plus it's own. It's performance will surely depend on what it wraps. HTTParty, last time I checked it, was good enough for the "first (easy) 80% of work", but most of them are.įaraday is just a wrapper for other http clients, no? The problem with Faraday is its complicated API for chunked reading (it requires to provide callbacks, while http.rb allows to just body.read(200) and that's it), and a bit of general "messiness" ( config.adapter fault_adapter anyone?.) = HTTPLibrary.new('') and then has a sweet spot with exactly this problem, plus a lot of "battery-included middleware", so (again, for API clients), you can build a sophisticated object with error processing, response parsing, and whatnot, and then just get('/endpoint') and have data ready to consume. I actually like HTTP.rb's API more, but they still can't make a decision about "base URL" API, which is quite valuable for API wrappers, e.g.
For complicated use cases, we (in pany) ended up using Faraday (most of the time), with a fallback to http.rb in some cases.
0 kommentar(er)
