dlesl / erqwest Goto Github PK

Hello, first I would like to congratulate you on the excellent project!
I would also like to know if this project is still active? And is it safe to use it in production?

Pid = spawn(fun() -> erqwest:get(default, <<"https://httpbin.org/delay/10">>) end),
timer:sleep(1000),
exit(Pid, kill).

needs rusterlium/rustler#376

In most applications you probably only need a small fixed number of erqwest:client()s. We could support an api like

ok = erqwest:make_client(named_client, Opts),
{ok, _} = erqwest:get(named_client, Url).

Internally, we could keep track of the corresponding erqwest:client()s in a persistent_term

Hey, how are you?

I intend to publish a Hex package that has erqwest as a dependency but only Hex dependencies can be added to other hex packages.

Could you publish erqwest to Hex so I can submit my library to Hex as well?

What do you think about validating the options passed to make_client/2? I was thinking this could be done in Erlang rather than Rust? Would you prefer a badarg or to change the return value to {ok, Client} | {error, Reason}.

Hi @dlesl !

I'm having a problem getting my application to run on Alpine after I've added the erqwest dependency.

Alpine uses musl and today erqwest is compiled for glibc only. I think you would have to add the x86_64-unknown-linux-musl target to generate the binary in a way that is compatible with alpine linux. It would also have to involve some magic to indicate the target during erqwest compilation.

Do you have any idea how I could get erqwest in a compatible way with Alpine images? Without this affecting local development on Linux using glibc?

Error

error: cannot produce cdylib for `erqwest v0.2.3 (/app/deps/erqwest/native)` as the target `x86_64-unknown-linux-musl` does not support these crate types
make: *** [Makefile:28: compile] Error 101
make: Leaving directory '/app/deps/erqwest/native'
===> Hook for compile failed!

==> spawn_operator
** (Mix) Could not compile dependency :erqwest, "/root/.mix/elixir/1-14/rebar3 bare compile --paths /app/_build/prod/lib/*/ebin" command failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile erqwest", update it with "mix deps.update erqwest" or clean it with "mix deps.clean erqwest"
The command '/bin/sh -c cd spawn_operator/spawn_operator     && mix deps.get     && mix release spawn_operator' returned a non-zero code: 1
make: *** [Makefile:47: build-all-images] Error 1

According to the docs, the limit is around 1 ms. Some quick timer:tc measurements show that erqwest_nif:req is usually below that, but it can take significantly longer once the body starts to get into the megabytes, I guess because it needs to be memcpy'd into a Vec. Same goes for erqwest_nif:send. Some options:

• Mark these nifs as 'dirty' (CPU bound) and be done with it
  • Hurts performance a bit, do we care?
• Copy the terms to an OwnedEnv and parse them on a tokio thread. I've been playing around with this:
  • NIF execution time is now independent of body size (large binaries are refcounted internally so the copy is cheap).
  • Better performance than dirty NIFs
  • It looks like it keeps erqwest_nif:req execution time pretty consistently below 1 ms, when running bench.escript with 5 workers (1 or 2 calls out of ~20000 exceeding 1 ms)
    • Is this acceptable? I assume it is OK for the occasional call to exceed 1 ms, this must be almost unavoidable when the system is at 100% load right?

A panic that occurs after req_async has returned would mean that we never send erqwest_response, causing a deadlock.