DEV Community: Lê Huy Giang

I Already Had Sentry. Then an iPhone from 2018 White-Screened My Karaoke App.

Lê Huy Giang — Sat, 22 Aug 2026 06:48:56 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

VKara is a karaoke room in the browser.

YouTube already plays the videos. VKara's job is the room: one TV as the playback screen, everyone's phone as a remote.

I rebuilt that for the GitHub Finish-Up-A-Thon. The idea is simple enough to explain in one sentence. The users are not.

A karaoke night at home usually involves parents, uncles, and aunts. People who are not going to update their phones. People whose "second phone" is still Safari 12. The TV in the living room is often a Tizen or Android TV from years ago. I do not own every one of those devices. I cannot sit in every living room and tap through first paint.

That is why I added Sentry about a month ago — as foundation, not as a challenge badge. vkara-web and vkara-api. Real production. The point was to see what old phones and old TVs do when I am not in the room.

Live: https://vkara.vercel.app
GitHub: https://github.com/lehuygiang28/vkara

Bug Fix or Performance Improvement

Sentry's issue list is noisy. That is normal.

Some events are not VKara bugs. YouTube's iframe hitting a Tizen same-origin wall. Zalo — a chat app a lot of people in Vietnam use — injecting zaloJSV2 into the page. I left those alone.

Two first-party failures were taking the room down. (Sentry issue links need org login. The screenshots below are the public proof.)

White screen on iOS 12 — WEB-B, WEB-C.

19 seconds. White screen. WEB-B and WEB-C in one Replay.

This is the device I would never have tested on purpose. Mobile Safari 12.1.2. iOS 12.5.8. Referrer: Yahoo Vietnam.

Replay showed the whole night dying in under 20 seconds. next-intl constructs Intl.PluralRules. Then matchMedia().addEventListener. Then the error boundary called useI18n() to explain the crash — same Intl path. The safety net crashed too.

Seer named the missing API. The error-boundary re-throw I found in error.tsx.

Related shelf 502 — API-A, API-C.

POST /related. InnerTube HTTP succeeded. youtubei threw on schema drift. Users=1 is a proxy IP. 189 events at screenshot time.

The phone remote asks for related songs. The parser hit a missing YouTube field. The route turned that into 502 youtube_upstream_failed. The player could still be up. The remote felt broken.

No new features. I wanted those two to stop killing a karaoke night.

I am not going to quote "zero events since deploy."

Safari 12 is a long tail. Two days of silence and two months of silence can mean the same thing: that phone did not open the room again. Supporting old devices needs users I do not have on a contest deadline. A quiet dashboard is not a result.

The number that matters is what one event does to the room.

WEB-B and WEB-C: 9 events, 2 users, last seen 6 Aug. Looks small. The Replay is 19 seconds of white screen. One phone opening the room is enough to take the night with it. Last-seen-in-August is how rare the device is, not how small the bug is.

API-A: 189 events at triage. Users=1 is a proxy. That count is how often /related turned a parser throw into 502 while a song was already playing. I did not try to make the Sentry issue disappear. youtubei will keep drifting. After the fix, the same throw is kind=parse, handled, warning. The remote gets 200 and an empty shelf. Local check: real videoId → 20 items; bad continuation → empty list, not 502.

That is the impact I can defend before the next iPhone from 2018 shows up.

Code

PR: https://github.com/lehuygiang28/vkara/pull/8

Fixes VKARA-WEB-B · WEB-C · API-A · API-C

I already had tv-polyfills.js for Tizen / Chrome 76. It loads beforeInteractive on every locale. Production showed Safari 12 needed two more shims. Native APIs stay untouched:

if (typeof Intl !== 'undefined' && typeof Intl.PluralRules !== 'function') {
    Intl.PluralRules = function PluralRules(locale) {
        this.locale = locale == null ? 'en' : String(locale);
    };
    Intl.PluralRules.prototype.select = function select() {
        return 'other';
    };
}

