Re: API Image Uploads are ridiculously slow

Just a quick comment here, as we are testing DatoCMS. The platform overall is fantastic, but the API for uploading images (await client.uploads.createFromUrl) is ridiculously slow when compared to other alternatives. We are actually uploading images via the client, sending to a server with FormData and then uploading to DatoCms. The DatoCms API can take nearly 45 seconds to just upload 5 images. By comparison we can upload 30 images with multiple transformations in about 5 seconds with As our web app is very focused on user image uploads and user-generated data, the slow speed of the DataCMS upload API is very concerning. Is there anyway to fix this? Why is it so slow? The only other platform that is comparably slow, and DatoCms is every slower, is Cloudlfare Images which we stopped using.

Hello @osseonews

Could you send us over the URL(s) that are taking that time to be uploaded so we can take a closer look at this?

Thanks, but what do you mean the URLs? These files are uploaded locally from the browser in the app via a serverless function which takes the formData. There are no URLs. The issue is that the API is just very slow to process creates/edits. I’ve found that to be the case, even with basic create/edit, unrelated to images. I’m guessing your API is optimized for read operations, but not mutations? And there is no such thing as a batch insert/update? So you need to hit the API on a single basis for each entry. So for example, if we need to update 100 rows, we need 100 API connections, as opposed to one connection to do a batch update? Is this true?

To clarify the previous post, actually what happens is that we send the formData to an s3 server for the serverless function, and s3 converts the formData image into a temporary URL, which is not accessible publicly and expires within minutes. But we can use that temporary URL to upload the file to DatoCms with the API (our code is below). So there is a URL for the image actually, but it’s temporary. The bottleneck is not the formData, but the API for uploads. We’ve tested it alot, so we are quite confident in this. I’m guessing DatoCms does alot of processing on its end for image uploads? I wouldn’t know. Eventually, all the files do get uploaded. so it works. It’s just very, very slow.


async function uploadImage (url, name) {
          const upload1 = await client.uploads.createFromUrl({
          // remote URL to upload
          url: url, //temporary s3 url
          // if you want, you can specify a different base name for the uploaded file
          filename: name,
          // skip the upload and return an existing resource if it's already present in the Media Area:
          skipCreationIfAlreadyExists: true,
          // be notified about the progress of the operation.
          //onProgress: handleProgress,
          // specify some additional metadata to the upload resource
          author: steps.trigger.event.body.clerkId,
          notes: postData.title
          //copyright: 'New copyright',
        return upload1

@osseonews my colleague was asking for the final assets URLs so that we can try uploading ourselves and checking. Maybe you want to share them via if you prefer.

It might be a performance issue, it shouldn’t be so slow as you have described, we’ll have a look!

Alright, I’ll send over some samples via email. I’m also just curious about the API create/edit response times. We were thinking of using datocms as a backend for an ecommerce store, storing cart data in datocms etc., but it doesn’t seem like this is a good use of the platform, from what I can tell b/c the API response time is quite slow, on a relative basis, in our tests. The create/edit API is much slower than reads, is that correct?

Surely reads are cached and much faster than writes.

Using DatoCMS as a DB for dynamic things linked to a user like a shop cart it might work, but I’m not sure it’s the main use case that we have in mind :slight_smile:

While we are going to improve the asset upload/create time, I’m not sure that it makes sense to store the cart status in the CMS as surely we are not optimized for that. I’ve seen people doing it and it works, but it’s not going to be as fast or optimized as a headless ecommerce solution.