I have developed a user file system that utilizes Firestore for maintaining file metadata and Cloud Storage for Firebase to store the actual files. Instead of solely relying on Firebase Storage, we opted for this combination to incorporate additional attributes to folders, which could pose challenges since GCS does not support "directories."
Within this system, there are two distinct types of items: directories and files. To streamline Firestore writes, child items do not currently have direct references to their parent directories. Parent directories contain an array with the IDs of each child item, and paths are generated by navigating through the children arrays of each parent. This approach simplifies the process of moving files - essentially, shifting a child ID from one directory's array to another. Otherwise, updating the parent reference for every child during folder movement would be necessary.
The data structure is defined as follows:
interface Directory {
id: string;
entryType: "directory";
name: string;
createdTimestamp?: Timestamp;
modifiedTimestamp?: Timestamp;
owners?: string[];
viewers?: string[];
editors?: string[];
children: string[]; // contains references to File's ID
color: string;
icon: string;
root: boolean;
}
interface File{
id: string;
entryType: "file";
name: string;
createdTimestamp?: Timestamp;
modifiedTimestamp?: Timestamp;
owners?: string[];
viewers?: string[];
editors?: string[];
storagePath: string;
storageBucket: string;
contentType: string;
metadata: Record<string, string>;
}
However, I've noticed that major companies offering drive services tend to include a parent reference for each child item. These companies are less concerned about the overhead of multiple writes, and I have yet to identify any significant shortcomings in this method (aside from minor inconveniences during path construction). So, I'm interested in hearing insights from individuals who may provide reasons for or against adding a parent reference. Thank you!