Mint vs Finch vs Gun vs Tesla vs HTTPoison etc

Newcomers better stick with httpoison. Most other clients are targeted to more advanced usage.

In many cases native :httpc could even be enough.

Thanks. I guess you guys interpreted this as “which library should a software noob pick”.
Many newcomers to Elixir are not newcomers to software. Here’s to hoping for a more thoughtful discussion.

It’s hard to tell without having tested and benchmarked each solution.

One criteria could be http client hex.pm’s popularity.

But it depends what You will do with… for simple requests, any should do, but if You are writing a complex web scrapper, You might want to try other plugins.

Usually it’s fine with httpoison, but recently I tried finch, for parallel download from wikimedia. As it is stated in finch homepage, it’s done for performance.

It also uses a dedicated gen_server, while httpoison does not.

I did not try all of them, my need for http client is very basic.

But in case the context is more complex, I might try other.

There is not a simple and single answer to your question, it always depends…

Are You planning to make a web scrapper? What is your use case?

I’ll go ahead and tell you that I use Tesla because it keeps my options open. It’s loosely based on Faraday from Ruby. You just use Tesla and then it has adapters for whatever other client you want it to use under the hood.

https://github.com/teamon/tesla#adapters

Tesla supports multiple HTTP adapter that do the actual HTTP request processing.

• Tesla.Adapter.Httpc - the default, built-in erlang httpc adapter
• Tesla.Adapter.Hackney - hackney, “simple HTTP client in Erlang”
• Tesla.Adapter.Ibrowse - ibrowse, “Erlang HTTP client”
• Tesla.Adapter.Gun - gun, “HTTP/1.1, HTTP/2 and Websocket client for Erlang/OTP”
• Tesla.Adapter.Mint - mint, “Functional HTTP client for Elixir with support for HTTP/1 and HTTP/2”
• Tesla.Adapter.Finch - finch, “An HTTP client with a focus on performance, built on top of Mint and NimblePool.”

When using adapter other than :httpc remember to add it to the dependencies list in mix.exs

Thank you for your thorough answer.

Indeed I guess my question, which I have admittedly not articulated properly, was intended to go more along the lines of:

Which libraries address which use cases ?

And in the process, that would perhaps help understand the fragmentation and also, the differences in implementation (GenServer/library/application). Otherwise I don’t see why so many people would be attacking the same problem.

Our internal service clients are all based on HTTPoison (probably because it was the most popular choice 4 years ago(?)).. but recently inspired by Goth redesign I started refactoring it to allow swapping http_client library “on demand per project” and want to give a shot to Finch in production.

Also impressed by this tweet
https://twitter.com/ChrisKeathley/status/1364692787032113153

I second this. I have had fantastic success with Tesla. When I used Mojito things go really sketchy with services timing out when I would pull info.

I wanted to use Finch because I’ve seen good posts about its performance — and because @keathley is awesome — but sadly for my current work it might not be a good fit because it seems to maintain a pool of open connections.

And in my current projects I need to be very conservative with how much connections I open to commercial API servers because we can get severely throttled and that would be a business disaster.

But I’d go with Tesla with Gun adapter (I used the raw Gun Erlang library and loved it) and then maybe migrate to Finch one day (by tweaking its connecting pool to never keep open connections, if that’s possible),

My $0.02

Let me state up front that I’m the original author of Finch (although at this point I’m by no means the largest contributor to the project). So that’s my bias out of the way. I’ll attempt to give a rundown of the current clients and then explain why I felt like I should try to contribute a new one.

Hackney and httpoison (which is an elixir wrapper around hackney) are probably the oldest and most popular http clients for Elixir. Both are very battle tested and have been used in many production deployments of elixir. Hackney has a lot of features and supports a number of use cases. The main issue with hackney (and thus httpoison) is with how it handles pools of connections. The pools have slowly gotten better over time but hackney is attempting to support a large number of use cases and has defaults that are better in general but worse in high throughput scenarios. If you care about performance, you’ll need to create dedicated pools for each of your hosts, manage which pools you’re using for different calls, etc. This is all doable, but its a chore and error prone. hackney and httpoison don’t support :telemetry, at least last I checked, which also added friction. We used hackney for a very long time at B/R and got a very long way. I’m very appreciative of the work that people have put into those libraries.

Gun is less popular but claimed higher performance than hackney (using default configs) for a long time. That said, its always been a chore to get to work properly because it depends on a non-standard version of cowlib that makes it incompatible with stuff like plug. So getting it working in a standard elixir project is typically difficult. It also didn’t truly support all of the features (websockets comes to mind) that it claimed for a while. Some of this may have changed as I believe there was a new release recently.

Mint is a wrapper around gen_tcp and ssl libraries in erlang that allows you to make http/1.1 and http/2 requests. It does this in a way that mostly hides the underlying socket mechanisms from you. This is useful for building libraries but makes it highly non-ergonomic for general use. You’ll need to build your own pooling mechanism if you want to get performance benefits of long lived connections with http/1.1. http/2 is a highly stateful protocol so you’ll end up needing to implement a lot of logic and functionality on top of the connection to make it work correctly.

Mojito is a pooling solution written around Mint. It uses a novel pool of pools for specific downstreams which tends to provide good utilization of all your connections. The main downside to mojito is that each connection is stored inside of a single process. That means that when you need to make a request, you need to get access to the gen_server, send a request to the gen_server, the gen_server then receives the response, and returns it back to the caller. Whenever you cross a process boundary, the memory must be copied. This means that you’re doing excessive copying to and fro for every single request which increases memory pressure, increases CPU pressure due to excess garbage collection and process rescheduling, and increases your overall latency since the connection can’t be checked back into the pool until the copying has finished.

This brings me to finch. At B/R we were making tens of thousands of http requests per second and were running into errors with misuse of hackney pools. So I spent a bunch of my free time working on a new client that combined mint with a new pool that jose had recently published called nimble pool. Finch stole the idea of a pool of pools from mojito. But instead of using processes to hold each connection, we instead hand the connection itself to the caller (which is possible thanks to mint’s design). This reduces memory, cpu, and decreases latency since we’re no longer copying large binaries across process boundaries. At least, this is true for http/1.1. http/2 is a completely different implementation and I suspect is about as “fast” as any other http/2 implementation. Finch also added support for telemetry spans which was something that we needed at B/R and has made its way into other clients as well. But Finch is brutally focused on being high throughput. This means we don’t support as many features as other clients do because we would have to take them into consideration when dealing with performance goals.

A more pleasant to use API around Finch you should check out GitHub - wojtekmach/req: Req is a batteries-included HTTP client for Elixir. · GitHub. I think this is potentially the right way to handle the various features such as a REST verb API, automatically decompressing responses, retries, etc. that many people have come to expect from a robust client. Definitely watching and chatting with Wojtek about it and excited to see what he does with it.

Something else that I didn’t see mentioned in your original post is chatterbox. This is a http/2 only implementation for both clients and servers. If I was going to support only http/2 that would be what I would use atm.

Tesla is a wrapper around all of these things. I would stick to the hackney adapter or the finch adapter (because of my aforementioned biases). We attempted to use tesla at B/R for a long time but eventually found that it still required more configuration than we wanted to do per project and moved to GitHub - keathley/twirp-elixir: Elixir implementation of the twirp RPC framework · GitHub, backed by finch. But Tesla has a lot of useful middleware and I think its a good library if you only have a few clients to manage.

I’ve never seen simplehttp or katipo so I can’t comment on either of those.