Three Ways to Upload Files: What I Learned While Building My Backend

As i was learning more about the backend tech. I got curious upon some thing HOW EXCTLY ARE WE UPLOADING THE FILE FROM FRONTEND TO BACKEND. Then i went on to see some ways to implement it as follows:

1. Upload the file directly into the database (ALTHOUGH NOT AN IDEAL WAY).

2. Frontend → Backend → Third-Party Storage

means frontend will call the api and backend is still receiving it but instead of storing the file directly into the database it stores it in a service provider in my case IMAGE KIT. Implementation is as follows:

• USER CALLS THE API

• _BACKEND HANDLE IT LIKE THIS _

so then i thought nice this should be the optimal way to handle upload files in backend but no there are some drawback of this also:

backend still acts as the middleman that receives the file. So server load doesn’t actually reduce.
Since your backend handles every file, scaling becomes hard. like bigger file means bigger memory usage.

so then i got to know about a new method which is

1. Frontend → Direct Upload via Presigned URL

In this method, the frontend doesn’t send the file to the backend at all.
Instead, the backend only generates a presigned URL (a temporary, secure upload link) and sends that URL back to the frontend.

The frontend then uploads the file directly to the storage provider using that presigned URL.
Once the upload is successful, the storage provider returns the final file URL, and that URL is what we store in our backend/database. (In my case i used SUPABASE as a service provider).

although the implmentation of this took me a while to understand it implementaion.

• For the first step we have a create a new route for the presigned URL generation. like this

-then

the work of this url is to just create a presigned url when called from backend.

• then from the frontend it will be called like this.

so for the function of this to call the url from the backend for the presigned URL then upload the file into that presigned URL then store that path into the backend.

• then the most painfull part for me was to create the backend of it (although it looks easy but it took me a while to figure it out).

this function helped me generate the presigned url

-then for the service creation part. It goes like this

oh one more thing the url that is stored in the database is not accesible we have to create a seperate function for it to get the publicUrl that will be used in the frontend.

so for me at this point i got exhausted and stopped my thinking there

but let me share the advantage of this loooong implementation:
. Zero Load on Backend for File Uploads as backend is just used to generate the presigned url
. Much Faster Uploads time that will reduce the upload time
. And most of all it is scalable.

• When u create a bucket in supabase make sure to make it public other wise the generated public url will just show BUCKET NOT FOUND (it is silly but it took me a while to figure it out).

so it just didn't end there, there are other ways also but its on me that i felt a little overwhelmed. Althought the scalablity and efficiency of this will be checked when i apply this in real world product.

Anyways if u find any wrong in this please correct me any constructive comment will be highly appreciated.