A Breakdown of HTTP Clients in Elixir
andrealeopardi.com
A Breakdown of HTTP Clients in Elixir
1–10 of 27 posts
Re: A Breakdown of HTTP Clients in Elixir
#2Informative, as always something top notch from Andrea.
Re: A Breakdown of HTTP Clients in Elixir
#3Is it a bad idea to use Tesla? I’ve got it in my app, but I never know.
Re: A Breakdown of HTTP Clients in Elixir
#4Very cool. Can we see a similar one for HTTP servers?
Re: A Breakdown of HTTP Clients in Elixir
#5This 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.
Re: A Breakdown of HTTP Clients in Elixir
#6Is 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.
Re: A Breakdown of HTTP Clients in Elixir
#7Very cool. Can we see a similar one for HTTP servers ?
https://ash-hq.org/
Have you played with this?
Re: A Breakdown of HTTP Clients in Elixir
#8This 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…
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.
Re: A Breakdown of HTTP Clients in Elixir
#9Is 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.
Re: A Breakdown of HTTP Clients in Elixir
#10Is 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.
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.