Clarification on Roadmap: Backend folder structure follows frontend

[antonycaporossi]

Hi!

I'm currently working on a PR to improve some parts.

Looking at the roadmap, I saw the goal: "Backend folder structure follows frontend"

What do you want to achieve?
Replicating the user-created folder hierarchy from the frontend into the backend uploads/ directory?

Thanks!

[moddroid94]

Hi @antonycaporossi

Yes, the idea was that, but it's quite some work to do i think, right now the folder is just a key in the DB 😅

and thanks to you for the help!

[antonycaporossi]

Hi @moddroid94,
i'm Italian too BTW ahahahah

Using raw folder names (e.g., uploads/Folder Name ?:ì^'/) is highly discouraged for several reasons:

OS Compatibility:
Special characters and spaces can create issues

Collisions:
In a multi-user environment (or even for a single user), having two folders with the same name would be impossible or lead to data overwrites.

Security:
Using raw user input for paths is a major security risk (Path Traversal).

I propose two safer alternatives:

Option A: ID-based Structure (recommended method)
uploads/{folder_id}/{filename}.stl

Pros: 100% unique, no collisions, extremely fast database lookups, ready for multiuser

Routing: Allows using React Router on the frontend (e.g., /folder/:id), enabling browser history and direct links to folders.

Option B: Slug-based Structure
uploads/{folder_slug}/{filename}.stl

Pros: More readable for a human browsing the server files.

Cons: Requires complex slugification and still risks collisions unless a unique suffix is added (like user id for multi user)

Exportability
If a user wants to download their library with the "real" names, we can easily provide a Zip/Export script that reconstructs the folder tree on the fly using the DB metadata. This is much safer than keeping a messy physical structure.

What do you think about moving towards an ID-based storage to support better routing and multi-user scaling?

[moddroid94]

hi @antonycaporossi
i saw ahahah nice to see an italian checking this repo :)

btw, yeah i had the same concerns the first time i thought about it, the ID method may be the only reasonable way to have the direct routing, even if that semi-kills the whole reasoning to switch to this kind of structure.

we can always implement some storage template like in Immich in the future, the sanitization of the strings is feasible, but needs to be thoughtfully built with some checks in the frontend too.

i'll go with the ID way for now, append an uuid to the filename maybe to avoid possible duplicates and we should be good.

about exportability yeah that shouldn't be a problem, we can build the file as we want anyway.

thanks again!

have a good evening :)