🚀 Feature: Implement a generic S3 adapter

[brocococonut]

🔖 Feature description

A generic S3 adapter not dissimilar from what's already implemented. The main difference would be a more easily customizable host option, and a toggle for using path based buckets and subdomain based buckets as not all S3 compatible servers use one over the other (Path deprecation notice)

🎤 Pitch

Creating a generic adapter would allow the use of multiple different providers without having to create an adapter for each. (e.g. Digital Ocean Spaces, AWS S3, MinIO, Backblaze, etc.)
This would allow for upstream projects (i.e. appwrite) to allow user customizable storage locations set to any S3 API compliant service instead of being vendor-locked to one specific.

This would also satiate #25's requirements.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

Adding some references for how to use the AWS CLI with S3-compatible providers:

1. Backblaze
   • uses endpoint URL for region and path for bucket
   • bucketname in endpoint should also be supported
2. Wasabi
   • uses endpoint URL for region and path for bucket
   • does also support virtual-style requests according to the API Guide
3. Cloudflare
   • uses endpoint URL for region and path for bucket
   • virtual-style is also supported
4. MinIO
   • uses endpoint URL for region and path for bucket
   • virtual-style is also supported
5. DigitalOcean
   • uses endpoint URL for region and path for bucket
   • virtual-style is also supported

[haymaker]

I might be able to work on this as generic S3-comptabile functionality is something I'd like to see in appwrite. I've already provided #75 which addresses #37 for MinIO as that's a current need I had - but if you have any guidance on how you'd like to see this implemented it would definitely be appreciated.

[stnguyen90]

@haymaker it would be good to create a new adapter for now so we don't interfere with the others. Have you used the S3 CLI tool (or something similar) with a S3 compatible provider?

[haymaker]

I have, just not in the context of doing so for significant testing against any particular provider.

Would you prefer a generic adapter that extends the current S3 adapter and implements a URI-style parameter for the endpoint variable via method overloading? This seems like the better approach as it would cover providers that use either the host/bucket or subdomain schemes while limiting code duplication.

[stnguyen90]

@haymaker, just like how you use the S3 CLI tool with the other S3 compatible providers, I think it would be good for the adapter to behave the same way.

[haymaker]

FYI @stnguyen90 - PR #76 is open to address this :-)

[haymaker]

@stnguyen90 - are there any issues I need to address with this?

[Sokratesli]

Please add Ionos S3 adapter as well, thank you.