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

Convert deno_s3 into an aws monorepo #43

Open
c4spar opened this issue Nov 14, 2021 · 2 comments
Open

Convert deno_s3 into an aws monorepo #43

c4spar opened this issue Nov 14, 2021 · 2 comments

Comments

@c4spar
Copy link
Contributor

c4spar commented Nov 14, 2021

Hi,

After opening several PR's and already working on another PR to implement bucket replication, I was wondering if it would make sense to turn this repo into a monorepo so we can add api's for services other than s3.
For example, for bucket replication I need to create an iam role and a role policy, so it would be nice to have an iam module as well.
And with a monorepo, we have the advantage of being able to easily share things between all modules. We could also move deno_aws_sign_v4 and deno_sqs to this repo.

My first idea was to create a subfolder for each module and publish each subfolder as a separate module on deno.land, so that each existing module can still keep its current module name. But I think this way we can't share files between modules with local imports.

Another option would be to publish the monorepo as a single module. But we would have to rename the s3 module to deno_aws or something else. I think aws is no longer available.

What do you think @lucacasonato about converting this repo to a monorepo?

@lucacasonato
Copy link
Owner

I think if we were to do this, it would be good to built on top of https://aws-api.deno.dev/. That does all the low level AWS interactions, and we would just maintain the high level nice API.

@c4spar
Copy link
Contributor Author

c4spar commented Nov 15, 2021

We could do that as well. But not sure how stable this library is.
One thing is that we currently use camelcase everywhere and the generated library uses pascalcase, so we would have to map all the responses if we want to keep using camelcase. But yes, it can still save us some work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants