search

google / go-cloud

The Go Cloud Development Kit (Go CDK): A library and tools for open cloud development in Go.
https://gocloud.dev/
Apache License 2.0
9.56k stars 810 forks source link

blob/Bucket #3451

Closed sandeepvinayak closed 3 months ago

sandeepvinayak commented 3 months ago

Is there a doc reference on the reasoning behind choosing bucket level granularity for portable Api blob/Bucket? Why didn’t we chose the service level portable API such as blob.BlobClient backed by s3client in aws as example. I understand azure have clients at multiple levels such as service client, container client and finally blob client but not sure if this is the reasoning behind the blob.Bucket.

vangent commented 3 months ago

https://github.com/google/go-cloud/blob/master/internal/docs/design.md#developers-and-operators

"The blob.Bucket type is a prime example: the API does not provide a way of creating a new bucket. To properly and safely create such a bucket requires careful consideration, getting something like ACLs wrong could lead to a catastrophic data leak. To generate the ACLs correctly requires modeling of IAM users and roles for each cloud platform, and some way of mapping those users and roles across clouds. While not impossible, the level of complexity and the high likelihood of a leaky abstraction leads us to believe this is not the right direction for the Go CDK.

Instead of adding large amounts of leaky complexity to the Go CDK, we expect the operator role to handle the management of non-portable platform-specific resources. An implementor of the Bucket interface does not need to determine the content type of incoming data, as that is a developer's concern. This separation of concerns allows these two personas to communicate using a shared language while focusing on their respective areas of expertise."

sandeepvinayak commented 3 months ago

@vangent thanks for your response, create bucket can anyway be controlled by not exposing a create bucket method on the portable API. We can still expose only read, write, delete operations on the objects without proving apis for bucket operations. Isn’t it?

vangent commented 3 months ago

Most applications don't deal with the "objects" above a bucket, and there's also not a clear set of functionality that can be abstracted across providers.

Not to say it's impossible, but we chose not to do it (and TBH nobody has asked for it either).

sandeepvinayak commented 3 months ago

Got it! So, I take it as just by choice and there is no real pros/cons other than the fact that the use-case to interact with multiple buckets at the same time is a bit unusual or no one asked for it explicitly.