<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Feb 24, 2016 at 4:49 PM Garrett Smith <<a href="mailto:g@rre.tt" target="_blank">g@rre.tt</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm taking time off from typing -module attributes to focus on my backlog of other important problems...</div><div><br></div>I'm interfacing with various OAuth providers within an Erlang application and I need a simple HTTP client. I've poked around the ecosystem and have learned that HTTP clients are the new MySQL clients in terms of which-one-to-freakin-use.<div><br></div><div>As I'm using this for user auth, memory and performance are considerations, though far behind stability and actual-workingness.</div><div><br></div><div>(In the interest of the later, I'd traditionally wrap OS curl processes because curl is known to actually work, but that _might_ not be feasible as the application grows. Come to think of it, I'm going to start with a curl wrapper and iterate by measuring, so never mind.)</div><div><br></div><div>I'd love to learn from the field experience of others. Is anyone really, really happy with the HTTP client he or she is using for semi-heavy loads like user auth?</div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>Well I would advise hackney of course :) The pool part is completely optional  and it will be gone in the week release anyway. It's used as a large scale in some companies handing millions of connections. It provides you a REST client API, streaming (transparent or not) and so on. </div><div><br></div><div>If you want to do in a minimal way, I extracted the parser in a library:</div><div><a href="https://github.com/benoitc/nplib/blob/master/src/nplib_http.erl" target="_blank">https://github.com/benoitc/nplib/blob/master/src/nplib_http.erl</a><br></div><div><br></div><div>and then uses it with gen_tcp.</div><div><br></div><div>It provides same kind of API than you find with erlang:decode_parser/3 but with less issue. For example decode_parser is not able to parse this:</div><div><a href="https://friendpaste.com/6w5CeBKwYZnMInCRZadlIX" target="_blank">https://friendpaste.com/6w5CeBKwYZnMInCRZadlIX</a><br></div><div><br></div><div>(not sure why yet, investigating it).</div><div><br></div><div>Hope it's useful, any feedback is welcome. I  would be interested to know what your choice at then end and why. I always enjoy to improve hackney when it's possible.</div><div><br></div><div>- benoît</div><div><br></div><div><br></div></div></div></div>