I did not ship full CLDR plurals. Vietnamese does not need English-style plurals. A white screen is worse than select() returning 'other'.

The error boundary no longer imports next-intl:

export default function LocaleError({ error, reset }) {
    const phase = useErrorBoundaryRecovery(error, reset);
    return <RecoveryShell phase={phase} label={documentRecoveryPhaseLabel(phase)} />;
}

Related parse failures become an empty list. Sentry still gets kind=parse. Real YouTube HTTP failures still 502:

export function safeParseRelated(raw, client) {
    try {
        return BaseVideoParser.parseRelated(asYoutubeRawData(raw), client);
    } catch (error) {
        captureRelatedParseFailure(error);
        return [];
    }
}

My Improvements

The useful decision was what not to fix.

I did not chase Zalo inject or Tizen iframe SOP. Those show up in Sentry. They are not my product.

I did not wrap every matchMedia call with addListener. There are two call sites today. There will be a third. One prototype shim in the file that already runs before app JS is enough.

I did not keep useI18n() behind try/catch. Hooks cannot do that. The recovery label is a small en / vi map from document.documentElement.lang. Ugly. Correct.

I did not turn every /related error into 200. An empty shelf looks like "no recommendations." A 502 looks like the app is down. During a song, those are not the same thing.

What I learned: nobody at a karaoke night cares that Intl.PluralRules shipped in Safari 13.

They care that the TV shows a video, and related still returns a list.

Best Use of Sentry

A month ago I wired Sentry as production foundation because VKara runs on devices I do not have on my desk: old iPhones, old Samsung TVs, Android TV boxes that never get a browser update. If something white-screens in a living room, I only find out if the client tells me.

What surprised me was the community support. Node is obvious. Bun, I expected they would get to. Seeing a first-party Sentry guide for Elysia still caught me. That is the kind of coverage that makes foundation work boring in a good way: Sentry.init(), wrap the app, ship. I was not writing a custom adapter for a karaoke API.

This challenge is the first time that bet paid off in a way I can point at.

Tool	What I actually used it for
Error monitoring	WEB-B: Safari 12.1.2 / iOS 12.5.8 — the phone I do not own. API-A: 189 events at triage, kept as handled parse
Session Replay	WEB-B and WEB-C are one white screen, not two stories
Seer	Named `Intl.PluralRules`. Missed that `error.tsx` would re-throw
MCP	From the editor: pull API-A, keep WEB-A / Zalo off the PR

Seer first returned HTTP 402. No budget on the plan I had. I used bugsmash26, then WEB-B RCA ran on the issue page.

Same reason there's no before/after chart above — a quiet week doesn't prove a long-tail device is fixed. What Sentry proved instead: the 19 seconds, and that API-A now reports as kind=parse instead of 502.

Best Use of Google AI

I used Antigravity with Gemini and the Sentry MCP. Not to generate the PR. To sit next to the issue list and ask what was actually mine.

Connect to org vkara, find the issue, explain cause.

The Sentry MCP setup page currently shows Gemini CLI. Antigravity wants serverUrl instead of url. One field. Then it connected. If Sentry adds an Antigravity snippet later, that extra minute goes away. Not a real problem.

{
  "mcpServers": {
    "sentry": {
      "serverUrl": "https://mcp.sentry.dev/mcp"
    }
  }
}

Gemini + MCP pulled Seer on API-A: InnerTube schema drift, videoInfo.attributedDescription undefined inside youtubei Video.load. That is the /related 502.

It also showed WEB-A (YouTube iframe SOP) and WEB-9 (Zalo WebView inject). I did not patch those.

That was the useful part.

In the Finish-Up-A-Thon I learned not to ask AI to dump code. Same here. Gemini helped me triage. The shim, the error-boundary helper, the parse wrapper, and the tests are mine.

Sentry showed the crash on a phone I do not own.

