DEV Community: Focss

YouTube Playlist to a 100% Static

Focss — Tue, 18 Aug 2026 06:55:04 +0000

Every so often you find a mobile game you enjoy but can't finish. Food Hunt is one of those match-3-style puzzle games where you clear colored tiles by tapping — and the difficulty climbs fast. The content lives on YouTube as a long playlist of level-by-level walkthrough videos, one video per level, each titled Food Hunt level N walkthrough solution.

I wanted to turn that playlist into a proper website: a place where players can search, filter, and jump straight to the exact level they're stuck on, with an embedded video, a difficulty label, and even adjacent-level navigation.

What I didn't want: a slow CMS, a monthly server bill, or a fragile scraper that breaks every time a video title changes.

The result is Food Hunt — a site serving 585 level pages, generated entirely at build time, deployed on Cloudflare's edge, with content refreshed weekly by an automated pipeline. No web server, no runtime database connection, no per-page API calls.

Here's the full technical breakdown: the data pipeline, the static frontend, and the SEO machinery — including the patterns I'd reuse (or avoid) next time.

System architecture

flowchart LR
    YT[YouTube Playlist<br/>Food Hunt level N walkthrough] --> CRAWL[yt-dlp<br/>extract_flat metadata]
    CRAWL --> VIDEO[JSON: video links + level numbers<br/>regex-parsed from titles]
    VIDEO --> THUMB[Thumbnail download<br/>i.ytimg.com, concurrent]
    THUMB --> WEBP[Pillow → WebP]
    WEBP --> R2[Cloudflare R2<br/>img.mobilecasualgames.com]
    CRAWL --> DB[(Neon Postgres<br/>serverless)]
    DB --> SNAP[Build-time snapshot<br/>download-data.mjs → JSON]
    SNAP --> NEXT[Next.js static export<br/>generateStaticParams]
    NEXT --> SEO[sitemap.xml + robots.txt<br/>IndexNow submission]
    SEO --> PAGES[Cloudflare Pages<br/>global edge]
    PAGES --> USR[Visitors]
    R2 --> USR

The whole thing is a one-way data flow:

Python pipeline (runs weekly) pulls the YouTube playlist, parses it, downloads thumbnails, uploads them to R2, and upserts records into Neon.
Build step (runs on deploy) downloads the database into local JSON snapshots.
Next.js statically generates every page from those snapshots and emits sitemaps.
Cloudflare Pages serves the exported out/ directory from the edge.

Let me walk through each layer.

Part 1: The data pipeline (Python)

The source of truth is a YouTube playlist. I used yt-dlp with extract_flat — which returns playlist metadata without downloading any video, making it fast and cheap:

ydl_opts = {"quiet": True, "no_warnings": True, "extract_flat": "in_playlist"}
with yt_dlp.YoutubeDL(ydl_opts) as ydl:
    data = ydl.extract_info(config.PLAYLIST_URL, download=False)

Parsing structure from video titles

The playlist is a flat list of videos; the only structure is encoded in the titles (Food Hunt level 1, Food Hunt level 2, ...). So the "schema" is a pair of regexes. I classify every entry into three buckets — single level, level range, or unknown:

def parse_entry(title):
    """Returns (kind, level_or_None, start_or_None, end_or_None)"""
    t = title or ""
    m = re.search(config.RANGE_REGEX, t, re.IGNORECASE)
    if m:
        return "range", None, int(m.group(1)), int(m.group(2))
    m = re.search(config.LEVEL_REGEX, t, re.IGNORECASE)
    if m:
        return "single", int(m.group(1)), None, None
    return "unknown", None, None, None

Two details worth copying:

unknown is a first-class bucket. Unparseable titles (private videos, renamed videos) don't crash the pipeline — they land in a report you can eyeball.
Video IDs are extracted defensively from multiple URL formats (?v=, youtu.be/, /embed/), because playlist entries don't always use the same URL shape.

Thumbnails: concurrent download + WebP

Each level page needs an image. YouTube serves thumbnails at i.ytimg.com/vi/<id>/..., so I download them concurrently with a ThreadPoolExecutor, then convert everything to WebP with Pillow:

from concurrent.futures import ThreadPoolExecutor, as_completed

with ThreadPoolExecutor(max_workers=8) as pool:
    futures = {pool.submit(fetch_one, v): v for v in videos}
    for fut in as_completed(futures):
        # save {index:03d}_{video_id}.png → .webp

