Module 13: Creating a Facebook Clone
A social app quickly runs into the question of where media should live. This lesson answers that by introducing a dedicated media entity instead of burying file data inside unrelated objects.
That is the right first step regardless of whether the actual bytes stay in the database forever. Separating media into its own entity means the application can reason about uploads, ownership, visibility, and purpose independently from the records that reference them.
The lesson is also honest about the tradeoff. Storing blobs in a database can be convenient, especially in a simple deployment or clustered environment, but it is not always the final answer. The more durable architectural lesson is that the app should already have a media abstraction, so moving later to object storage or another file service does not require redesigning the whole domain model.
Fields such as filename, timestamp, role, visibility, and owner are doing real work here. They turn the media record from “just bytes” into something the rest of the application can reason about. An avatar image is not the same thing as a post attachment, and visibility rules matter long before the app has every UI feature built.
The DAO stays intentionally simple, which is also a good sign. Media transport should be explicit and predictable rather than full of hidden side effects.