Gemini helped me not fix the wrong crash.

Then I made the smallest change I would still trust on a weekend night.

I Rebuilt My Karaoke App So Everyone's Phone Could Be a Remote

Lê Huy Giang — Mon, 01 Jun 2026 00:47:27 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

VKara is a browser-based karaoke room app for singing at home with friends or family.

It is not trying to replace YouTube.

YouTube is already great at playing videos. It already has almost every karaoke song we need. But YouTube is not really designed to manage a karaoke night where many people want to choose songs together.

That is the gap VKara tries to fill.

You open VKara on a TV or laptop as the main playback screen. Everyone else joins the same room from their phone using a 4-digit room code or QR code. Then anyone can search for songs, add them to the queue, pause, resume, or skip.

The TV only needs to play the video.

Everyone's phone becomes their own remote.

That is the whole idea.

Simple enough to explain in one sentence. Not simple enough to build in one weekend. I learned that part the hard way.

Demo

Links:

Live demo: https://vkara.vercel.app/en
GitHub repo: https://github.com/lehuygiang28/vkara
Before branch: https://github.com/lehuygiang28/vkara/tree/before
Old backend repo: https://github.com/lehuygiang28/vkara-api

Small warning: the demo is running on limited resources, so if it is slow, please give it a moment. My wallet is still a student wallet. lol.

The flow is:

Open VKara on a TV or laptop.
Join the room from a phone by code or QR.
Search for a karaoke video.
Add it to the shared queue.
Control playback together.

Before: the idea worked, but the product still felt like a video app squeezed into a karaoke use case.

After: the mobile flow is now focused on joining, searching, choosing an action, and controlling playback.

What Changed

Before:

Frontend and backend lived in separate repos
Mobile UI was basically a compressed desktop UI
WebSocket contracts were spread across projects
The TV screen had too many controls

After:

Merged everything into a Bun workspace monorepo
Moved shared API/WebSocket contracts into packages/shared-types
Rebuilt the product around two roles: TV as screen, phone as remote
Simplified the mobile flow around join, search, queue, and controls
Improved room state, reconnect behavior, playback sync, and deployment

The Comeback Story

I started VKara around early 2025.

At that time, my goal was very personal. I wanted a better way to sing karaoke at home with friends. The normal setup was: open YouTube on a TV, search for karaoke videos, and pass control around.

It worked, but it was awkward.

One person was searching. Another person accidentally played a video immediately. Someone else wanted to know what song was next. The queue was unclear. Casting also usually depended on everyone being on the same Wi-Fi network.

So I built a prototype.

The first version technically worked. And by "worked", I mean the dangerous kind of worked: it worked enough to prove the idea, but not enough to confidently bring it to a real karaoke night.

The product had problems:

the desktop screen had too many controls around the video
the mobile UI felt like a compressed desktop app
search, queue, and controls were too close together
realtime state was fragile
the frontend and backend lived in separate repos
shared types and WebSocket contracts were not cleanly owned by one place

That last part mattered more than I expected.

VKara is a realtime app. The frontend and backend have to agree on room state, queue state, video metadata, player commands, and WebSocket messages. When those contracts live in different places, every change feels risky.

So I stopped working on it.

Not because the idea was bad.

Because the project was hard to change.

When I came back this year, I decided not to start with new features. I started by making the project safe to change.

The first major step was merging the old frontend repo and old backend repo into one Bun workspace monorepo:

apps/web                # Next.js frontend
apps/api                # Elysia + WebSocket backend
packages/shared-types   # shared API/WebSocket contracts
packages/shared-utils   # shared helper functions

This was not just folder cleanup. It changed how I could work on the project.

After the monorepo migration, web and API changes could be checked together. Shared contracts could live in packages/shared-types. I could change a room event or video shape without hunting through two repos and hoping I remembered everything.

The second major change was UX.

At first, I treated VKara like a responsive website:

Desktop layout. Mobile layout. Done.

