feat(connect): storage.upload
and storage.download
should attempt to use signed urls, if possible
#526
Labels
storage.upload
and storage.download
should attempt to use signed urls, if possible
#526
As an engineer maintaining the hyper cloud platform,
I would the like the
hyper-connect
SDK to use thesignedUrl
flow forstorage.upload
andstorage.download
, whenever possibleso that load can be distributed off of the hyper service and instead be placed directly on wrapped services.
Background
Files can be uploaded and downloaded directly using hyper OSS and hyper cloud.
file serving can be considerable load on the system, especially with large files being uploaded or downloaded.
Hyper Storage adapters may implement the
useSignedUrl
flow for bothgetObject
andputObject
, which returns a presigned url that the consumer can then interact with, directly.hyper-connect
being a consumer, we would like it to use thissignedUrl
flow whenever possible, to reduce load put onto the actual hyper system, as is one of the use cases for thesignedUrl
flow.for
upload
anddownload
hyper-connect
should attempt to first obtain a presigned url from hyper, for each flow, respectively. If hyper-connect is not able to obtain a presigned url ie. the adapter doesn't support presigned url flow (probably should be a status code for this) ie. a local-only adapter, thenhyper-connect
should transparently fallback to using the regularupload
anddownload
directly through hyper.The text was updated successfully, but these errors were encountered: