Juan8 Karaoke: Building a Realtime Next.js App

Juan8 Karaoke started as a personal project with a simple goal: open a browser, queue a song, and sing with people in the same room without downloads or accounts. Building it forced the interesting problems of a Next.js realtime app into the open: shared state, device control, media APIs, and deploy boundaries.

The live write-up is on Juan8 Karaoke. This post walks through the stack and lessons without inventing metrics.

The problem

Karaoke at home usually means a machine, an app install, or a messy cast setup. I wanted a web app that:

• Plays from YouTube in the browser

• Lets friends add songs to a shared queue

• Gives phones a remote-control role without a full login wall

• Stays fun on desktop and mobile

That is a product brief and an engineering brief at the same time.

Stack for a Next.js realtime app

From the project page, the core stack is:

• Next.js 14 (App Router) + React for the UI and API routes

• Tailwind CSS for responsive layout

• Socket.IO for realtime queue and session sync

• Railway-hosted Socket.IO server for the realtime layer

• YouTube Data API v3 and YouTube IFrame Player API for search and playback

• Vercel for the Next.js deploy

The split matters: the Next.js app can ship on Vercel while the long-lived socket process lives on Railway. That is a normal shape for a Next.js realtime app once WebSockets outgrow a single serverless function.

Auth, sessions, and the queue

Instead of classic account signup, Juan8 uses session-based QR authentication. A phone scans a QR code and joins as a remote for that session. The project notes support for multiple remotes per session (up to five on the portfolio page).

Lessons that stuck:

• Treat the session as the unit of trust, not a permanent user profile

• Keep queue operations explicit (add, reorder, play next) so socket events stay boring and predictable

• Validate inputs server-side even when the UI feels casual

• Assume reconnects: phones drop Wi-Fi, tabs sleep, sockets flap

Realtime karaoke fails in embarrassing ways when two devices disagree about “now playing.” The queue has to be the source of truth.

Deploy notes

Vercel handles the Next.js surface well. The Socket.IO server on Railway handles persistent connections. Keeping those roles separate avoided pretending serverless alone would carry a party of open sockets.

Operational details I care about on a project like this:

• Rate limiting and input sanitization on API edges

• Security headers on the web app

• Clear env separation for YouTube keys and socket URLs

I am not going to invent uptime percentages or “enterprise” scorecards. The portfolio already states the security posture in plain terms: rate limiting, sanitization, and headers.

What I would improve next

If I keep iterating Juan8, the honest backlog looks like:

• Stronger session recovery UX when a remote disconnects mid-song

• Clearer host controls for moderating the queue in a loud room

• Tighter observability on socket errors without logging sensitive payloads

• More resilient YouTube search edge cases (quota, empty results, region limits)

Passion projects teach the same lesson as client work: ship the fun path first, then harden the failure path.

Who this is for

If you want a Next.js realtime app case study rooted in a real build, start with Juan8 Karaoke, browse more under Projects and the blog, or get in touch about similar full-stack work.

---