Child Item

Image gallery with backend, poor performance

Hello. We are developing a mechanism for importing user files (images, videos) from dropbox into our system.
To view the list of files, our frontend does not interact with the dropbox API directly, instead, it makes calls to the backend, and the backend makes calls to the dropbox.
The page on the frontend is a gallery where the user marks the files he would like to import with checkboxes. We need thumbnails and links to the source file for the detail view.
To display a paginated file list (10 files per page) our backend:
- Requests a paginated list of 10 files files-list_folder - 0.27 sec
- Requests a list of 10 thumbnails files-get_thumbnail_batch - 3 sec for 640*480px
- Requests a temporary link to a file files-get_temporary_link 0.3 sec/each * 10 files = 3 sec

As a result, it turns out that the user is waiting for a response for 7 seconds. We would like to know if we are using the right APIs and how we could improve performance without using embedded components on the frontend.
Our backend is located on AWS Lambda in the us-east-1 region, so we hope this is not a network issue.

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

Thanks for the feedback! As Здравко said, there may some ways to optimize your call pattern, but it would very much depend on your particular scenario, and it sounds like you have certain design constraints to accommodate. As for the Dropbox API itself, you're already using the right endpoints. The /2/files/list_folder[/continue] endpoints are the right way to list the contents of a folder; /2/files/get_thumbnail_batch is the best way to retrieve multiple thumbnails at once; and /2/files/get_temporary_link is the right way to get a direct link for a file, and there isn't a batch version of that available. There isn't any way to just speed up these endpoints, but I'll pass this along as a feature request for various performance/batching improvements. I can't promise if or when any of these might be implemented though.

All comments

Здравко

@serhiisv wrote:
...
The page on the frontend is a gallery where the user marks the files he would like to import with checkboxes. ...
...
- Requests a temporary link to a file files-get_temporary_link 0.3 sec/each * 10 files = 3 sec
...

Hi @serhiisv,

Usually there are ways to optimize the workflow, but this is something very dependent on particular scenarios. In your case, I cannot understand why you are requesting any temporary links while the intended is import - even more import in backend. You just lose 3 secs (according the your calculations) for... nothing. Instead transfer forth and back some links, easier way would be download selected files directly (identified with their IDs - already received in the first step). In such a way you can speed up your procedure almost twice! 😉 Probably other optimizations can be achieved too, taking in mind the proceedings details.

Hope this helps to some extent.

serhiisv

Thanks for the answer.

We need a temporary link so that the user can view the video/image in high quality before importing.

We already have several "adapters" for importing from other platforms that work according to the rules described above. However, other platforms provided a link to the original file and a thumbnail in the "list_folder" request.
This decision was made to remove complex logic on the frontend and standardize all requests/responses to all platforms.

Greg-DB