I clicked on this article because I needed to do something similar this week, and ended up using the JS-based approach. I’ve built something like this with S3 before, but ended up doing it with Google Cloud Storage this time around. The process looked like this:

1) Client-side app receives an image (via drag-and-drop or file picker)

2) Client hits an authenticated endpoint on backend with the name of the file, which returns a “signed URL” (authenticated, with customizable expiration) from Google Cloud Storage

3) (This part is particular to GCS, and I think unneeded for AWS/S3) Hit this signed URL in the client, and receive a final, PUT-able URL

4) Upload the file using the final authenticated URL from Google Cloud Storage

Like I said, I think with AWS/S3 you can just request a signed URL and send data to that URL directly. Delegating as much communication with GCS to the backend was important for my project [1] but you might be able to just manage it with a JS lib.

[1] Streaming music, so trying to abstract the actual files from the client-side as much as possible to discourage downloading the raw audio files

If we want to store the object's URL in a relational database, should the browser send another HTTP request to our service? Wouldn't we lose the object if there's a network error during the interval between the two requests?

Yes, one option is to do as you've described, for example, use JS to upload the file, then submit a form as normal with a file url / id in the form.

However, you can also create a Lambda that is triggered whenever a file is uploaded to a given bucket and directory. With this, you can react to the file being received and update your database without the need for a second request.

s3 requires a signature as well. Without requiring a signature, anyone could upload anything to your s3 account. With a signature, you choose when and where people can put their files.