it's basically a chronological YouTube channel player: Play any YouTube channel from oldest to newest or reverse It remembers your place per channel, Skips watched videos automatically and jumps to the next unwatched one Has a “favourites” view for your go-to channels, A “Bingeworthy” view that ranks channels by how much people binge them (aggregated watch time) and that page sucks right now because it's just populated by my test accounts where i've just added random stuff. It’s or people who discover a great channel and want to watch the entire backlog in order Frontend: Vanilla HTML/CSS/JS (no framework), single-page style, YouTube iframe API for playbackFirebase Web SDK for: Auth (Google + email/password) Firestore for user data (playback progress, favourites, etc.) Backend Firebase Cloud Functions (v2) running on Node 20/24 Firestore as the main DB (users, channels, channels/{id}/videos, etc.) A shared server-side YouTube Data API key (no key in the frontend anymore except for fallback) Cloud Functions: Ingest playback events and update per-user playback/progress Cache channel uploads (video list, metadata) so the frontend doesn’t spam the YouTube API Periodically rebuild an aggregated “Bingeworthy” score per channel based on total watch time & user count The main goal was to minimize YouTube API calls and push as much logic as possible server-side, while keeping the frontend simple.
I’d really appreciate thoughts on stuff like architecture: Does the way I use Firestore collections/subcollections for channels & videos make sense? Any obvious pitfalls with this sort of “cached playlist” approach? I'm really a beginner at this so for those who’ve built stuff on top of the YouTube Data API: any red flags in relying on cached uploads + occasional refresh?
I also notice that my api key is limited to 10000 calls a day, and i hit that yesterday when i stupidly had the search bar call the api key for every keystroke lol please try it with your favourite channel, I’d love to hear if anything breaks.