That was the wrong mental model.

A TV is not just a large phone. A phone is not just a small TV.

They have different jobs.

So VKara now thinks in two roles:

TV / laptop: the playback screen
Phone: the remote

That one decision made the product much clearer.

The TV should stay clean. It should show the video, the room code or QR, and the basic room controls.

The phone should handle joining, searching, adding to queue, and playback actions.

The real flow became:

Join a room → search a song → add it to the queue → keep singing.

A lot of the comeback work was not glamorous. It was the kind of work users only notice when it fails: WebSocket room state, reconnect behavior, playback sync, queue updates, room cleanup, YouTube metadata shape, Docker builds, GitHub Actions, and Vercel deployment after the monorepo migration.

Nobody at a karaoke night cares how clever the architecture is.

They only care that when they tap a button, the room responds.

My Experience with GitHub Copilot

The biggest difference between the first version and this comeback was not only GitHub Copilot.

It was how I used it.

In the first version, my AI-assisted workflow was too naive. I asked for code, patched bugs by hand, and moved fast. That helped me build a prototype, but it did not always leave behind code I trusted.

This time, I used GitHub Copilot more like a finishing partner.

Before changing code, I used Ask Mode to understand the project again. VKara had been sitting for a long time, and honestly, I did not remember every decision I made.

One of my first questions was basically:

"Why am I not using SWR or React Query in this frontend? What am I actually using instead?"

The answer reminded me that the app was using Zustand stores for client state, direct fetch calls for server data, and WebSocket-driven realtime sync for room/player state.

That question saved me from changing the wrong layer.

Ask Mode helped me understand the old data flow before editing code.

For larger work, I used Plan Mode before execution.

Instead of saying:

"Make these two projects cleaner."

I asked for a real migration plan:

"Merge vkara and vkara-api into one monorepo, keep history, use Bun workspace, find shared types, and move contracts into shared packages."

Plan Mode turned a vague refactor into a safer migration path.

That became my loop:

Think → Ask → Plan → Execute → Verify → Repeat

For bugs, I pasted exact TypeScript errors or Docker logs.

For UI work, I used screenshots and described what felt wrong.

For architecture questions, I asked for alternatives before touching code.

That was the real upgrade.

In the first version, I mostly asked AI to generate code.

In the comeback, I asked GitHub Copilot to help me investigate, compare, plan, refactor, verify, and explain trade-offs.

The final result is still not perfect.

But now I know what actually matters.

Not “AI lyrics” or some huge feature that sounds cool in a roadmap.

The real problems are smaller and more human: who is allowed to skip, who added this song, whose turn is next, how to stop one person from filling the whole queue, how to rejoin quickly when someone closes their phone, and how to bring back the same queue for the next karaoke night.

YouTube already gives us the videos.

VKara should make the room feel calm.

But VKara is no longer just a prototype I keep for myself.

It is something I can open on a TV, hand my phone to a friend, and say:

"Pick the next song."

And honestly, that already feels like a win.

I Built a Full-Stack Proxy with a Dashboard to Scale the Gemini API. Stop Juggling Keys

Lê Huy Giang — Tue, 30 Sep 2025 16:22:12 +0000

Hey Dev Community! 👋

If you're like me, you love hacking on projects with the Google Gemini API. But you also know that feeling... you're in the zone, code is flowing, and BAM! Rate limit exceeded. 😭

The free tier is fantastic, but that RPM/RPD limit can be a real creativity killer.

This exact problem bugged me so much that I decided to build my first major open-source project to solve it. I'm super excited (and a little nervous!) to share it with you all: Gemini Proxy.

🚀 This project is fresh off the press and actively being developed! I'm constantly adding new features, fixing bugs, and improving the developer experience. Your feedback and contributions are not just welcome—they're essential to making this tool amazing for the entire community.

✨ What's in the Box?

