🚀 Feature: Get File Download Link Based On Storage Adaptor

[iamdineshkumar]

🔖 Feature description

At this moment, if client need to download a file it can be done through Appwrite instance only even though files are stored in remote location like S3 bucket. I can understand that Appwrite provide lot of feature on top of it but this may leads to give over load with traffic to appwrite instance since it reads the file from remote bucket and returning data to client which also increase bandwidth utilization in case of large files. I would like to explain this scenario with use case:
In case we develop a social media app and in which we are allowing user to upload video contents and other users can stream view those. In present scenario if appwrite instance read file and return to client means then it leads to massive amount of resource utilization this also leads to an situation we are not using competative advantage of content distribution of S3 bucket as well as we are going to doubly charged for bandwidth utilization(S3 bucket as well as for instance of appwrite)

🎤 Pitch

We can provide separate endpoint to get download link in which if storage provider support URL generation then we can return generated URL based on provider else we can return default download link of appwrite(this also applicable in case local storage is used).

This will provide option to utilize all existing features of appwrite as well as it also provide option to return download link of storage provider to client. So all traffic will be handled by storage provider and not appwrite.

👀 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

[p4-k4]

Just adding some points that I've already mentioned in Discord but I feel are still relevant and further support @iamdineshkumar's points.

We hear or see that Appwrite "supports" this or that storage provider only to find out that it's not supported in the way that most would assume. Although I appreciate that Appwrite tries to provide a single common interface/consistency and cool features built into it's storage service ,at minimum I would like to see more options that take advantage of what 3rd party providers API's offer.

Let's face it, keeping data close to our Appwrite instance is not always cost effective with competitive storage options provided by the likes of Google and Amazon and nor would it be practical to in cases that geographical distribution matters. Not only this but I'd imagine a decent chunk of Appwrite users develop on flutter of which is mobile dominant - In that case, geographical distribution definitely matters and it would become counter-intuitive to double handle data. We've essentially undone some money and performance saving when a client could speak directly to the provider.

Or at least, having the option to choose from whom the data comes from/whether Appwrite cache's that data as raw data (or metadata) would solve that problem.

[iamdineshkumar]

@p4-k4 We are not going to loose file permission related feature since link will be genreated and return when user have necessary rights.

As well as at this moment file can be downloaded using end point like below
/v1/storage/buckets/:bucketId/files/:fileId/download
we can introduce new end point like
/v1/storage/buckets/:bucketId/files/:fileId/link

So that it will return download link only if user is permitted to access that file as well as some providers provide file link expiry aslo which will be another advantage so that user can't copy the link to have permanent access to it.

[stnguyen90]

Thank you for raising this issue! 🙏 We’ll dig into this and get back to you as soon as we can. 😊

[iamdineshkumar]

Based on discussion in discord, S3 file URL can be provided in metadata of a file.
At present appwrite have endpoint to get metadata of file as below
/v1/storage/buckets/{bucketId}/files/{fileId}
This endpoint return value with file URL. For making it as standard we can include file URL for all, if its S3 adapter S3 file URL can be included or else appwrite URL can be returned. So developer no need to worry about which adapter is used
@Meldiron

[iamdineshkumar]

@stnguyen90 @Meldiron @eldadfux While returning S3 file url it would be great if url are generated with expiry for an example 2 hours. This will also indirectly enforces security of a file since only user with access to file can get meta data from appwrite and those link also have expiry time which secure the file from accessing it later(In case of web apps its easy to get url of file or even right click to open image in new tab).

[PavieOlivier]

any update on this @stnguyen90 ?
@shimonewman ?

[stnguyen90]

@PavieOlivier, we've been busy with other requests at the moment so we don't have any update on this.