-
Notifications
You must be signed in to change notification settings - Fork 29
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
Replace clients host
and scheme
properties to cater to S3-Compatible backends
#61
Conversation
Hi @Schachte, and @w0rd-driven 👋🏻 Just a heads-up that I believe this PR should help address your recent issues interoperating with Cloudflare R2 and Digital Ocean spaces. Could you take it out for a spin, and let me know how it goes? 🙏🏻 Thank you! 🙇🏻 |
Awesome work! I'll review this guy today. One callout without actually having dug too deep yet, was this comment:
I can browse to see if that is problematic as the example above prefixes with Edit: Oh 🤦 , took a quick peek at your refactor and see endpoint is taking precedence 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thanks for the fast follow-up. Left just a couple nits.
What?
This Pull Request is massive, but it does a single thing: replace the existing
AWSClient.host
andAWSClient.scheme
properties with a singleendpoint
property both on theAWSClient
, and theAWSConfig
.This Pull Request adds an option to
AWSConfig
:In the ☝🏻 example, every request will now be sent to
https://fra1.digitaloceanspaces.com
instead ofhttps://amazonaws.com
.Why?
This is an attempt to replicate the constructs in the node AWS SDK, as discussed in #57, and expose an
endpoint
property. Using this property, users can now indicate to the client classes instances via theAWSConfig.endpoint
property or by setting it directly on the client the actual URL endpoint it should use to talk to AWS.The reason for that is to cater to AWS-compatible services and stacks, such as in #21 #57 #50, and allow for a nicer integration of the SDK with services such as DigitalOcean spaces and Cloudflare R2 offer S3-compatible APIs or with Localstack, for instance.
This feature does not mean that we officially support alternative S3-compatible APIs, but it should offer the possibility to whoever needs to use it to do so at their own risk.