🔑 Stop Juggling API Keys → Throw all your Google Gemini keys into one secure spot (a Supabase DB). The dashboard lets you add, toggle, or remove them on the fly. No more .env file madness!
⚖️ Automatic Load Balancing → It smartly spreads your requests across all your active keys. If one key gets tired and hits its limit, the proxy just grabs the next one. Zero downtime for your app.
🛡️ Your Own Secret Handshake → Create special proxy keys for your apps. This means your real Google API keys never leave the backend. Super secure!
📊 Know What's Happening → A built-in dashboard shows you logs, performance, and usage in real-time. No more flying blind!
🌍 Deploy It Your Way → The full-stack Next.js app is the easiest way to get everything, but if you just need the core logic, you can deploy it to Vercel Edge, Cloudflare Workers, and more.

🏗️ How It Works

The concept is simple but powerful. Your application makes requests to your deployed Gemini Proxy instance using a proxy key. The proxy then uses Supabase as its "brain" to fetch an available Google Gemini API key, forward the request, and log the transaction.

Your App → Gemini Proxy → Google Gemini API  
               ↓  
            Supabase (for keys, logs, and metrics)

🚀 Get Up & Running in 5 Minutes

I wanted the setup to be as painless as possible. You can get the full experience (dashboard included!) up and running in about 5 minutes.

Prep Supabase → You'll need a Supabase project to act as the brain. I made an Illustrated Setup Guide and a Quick Usage with pictures and everything to walk you through it.
One-Click Deploy to Vercel → Just hit this magic button on main readme file. It'll clone the repo and get you ready to go.
Connect to Supabase → Vercel will ask for your Supabase URL and key. Just paste 'em in.
Launch! → You're live! You have a running instance with a dashboard.
Feed It Some Keys → Now for the fun part. Use the CLI or the shiny new web UI to add your first proxy key and all your Google Gemini API keys.

💻 Show Me the Code

Okay, you're deployed. Now what? Just point your favorite AI library to your new proxy URL. Here's how it looks with the Official Google Genai. Check out how clean this is:

import { GoogleGenAI } from '@google/genai';

const genAI = new GoogleGenAI({
    apiKey: 'YOUR_PROXY_API_KEY',
    httpOptions: {
        baseUrl: 'http://localhost:9090/api/gproxy/gemini',
    },
});

// Generate content
const response = await genAI.models.generateContent({
    model: 'gemini-2.0-flash',
    contents: 'Count from 1 to 10',
});

console.log(response.text);

And boom! Your app is now supercharged, running through a scalable, managed proxy that you control.

🔥 This Project Needs YOUR Help

🔥 This project is in active development and I need YOUR help!

Honestly, this is my first big open-source project, and I'm really passionate about making it something the community finds useful. For now, my main collaborator has been AI (it's been an interesting journey, ask me about it sometime!), but I know that the best projects are built with people.

That's where you come in - and I genuinely appreciate every contribution!

🐛 Found a bug? → Open an issue - Please report it! I'm actively fixing issues and your bug reports help me make this tool rock-solid.
💡 Got an idea? → Start a discussion - I'm all ears! Feature requests, improvements, or even just suggestions for better UX are incredibly valuable.
👩‍💻 Want to contribute code? → Fork the repo - Pull requests are always welcome! Whether it's fixing a typo, adding a feature, or improving performance - every contribution matters and I'll make sure to acknowledge your hard work.
📝 Questions about the code? → Don't hesitate to ask! I'm here to learn and grow with all of you, and your questions help me improve both the code and the documentation.

I'm looking for feedback, ideas, and maybe even a few brave souls who want to contribute. If you read my code and have questions or see a better way to do something, please tell me! I'm here to learn and grow with all of you.

👉 Check out the Repo: lehuygiang28/gemini-proxy

If you think this is a cool idea, please give it a ⭐️ on GitHub! It would seriously make my day.

This is my first major open-source project, and I'm committed to making it amazing with your help. Let's build something great together!