Originally, we created a separate prompts subcollection for IP reasons (minimize the risks that these leak).
However, since we now have the separation landing / serving, that landing is never public (and will likely never be), and we can control very precisely which data end up in serving, we could put the prompts as attributes of the parts subcollection.
Note: could this be done for images as well?
There is a 1 MB limit per Firestore document, but the story part text + prompts are not going to make much of a difference, so that's not a valid argument.
The only argument I see is we cannot just give the ID of a single image to the two parts.
But types in Firestore are flexible, so we could just have image: Byte | string, and if it's a string, it's the ID of another part to which we should refer to get the image.
Anyway, this is not a use-case today (one image, several parts).
For both prompts and images, doing this refactoring would give a code easier to read and fewer costs (since we only retrieve one document).
Originally, we created a separate
promptssubcollection for IP reasons (minimize the risks that these leak). However, since we now have the separationlanding/serving, thatlandingis never public (and will likely never be), and we can control very precisely which data end up inserving, we could put the prompts as attributes of thepartssubcollection.Note: could this be done for images as well?
image: Byte | string, and if it's a string, it's the ID of another part to which we should refer to get the image.For both prompts and images, doing this refactoring would give a code easier to read and fewer costs (since we only retrieve one document).