3 ms·
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 b
by th0ma5 3y ago
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.
- josevalim 3y agoI 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.
- jkhdigital 3y agoI 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.