Are you planning to share it?
Yes, at least for the default :httpc backend.
I have open it in 2019, but still not solved, and I even got downvoted because of a recent comment I made.
1 Like
If youāre going to question how people spend their free time, you should at least offer to mow their lawn. I mean, itās not surprising youāre getting downvoted. Theyāve offered you code and insight into how they approach a problem - something that is much more valuable than the actual code btw. In return, you offered them an opinion on said code. When they didnāt respond to your opinion in the way you wanted, you criticized them. Youāre being downvoted because you presumed that your opinion was worth more than that maintainers time. If you donāt like Tesla itās really simple: donāt use Tesla. Or fork it and change it to your liking. But donāt assume that because you use a thing it gives you any right to tell people what they do with their projects or their time.
15 Likes
I recently used Finch for a small project wrapping the Hue API. So far I am very happy with the results!
Iāve used HTTPoison, a wrapper around Hackney, for a couple years and found myself wishing for something implemented entirely in Elixir. When on-boarding engineers new to the Elixir ecosystem I received feedback that the Erlang-isms of Hackney presented an additional barrier to entry to engineers already busy with learning Elixir itself. I was excited when Mint was announced, but realized it was a bit low-level for most scenarios, hence my interest in Finch.
@keathley Thank you for your work on Finch! Iām curious to see how Req progresses 
Adding the ability to perform one-line requests like HTTPoison is great for developers new to the ecosystem.
5 Likes
Interesting! I saw something similar on a Ruby project that surprised us when we moved the project to Alpine Linux images and forgot to install curl before deploying 
Did you use the Ports module to handle instrumenting curl itself, or something else?
2 Likes
I think the best way to pick the HTTP client is to start with the requirements. Hereās what my app needs:
- Security,
- Testability,
- Out-of-the box support for various formats,
- Customizability and extensibility,
- Retries,
- Logging.
You might also want to care about:
- Telemetry support,
- High performance,
- Out-of-the box authentication support (like Basic Auth).
I guess you can get all/most of that features with any client, but Tesla gives you a lot of them for free. This is mostly because it was explicitly designed around the idea of swappable adapters and pluggable middleware.
For example, the testing story is great. You could use the provided mock adapter, but you can do even better than that - Tesla defines a simple behaviour for adapters which works great with Mox: define a mock adapter and plug it into your config/test.exs and you can test all the way down to bare-bones HTTP calls.
Customizing Tesla is really important for my use case: I need to log the requests, but they can contain sensitive data in query strings, so I just copy-pasted the provided logging middleware, tweaked it and plugged it into the client.
I also built an adapter that dumps and loads requests from disk which allowed me to built test fixtures that enabled fast and repeatable unit testing and fearless refactoring.
Iām keeping an eye on @wojtekmachās req and I hope it will tick all the boxes.
What Iād love to see though is a unified, agreed-upon interface for HTTP requests/responses which would make swapping HTTP clients easier.
7 Likes
No, I never assume that. My observation is about security of the library not about features to be added or improved.
Once more is about security of the library.
Libraries that are not secure will harm developers using them in good faith, A maintainer that doesnāt have time to keep his library secure should step down from maintaining it or retire it.
Itās not about liking or not of Tesla. On the time I open the issue I was not even using any library, because I was not coding in Elixir.
It is about having secure libraries to their end users, and in my opinion backwards compatibility should not take precedence on secure defaults.
Nowadays I have some pet apps and they use Finch. Thanks for your awesome work on it 
In the BEAM world we could try to create standards for defining this behaviours, like PHP has with PSR standards, that allow any library implementing the PSR Interface for HTTP to be swapped with another one.
Maybe something in the lines of Erlang Enhancement Proposals(EEP) or done as part of it?
Then any HTTP library could adhere to the EEP beahaviour for HTTP and the community would benefit from a unified interface, and the number of concrete implementations would not be an issue, because we could swap them easily in our code.
Sounds like you did it, so why not publish it. Be the change you want to see.
It is a bunch of files scattered throughout a proprietary code base, so I canāt really just take them. There is nothing special about it, it is just a wrapper around curl. Anyone could put up an alpha version in a half hour.
5 Likes
Any of this can I use on a nerves project? in particular I need to request a digest auth service but not sure which of this option is the correct one for the job
