61–70 of 105 posts
> https://raw.githubusercontent.com/good-lly/s3mini/dev/perfor... It gets slower as the instance gets faster? I'm looking at ops/sec and time/op. How am I misreading this?
[0] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1... [1] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1...
Earlier quoted context omitted.
Can someone explain the advantage of this? If I want S3 access, I can just use NPM If I don't want S3 access, I don't want it integrated into my runtime
Would you rather use an officially maintained solution or some random package by a random author who might abandon the project (or worse)?
This is awesome! Been waiting for something like this to replace the bloated SDK Amazon provides. Important question— is there a pathway to getting signed URLs?
For now, unfortunately, no - no signed URLs are supported. It wasn't my focus (use case), but if you find a simple/minimalistic way to implement it, I can help you with that to integrate it. From my helicopter perspective, it adds extra complexity and size, which could maybe be ideal for a separate fork/project?
Our primary use case is browser-based uploads. You don't want people uploading anything and everything, like the wordpress upload folder. And it's timed, so you don't have to worry about someone recycling the URL.
You know what would be really awesome? Making a fuse-based drop-in replacement for mapping a folder to a bucket, like goofys. Maybe a node.js process can watch files for instance and backup, or even better it can back the folder and not actually take up space on the local machine (except for a cache). https://github.com/kahing/goofys
This seem completely unrelated to the goal of OP's library ?
This is awesome! Been waiting for something like this to replace the bloated SDK Amazon provides. Important question— is there a pathway to getting signed URLs?
I've built an S3 client with similar goals like TFA, but supports pre-signing: https://github.com/nikeee/lean-s3 Pre-signing is about 30 times faster than the AWS SDK and is not async. You can read about why it looks like it does here: https://github.com/nikeee/lean-s3/blob/main/DESIGN_DECISIONS...
Earlier quoted context omitted.
Would you rather use an officially maintained solution or some random package by a random author who might abandon the project (or worse)?
The S3 packages on NPM are maintained by AWS
I'd be surprised if any of your Node projects had less than 100 total deps of which a large number will be maintained by a single person.
See Express for example. 66 total deps with 26 deps relying on a single maintainer.
https://npmgraph.js.org/?q=express
But even in the case of the official aws-sdk they recently deprecated v2. I now need to update all my not-so-old Node projects to work with the newer version. Probably wouldn't have happened if I had used Bun's S3 client.
Earlier quoted context omitted.
In my view one reason is to ensure integrity down the line. You want the checksum of a file to still be the same when you download it maybe years later. If it isn't, you get warned about it. Without the checksum, how will you know for sure? Keep your own database of checksums? :)
If we're talking about bitrot protection, I'm pretty sure S3 would use some form of checksum (such as crc32 or xxhash) on each internal block to facilitate the Reed-Solomon process. If it's verifying whether if it's the same file, you can use the Etag header which is computed server side by S3. Although I don't like this design as it ossifies the checksum algorithm.
Earlier quoted context omitted.
I tried to go this route of using Bun for everything (Bun.serve, Bun.s3 etc), but was forced back to switch back to NodeJS proper and Express/aws-sdk due to Bun not fully implementing Nodes APIs.
What were the most significant missing bits?