cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Whether you want to work on being more organized, your productivity or you want to use AI to make your life easier, we’ve got something for you right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Image gallery with backend, poor performance

Image gallery with backend, poor performance

serhiisv
Explorer | Level 3
Go to solution

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.

1 Accepted Solution

Accepted Solutions

Greg-DB
Dropbox Staff
Go to solution

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.

View solution in original post

3 Replies 3

Здравко
Legendary | Level 20
Go to solution

@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
Explorer | Level 3
Go to solution

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
Dropbox Staff
Go to solution

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.

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Greg-DB Dropbox Staff
  • User avatar
    serhiisv Explorer | Level 3
  • User avatar
    Здравко Legendary | Level 20
What do Dropbox user levels mean?