Why WebP? It's typically 25–35% smaller than PNG for these screenshot-style thumbnails, and the site is configured to only emit WebP anyway.

Storage: Cloudflare R2 + Neon Postgres

Two storage targets, two very different access patterns:

Images → Cloudflare R2. Uploaded with boto3 (R2 speaks the S3 API), and served through the CDN domain img.mobilecasualgames.com. The upload step is idempotent: it skips objects that already exist, so re-running the pipeline never re-uploads 585 images.
Records → Neon. A serverless Postgres database accessed with psycopg2. There are three tables: games (game metadata), game_levels (one row per level + video), and game_guides (auto-generated walkthrough text + FAQ content).

The pattern that saved me: incremental merge

The pipeline's most important rule is:

Existing levels are never overwritten. Only missing levels are added.

The script reads the levels already in the database, then upserts only the ones that don't exist yet:

existing = sn.read_existing_levels(game_name)   # from Neon
missing = [lv for lv in parsed_levels if lv["level"] not in existing]

for level in missing:
    sn.upsert_level(game_name, level)           # INSERT ... ON CONFLICT DO NOTHING

Why does this matter?

Video titles occasionally change or get removed. Re-running the crawl must not silently clobber a previously correct record.
The YouTube playlist is append-only in practice — new levels get added at the end. So the diff is almost always new_levels = all_levels - existing, which is exactly the merge behavior you want.
It makes the pipeline safe to run weekly, unattended, which is what the automation is built for.

Automation

Everything above runs on a schedule (a weekly cron in my case): crawl → download → integrate → rebuild the site. Because each step is idempotent and produces a JSON report, a failed run can be re-run without any manual cleanup.

Part 2: The frontend (Next.js)

The site itself is deliberately boring in the best way. Next.js 14 (App Router) + TypeScript + Tailwind CSS, with one crucial setting:

// next.config.mjs
const nextConfig = {
  output: "export",      // no Node server — emit pure static HTML
  images: {
    unoptimized: true,   // static export can't use the image optimizer at runtime
    formats: ["image/webp"],
  },
};

Build-time data, not runtime data

There is no database connection and no API at runtime. Instead, a small script (download-data.mjs, using the postgres package) pulls the whole dataset from Neon into versioned JSON snapshots:

src/data/
├── games.json     # game metadata
└── levels.json    # 585 levels: id, name, image, videoId, embedUrl, watchUrl

Then the data layer (levels.ts) reads those JSON files directly. This is the key trade-off: you trade real-time data for zero runtime cost and instant scaling. For a walkthrough site that updates weekly, that's the right trade.

A nice side effect: the data snapshot lives in the repo, so deploys are reproducible and the build fails loudly if the data is malformed.

One static page per level

Every level gets its own URL (/levels/1, /levels/2, ...) via generateStaticParams, and its own <head> via generateMetadata:

export function generateStaticParams() {
  return levelsData.levels.map((l) => ({ id: String(l.id) }));
}

export async function generateMetadata({ params }) {
  const level = await getLevel(Number((await params).id));
  return {
    title: `Food Hunt ${level.name} Walkthrough`,
    description: `Watch the full video walkthrough for ${level.name}. ${level.difficulty} strategy...`,
    alternates: { canonical: `/levels/${level.id}` },
    openGraph: {
      type: "video.other",
      url: absoluteUrl(`/levels/${level.id}`),
      videos: [{ url: level.watchUrl, type: "text/html", width: 1280, height: 720 }],
    },
    twitter: { card: "summary_large_image", images: [level.image] },
  };
}

Because output: "export" produces plain HTML files, every one of the 585 pages is a crawlable, indexable, fast-loading static document — no client-side rendering wall between Googlebot and the content.

A few component-level details I'm happy with:

YouTubeEmbed — a wrapper around the standard iframe embed, with lazy loading and a consistent 16:9 aspect ratio.
LevelsBrowser — a client component that does search + difficulty filter + pagination entirely in the browser over the preloaded JSON.
Adjacent-level navigation — every level page links to the previous/next level, which is both good UX and good internal linking for SEO.

Part 3: SEO & operations

For a content site whose entire purpose is being found on Google for queries like "food hunt level 240 walkthrough", SEO isn't an afterthought — it's the product.

sitemap.xml: generated, but never destructive

sitemap.xml is generated from the data snapshot — but with a merge rule I wish more tools had:

Static pages (/, /levels, /download) and level pages (/levels/\d+) are regenerated from the data.
Everything else (blog posts, custom landing pages) is preserved verbatim from the existing sitemap.

// generate-seo.mjs (simplified)
const existing = parseExistingSitemap("public/sitemap.xml");
const staticUrls = buildStaticUrls();          // from levels.json
const customUrls = existing.filter(u => !isStaticOrLevel(u));
const merged = [...staticUrls, ...customUrls];
writeSitemap(merged);

This means the sitemap script is safe to run on every deploy — it will never wipe out manually added URLs. That's the same philosophy as the database merge, applied one layer up.

robots.txt + IndexNow

robots.txt is generated alongside the sitemap into public/.
After each deploy, an IndexNow submission script pings search engines (Bing, Yandex) with the updated URL list, so new levels get indexed quickly instead of waiting for the next natural crawl.

Deployment: Cloudflare Pages

With output: "export", the out/ directory is a fully static site. Deploying is just a matter of pointing Cloudflare Pages at it:

// wrangler.jsonc
{
  "name": "foodhunt",
  "assets": { "directory": "./out", "not_found_handling": "404-page" }
}

You get global CDN caching, HTTPS, and zero infrastructure to maintain — the site is just files.

What I'd do differently next time

A few honest takeaways from building this:

Don't trust playlist order. I initially assumed playlist order == level order. It isn't always — the regex-parsed level number is the only reliable key. Always parse and validate.
Idempotency is non-negotiable for automation. Every step (download, upload, upsert, sitemap) must be safe to run twice. This single property is what makes unattended weekly runs possible.
Static export changes image strategy. With output: "export" you lose next/image's on-demand optimizer, so pre-optimizing to WebP in the pipeline was the right call — do image optimization upstream, not at runtime.
Metadata is code, treat it that way. Per-page generateMetadata gives you canonical URLs, Open Graph video cards, and Twitter cards for free — it's the highest-leverage SEO work in a Next.js project.

Try it out

If you're stuck on a level of Food Hunt (or just curious to see 585 static pages in the wild), check out food-hunt.org — search for your level, watch the walkthrough, and move on.

The stack in one line: Python + yt-dlp → Cloudflare R2 + Neon Postgres → Next.js static export → Cloudflare Pages, held together by idempotent, incremental, fully automated data flows.

If you're building something similar — a content site from a semi-structured source — I hope the merge-don't-overwrite pattern and the build-time-snapshot trick save you a few late nights.

Finding Pixel Flow levels with a 768-bit RGB pHash visual search

Focss — Thu, 02 Apr 2026 06:47:36 +0000

I’m a big fan of the game Pixel Flow, but I often find myself getting completely stuck on specific levels. Because it is a purely visual grid game, you cannot simply search for a solution using text. To solve this, I built a reverse image search engine specifically designed to find level solutions based on a screenshot.

The challenge was figuring out how to do image matching quickly, accurately, and without heavy infrastructure. Here is how I approached the technical side:

Multi-Channel pHash (Per-Channel RGB)
Most perceptual hashing (pHash) implementations convert an image to grayscale before processing. However, in a game like Pixel Flow, color is the primary piece of information. Discarding color would mean losing the ability to distinguish between levels with similar layouts but different color palettes.
To fix this, I split the image into its Red, Green, and Blue channels and computed a 256-bit pHash for each channel independently.
Combining into a 768-Bit Fingerprint
After generating a 256-bit hash for all 3 channels, I concatenated them. This creates a combined fingerprint of 768 bits (256 * 3). This captures both the structural layout and the color distribution of the game level perfectly.
Hexadecimal Compression
Storing and querying a raw 768-bit binary string isn't the most efficient approach for database queries. To reduce the data footprint, I convert the binary string into a hexadecimal string. This brings the size down to just 192 characters while retaining all the precision.
Fast Hamming Distance Matching
When a user uploads a screenshot, the system generates its 768-bit hash on the fly. It then compares this hash against the saved database of known level hashes. By calculating the Hamming distance (the number of positions at which the corresponding bits are different), it can rapidly find the closest match.
Displaying the Top 6 Matches
Finally, the system pulls the 6 records with the smallest Hamming distance and displays them to the user. Showing a small cluster of top matches instead of just one gives the user fallback options in case there are minor discrepancies due to image cropping, phone UI overlays, or screen dimming.

