A Breakdown of HTTP Clients in Elixir | Hacker News Reader

A Breakdown of HTTP Clients in Elixir

andrealeopardi.com

163 pointsclessg24 comments

This is a wonderful summary but I'm struck with how these things all seem unnecessarily complicated compared to Python' requests, Apache Commons clients, curl based libraries... I get that a lot of magic also comes from the Erlang resilience, and maybe the functional composing is certainly interesting, but JavaScripts and Clojure and arguably you could do this with anything with promises... Anyway.

This sounds great in the sense that many of the issues I've had with those other platforms also have consideration here, but I guess my real question is:

Are http(s) requests always going to be bespoke and have application specific considerations? It also seems we can't escape having to know all of the layers ultimately, the socket, TLS, etc sometimes for even the most basic of http use cases. I feel like we don't have to do this for... Many other protocols.

I believe `req` borrows inspiration from `requests` and applies a functional approach. Maybe it will become a similar standard in the community? The idea then is that you have the high-level library but the building blocks are available for low-level control.

You have a good point about HTTP though and I am not sure if it will improve given 1.1, 2.0, and 3.0 all imply different trade-offs as well.

I realized that I needed to know way more about HTTP than I wanted to when trying to write a bunch of API wrappers for crypto exchanges. There’s just… a lot of failure modes and the application needs to respond differently to each. Some failures just need a quick retry while others must be pushed all the way back to a client to decide what to do.

Is it a bad idea to use Tesla? I’ve got it in my app, but I never know.

I'm also curious why Tesla doesn't get mentioned in here, particularly because I'd argue that Tesla is at a similar abstraction level to Req.

Tesla is definitely fine to use! In my opinion it relies too much on module-based composition/configuration. In this aspect Req is more functional and less setup-y.

Ahhhh. I can absolutely see that. I’ve got two similar, but slightly different Tesla clients, and it required two separate modules because of the “assemblage”, but can see how Req could have piped easier, probably allowing me to use only one client instead of two.

Came here to say this as well! Tesla was my library of choice for setting up dozens of crypto exchange API wrappers while minimizing the repeated boilerplate for each.

For the same reasons that the author dislikes Tesla, I prefer it :D

To clarify: it's the same reason that I like plug.

I love Tesla. The fact that it comes with various adapters makes it super easy to configure and extend. It also comes with its own mock module, so testing requests is a breeze as well.

I've used HTTPoison, Tesla and more recently Req for a thin Firebase client.

I guess they all work.

I remember at some point HTTPoison & hackney were finicky with SSL certificate validation. But AFAIK HTTPoison is the only one that can do async requests to process chunks? [0]

[0] https://www.poeticoding.com/download-large-files-with-httpoi...

See: https://gist.github.com/zachallaun/88aed2a0cef0aed6d68dcc7c1... and work underway here: https://github.com/wojtekmach/req/issues/82#issuecomment-154...

Good to know, thanks.

HTTPoison seems to have unresolved issues with connection pooling, where your connection gets closed by the remote server under some conditions - like if you are making a large number of one off calls to different servers and are using the default connection pool. I don’t have much experience with the others mentioned in the article.

Informative, as always something top notch from Andrea.

I use Mint directly. Maybe I made the wrong choice. Maybe I didn't. I tried to use Finch. Our application issues webhook updates from various devices to arbitrarily run time configured endpoints. And the devices come and go at run time as well. So I found the connection pooling of Finch just fought me and frequently produced errors I didn't understand.

Using Mint was definitely "more work" to handle all of the streamed updates of the the response, but in the end, it has worked really well for me. The documentation for Mint is really good IMO.

This was great, selfishly I really wish we had an up to date comparison of HTTP clients like this but for Clojure.

I found Tesla mock capabilities for testing buggy. Req exposes an adapter interface that facilitates similar functionality. I think I'll try Req next.

Very cool. Can we see a similar one for HTTP servers?

https://ash-hq.org/

Have you played with this?

takes note

Rather than post a top-level comment, I'll just tell you here that your content is _so good_ and I really appreciate what you're doing.

I only know Cowboy and Bandit right now.

Reply on news.ycombinator.com