Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce library size #81

Open
ianopolous opened this issue Apr 16, 2020 · 7 comments
Open

Reduce library size #81

ianopolous opened this issue Apr 16, 2020 · 7 comments
Labels
help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked

Comments

@ianopolous
Copy link
Member

ianopolous commented Apr 16, 2020

The latest version of this has almost doubled the size to 60mb. This is way too much for a glorified rest client. For comparison the Java S3 client is ~3mb. Is there any way to reduce this by stripping out unused dependencies? Or just including the S3 sdk, and not all of amazon?

@Stebalien
Copy link
Member

Is that compiled size or source code size? We're using amazon's s3 sdk.

@Stebalien Stebalien added kind/enhancement A net-new feature or improvement to an existing feature help wanted Seeking public contribution on this issue labels Apr 16, 2020
@ianopolous
Copy link
Member Author

Compiled size. I've also opened an issue on amazons go sdk about importing only S3 client and dependencies. I'm also referring to Amazon's S3 client. I think the problem here is it's including clients for all of amazon's ~50 services. Not sure why Go isn't stripping out unused components though during compilation.

@ianopolous
Copy link
Member Author

Amazon have replied and they are already working it. Tracking issue here:
aws/aws-sdk-go-v2#444

So I think it's mostly just a matter of waiting for that to be released and importing that sdk instead.

@ianopolous
Copy link
Member Author

ianopolous commented Apr 16, 2020

@Stebalien Is there a size where would you consider including it in ipfs proper, like 3mb say? Or is even that too much to make every user pay. If only we could store the ipfs binary in ipld proper and selectively download the merkle linked modules on demand. :-)

@Stebalien
Copy link
Member

I'll have to think about it. Honestly, go-ipfs is already pretty massive so 3MiB might be acceptable.

We may just want to ship multiple IPFS versions, one with additional supported datastores. Plugins were supposed to solve this issue, but they just don't work reliably.

@ianopolous
Copy link
Member Author

A better solution to this is to just implement our own S3 request signer. It is quite simple (<300 lines of Java). My Java implementation is here:
https://github.com/Peergos/Peergos/blob/master/src/peergos/server/storage/S3Request.java

Then this should be < 1 KiB not 60 MiB, and thus could be included in ipfs directly without requiring a plugin.

@ianopolous
Copy link
Member Author

I've checked that I had implemented all the calls used by this library, and I'd missed bulk delete. So I've added that and the result is still ~ 500 lines of very simple code. Zero dependencies. This would make a good small dev grant target, @momack2.

@aschmahmann aschmahmann added the status/ready Ready to be worked label Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

3 participants