I'd love to hear your feedback on this! Are there more efficient ways to handle color-sensitive image hashing for grid-based games?

Link to the site: https://pixelflowonline.net/

From Zero to Ranked: Building a High-Performance NBA Player Randomizer with Next.js 14 & Cloudflare

Focss — Sun, 15 Feb 2026 02:47:35 +0000

As a developer and an NBA fan, I noticed a recurring problem in communities like r/NBA2K: players often get "choice paralysis" when starting a new MyLeague rebuild or a Blacktop 1v1 session. Static lists are boring, and existing randomizers are often cluttered with ads or lack specific filters.
I decided to build a high-performance solution: . Here’s how I leveraged Next.js 14 and Cloudflare to create a tool that is not only fast but also highly optimized for SEO.

1. The Stack: Why Next.js and Cloudflare?

For a tool-based website, performance is the primary SEO signal. I chose:

Next.js 14 (App Router): For its superior handling of Server Components and built-in Image Optimization.
Cloudflare Pages: To deploy at the edge, ensuring the generator loads instantly regardless of the user's location.
Tailwind CSS: For a "dark mode" aesthetic that resonates with the gaming community.

2. Data Strategy: JSON vs. CSV

While many data-heavy sites rely on databases, I opted for a JSON-driven architecture.
Performance: Next.js can import JSON files directly, allowing the JS engine to parse data with zero runtime overhead compared to CSV.
Filtering Logic: Storing player data in a structured JSON format allowed for instant client-side filtering by Team, Position, and Country without a single API call.

3. The Core Logic: Ensuring True Randomness

A common complaint with randomizers is "repetitive results." To ensure every player in the NBA database has an equal chance, I implemented the Fisher-Yates Shuffle algorithm.
This algorithm ensures an unbiased permutation of the player array.
When a user applies a filter—like "Center from France"—the tool first creates a filtered subset and then applies the shuffle to provide a fresh result every click.

4. SEO for Tools: Beyond the Meta Tag

Tools often suffer from "Thin Content" issues in the eyes of Google. To break into the first page of search results, I focused on:
Topical Authority: Instead of just a button, I added a comprehensive FAQ section explaining the tool's use cases for NBA 2K Challenges and Fantasy Basketball.
Dynamic Metadata: Each page uses Next.js 14’s generateMetadata to ensure that keywords like "Random NBA Team" and "2K26 Randomizer" are indexed correctly.
Internal Linking: I built a "Topic Cluster" by linking the main player generator to specialized tools like the NBA Team Generator.
Check out the live project here: https://randomnbaplayergenerator.net/

Random Nba Player Generator - A Free Tool

Focss — Wed, 04 Feb 2026 10:00:16 +0000

NBA Random Player Generator – What It Is

This free online tool instantly generates a NBA random player from both current and all-time rosters. Whether you're settling debates, playing fantasy games, or creating fun challenges, this generator gives you new players with every click.

How To Generate Random Nba Player

The Random NBA Player Generator works by leveraging a comprehensive database that includes detailed information on both current and historical NBA players. This database is meticulously compiled and regularly updated to ensure it encompasses a broad spectrum of players from different eras of the NBA. When a user interacts with the Random NBA Player Generator, the tool executes a randomized selection process.

Frequently Asked Questions

Is the Random NBA Players Generator free?

Yes, the Random NBA Player Generator is 100% free to use. Our mission is to provide a high-quality, accessible tool for the global basketball community. There are no hidden subscription fees, no "premium" tiers for specific teams, and no mandatory registration or login required. You can generate an unlimited number of players, experiment with all filtering combinations, and use the tool for your personal projects or gaming sessions without ever reaching for your wallet. We believe that the love for the game should be accessible to everyone, and this tool is our contribution to that vision.

Does it include current NBA players?

Yes, the generator includes active NBA players from recent seasons.

Can I use this tool for games or challenges?

Absolutely. Many users use it for NBA trivia, fantasy challenges, or social media content.

Is each result truly random?

Yes. Each click generates a new, random NBA player from the database.

Can I filter players by team or position?

Currently, the generator provides fully random results. Filters such as team, position, or era may be added in future updates.

Why would someone use a random NBA player generator?

People use random NBA player generators to discover new players, make unbiased selections, settle debates, or simply have fun with basketball-related challenges.

If you want to experience it, you can click on the link

https://randomnbaplayergenerator.net/