A synchronous http client for rust? [closed]
Asked Answered
B

1

8

I'm looking for a low overhead HTTP client in Rust to create a custom runtime for AWS lambda. All the implementations that I find (including the official runtime from AWS) are based on hyper/tokio and I don't want the overhead nor the added binary weight.

Do you know one ? Is there a reason all frameworks are based on tokio ?

Thanks,

Bettyebettzel answered 16/1, 2019 at 16:42 Comment(7)
the overhead nor the added binary weight — what are you basing this statement on? What does "overhead" mean? What is the "added binary weight" compared to, code that doesn't have HTTP at all?Farfetched
I mean that by adding the whole hyper/tokio dependencies the generated binary grows by a few Mb. The way rust runtime is deployed on AWS lambda mean these few Mb are stored for each function. Regarding the overhead, each AWS lambda container processes only 1 request a time (correct me if I'm wrong on this one), so the whole async system seems overkill...Bettyebettzel
and that’s for a release build?Farfetched
Yes, for a release. The base binary is already 5Mb with the musl standard library, and it grows to around 8Mb with the dependencies.Bettyebettzel
Since this question in its current form appears off-topic, you may wish to look at other resources. More open-ended questions and discussions are welcome on the Rust-Beginners IRC channel, the Rust subreddit, or the Rust users forum. There is also a list of Rust IRC channels on the community page.Farfetched
I felt the question was still valid as I asked for the existence of software meeting a specific criteria, not for a recommendation. Semantics, I guess... Thanks for the interest anyway !Bettyebettzel
I'm afraid that still counts as a request for an off-site resource. Since these questions are harder to stay updated and tend to attract options and spam, they are not suitable for Stack Overflow. Fortunately, there are many other places to ask this, as Shepmaster said.Lambertson
T
9

Is there a reason all frameworks are based on tokio ?

Tokio crate is contributed by many people and maintained by them as well. Since it is developed and maintained well, It is a wise idea to put new crates on top of this base. This is why many libraries are depending Tokio and it's variant/relevant crates.

Since Tokio is based on minimal sub crates like tokio-tcp, tokio-codec , tokio-io, tokio-executor etc. these crates can be imported seperately so your release size will be considerably small.

If you insist on not using any tokio dependency, there are still some options but they will be developed and maintained by relatively less contributor.

Here are some HTTP Client options which are not using Tokio:

There are plenty options apart from these alternatives, but in my opinion I import the minimal tokio relevant crates and implement my application on top of them.

Tutti answered 17/1, 2019 at 18:26 Comment(6)
The question seems like not closed as off-topic? I just wanted to make some suggestions and tried to help if I can.Tutti
Please re-acquaint yourself with the guidelines of Stack Overflow. Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. The question is not yet closed; you should vote to close the question.Farfetched
Thank you very much for taking the time to answer my question. I'll start from there !Bettyebettzel
You may also wish to read Should one advise on off-topic questions?. We do not prohibit assisting the OP with comments, but answering is counter to the goals of the site.Lambertson
Well, okay then. I may try to help from comment section next timeTutti
Thanks @AkinerAlkan. It seems this negative first response from the Stack Overflow community dissuaded you from contributing any other answers. That's too bad, but I don't blame you, it's been an unfriendly place thanks to all its rules for a long time. I appreciate the effort you took in your answer and found it helpful.Playroom

© 2022 - 2024 — McMap. All rights reserved.