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

khanjan jha — Tue, 18 Nov 2025 15:55:27 +0000

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:

Upload the file directly into the database (ALTHOUGH NOT AN IDEAL WAY).
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

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.

Inside My 3D Car Configurator: Architecture, Challenges, and Lessons Learned

khanjan jha — Sat, 08 Nov 2025 09:57:05 +0000

So this is the very first time i am writing a blog so please don't mind my mistakes.

Part 1: Models

For the models i have downloaded them from SKETCHFAB (https://sketchfab.com/)

As for my project i have downloaded 4 models from there

LESSON

For the react project download the model in gltf or glb format.
As for the size look out for the triangle counts larger the count more time it will take be rendered on the screen

PART 2: Using models in React

As for using the model in your react project u can directly load them through the useGLTF provided by @react-three/drei. This hook will help u load the model in ur browser.

Now for the custom modification for the project i converted the 3d model file into JSX component by GLTF to JSX. And then use that JSX component to make the changes.

LESSON

Its not the best practice to do it.(but i didn't think of any other thing at that time).

PART 3: Optimizing the models

As i have mention earlier the greater the models complexity is the greater the triangle count will be and the greater the count the bigger of the size it will have and to load it for first it is already a very heavy practice and by having a heavy model make things worse.

LESSON
As for my lesson i searched quite some ways to optimize it and the things that i found out was these:

npm install -g @gltf-transform/cli
gltf-transform compress your-file.glb your-file-new-name.glb --draco
this draco command will compress your gltf/glb file quite a bit.
gltf-transform prune your-file.glb your-file-new-name.glb
this command will delete the Unused textures, materials, meshes, nodes.

Though i tried it and it does compress it a lot but beware while compressing the texture it can bring errors.( It did for me)

While also i compressed the big models from 10mb to 2.4mb. (so give them a go).

*AND IF U DONT WANNA DO THIS THEN LEARN BLENDER.

PART 4: Handling the States for the model

Well for simple loading the models is quite simple by just creating a single state and alter the model based on the click at first i also did so but that was not good because later on i have add those custom accessories, scene alteration, color changes and paint type changes and so on. so for that i could have handles it by creating many states for it, but it was not a good approach as i searched around a bit because as the modification grows creating many different states will make the project complex unnecessarily.

like this:

Then i stumble upon "useReducer" that is used for complex state handling (and also a good opportunity to try my hands on it).

LESSON

As the project grow depending on useState can create a clutter so look for better state management.(i used useReducer).
Too much props drilling is also bad as the props changes it load the whole components connected to it weather needed or not. ****

with this setup i can pass around many states in different files and use it for the customization. like this:

Though, I am still doing props drilling its a bad approach to do it cuz as the project grows this can be hectic but for the current scale of my project it was working. (so i didn't think much)

IN SHORT
Switching to useReducer made my state handling much cleaner, scalable, and future-proof as my configurator’s complexity increased.

PART 5: Preloading the models

Now as for the last part about preloading the models so let me explain what it is and what is my thinking behind it. So as for this project while a single model load at a time i think why not pre load the remaining model behind the scene while the user is on the first model i tried to preload the remaining model behind the scene such that it will decrease the loading period.

useGtlf provide a prebuild function names as preload that help loads the model priorly behind the scene. And called it in my main file.

Sooo as for now this mark the end of my blog post about the project. I know there still many amateur practices that i have done but feel free to help me correct it any constructive comments or ideas will be highly appreciated.

Thanks for your attention
GITHUB Link: (https://github.com/jkhanjan/lambo.git))
Live Link: (https://carsimulator.vercel.app/)

DEV Community: khanjan jha

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

Inside My 3D Car Configurator: Architecture, Challenges, and Lessons Learned