Lessons from Fixing My Video Thumbnail Nightmare in Firebase

How I Refactored My Media Data Model to Save My Sanity
When I started building my Flutter app to track bucket list goals, I structured things in a way that worked—but only for a while.

Each bucket list had its own items, and each item had a list of media files (images or videos) associated with it. These media files weren’t their own objects—they were just stored as a list of URL strings inside each bucket item. Initially, this was fine for displaying content. But as the app grew, so did the pain.

The Breaking Point: Thumbnails and Deletion Logic
The real problem began when I wanted to support video thumbnails.

Because I stored only the video URLs directly in the bucket item, I had no structured place to associate a thumbnail. My “solution” at the time? I created a Map inside the item, where the video URL was the key and the thumbnail URL was the value.

This led to a mess:

• To delete a video, I had to first check if it was a video or image.
• Then, if it was a video, look up its thumbnail URL in the map.
• Then delete the thumbnail, then the video, then update the entire bucket item’s data.

It felt like hacking around the lack of a proper data model.

A Cleaner, More Industry-Standard Design
This change also aligns with the relational modeling I’ve been learning in my Database Administration class. Just like I previously refactored my app so that each BucketItem refers to a BucketList by ID, I’ve now done the same with media and items.

The benefits:

✅ Easier deletions and edits

✅ Cleaner separation of concerns

✅ Better scalability

✅ More intuitive and modular logic

Old Design

New Design

Takeaway
This refactor reminded me that sometimes quick solutions become long-term pain. By modeling media as structured, standalone resources with proper references, I’ve made the app more maintainable and aligned with how real-world systems are designed.

And most importantly? I spend way less time fighting my own code.