#amazon-s3 #s3 #client #aws #connection-pool #tokio #async

s3-simple

simple, fast and efficient s3 client for bucket operations

6 releases (3 breaking)

0.4.1 Oct 31, 2024
0.4.0 Jul 20, 2024
0.3.0 Apr 17, 2024
0.2.0 Apr 12, 2024
0.1.1 Apr 12, 2024

#1341 in Network programming

Download history 76/week @ 2024-08-21 166/week @ 2024-08-28 92/week @ 2024-09-04 94/week @ 2024-09-11 115/week @ 2024-09-18 112/week @ 2024-09-25 84/week @ 2024-10-02 83/week @ 2024-10-09 80/week @ 2024-10-16 77/week @ 2024-10-23 261/week @ 2024-10-30 205/week @ 2024-11-06 176/week @ 2024-11-13 140/week @ 2024-11-20 147/week @ 2024-11-27 107/week @ 2024-12-04

601 downloads per month
Used in 2 crates (via cryptr)

Apache-2.0

82KB
1.5K SLoC

s3-simple

simple, fast and efficient s3 client for bucket operations

Why?

Why another s3 client crate? Well, there are a lot of them out there, a lot of them are unmaintained, a lot of them have flaws, a lot of them come with lots of dependencies.

Most often, you need your bucket CRUD operations, that's it.
This crate has been created out of the need for an efficient solution, that does not eat up all your memory for large files while being as fast as possible.
Quite a bit of code from the rust-s3 crate has been reused, especially for the headers signature. There was no need reinvent the wheel. What it does differently, it only works with async, it has a fixed, built-in request backend (reqwest) with connection pooling and it does not provide (and never will) all possible S3 API actions.

I tried quite a few different s3 client crates and was not fully happy with any of them so far. There were pretty good ones, like rusty-s3, but I don't like using pre-signed URLs, when I don't need to, for security reasons. Yes, you cannot guess a URL with random parts, but they get logged in lots of places where you can simply read them.
Other crates had the problem, that they re-created a new client for each single request, which means new TLS handshakes for each object, even if its only 200 bytes big, which was a huge overhead. And then others again try to buffer files of any size fully in memory before writing a single byte to disk, which OOM killed my applications a few times, since they are often running on not that powerful big servers.

What it offers

  • fast, efficient, minimal client
  • internal connection pooling with reqwest
  • streaming without eating up your memory
  • incomplete S3 API on purpose to reduce complexity
  • only accepts connections via access key and secret
  • the following currently implemented operations:
    • HEAD object for metadata
    • GET object - S3Response is a wrapper around reqwest::Response, so you can decide yourself if you want it in-memory or convert it to a stream
    • GET object range for partial downloads
    • DELETE an object
    • PUT an object (direct upload)
    • PUT streaming from any source that implements AsyncRead
    • list bucket contents
    • S3 internal copy of objects
  • all operations are tested against Minio and Garage

How to use it

Take a look at the examples, but basically:

let bucket = Bucket::try_from_env()?;

// upload
bucket.put("test.txt", b"Hello S3").await?;

// get it back
let res = bucket.get("test.txt").await?;
// no manual status code checking necessary,
// any non-success will return an S3Error
let body = res.bytes().await?;
assert_eq!(body.as_ref(), b"Hello S3");

Dependencies

~10–22MB
~329K SLoC