-
-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture Overview
This page covers the shape of the system and the reasoning behind it, at a level useful for understanding the project — not a full implementation reference. Endpoint-by-endpoint and schema-level detail lives in local planning notes, not in this wiki.
- Frontend: React (Vite)
- Backend: Node.js + Express
- Database: Postgres, hosted free on Neon
- Hosting: Backend on Render's free web service tier, frontend on a static host (Vercel/Netlify)
One language (JavaScript) across the whole stack, and every piece of infrastructure runs on a genuinely free tier — this is a solo, zero-budget project.
Important
This is the target deployment stack, chosen and built against — it isn't live on the public internet yet. Development and testing currently happen locally; see the README for local setup instructions.
Render's free web service spins down after 15 minutes idle and cold-starts in 30–60 seconds, which is an acceptable trade-off for a friends-testing project where nobody expects always-on uptime. Neon's free Postgres tier persists indefinitely, unlike some free-tier databases that expire after a fixed window, and it lives independently of Render, so the backend's cold-start/redeploy cycle never puts the data itself at risk.
The backend deliberately never stores live Twitch API responses — stream titles, viewer counts, thumbnails. It only persists what a user explicitly created: template data (which channels, in what layout, which audio mode). That distinction keeps the project clearly outside any "don't cache or redistribute Twitch data" concern, since nothing it stores actually originates from a Twitch API call.
The grid's entire state — which channels are in it, the current audio mode, per-channel volumes, chat bar visibility — lives in one place on the frontend. Saving a template is just sending that state to the backend; loading a template is just replacing it. Keeping "current grid" and "saved template" the same shape avoids maintaining two parallel representations of what is conceptually the same thing.
Chat tabs and the offline/online state per panel are driven directly by the Twitch Embed SDK's own events and player controls, rather than by polling or manually tearing down and remounting iframes — muting a channel means calling the embed's own mute API, not hiding or reloading its iframe.
Tip
"Mount once, control via the SDK" is a recurring pattern here: chat tabs are all pre-loaded and shown/hidden with CSS rather than mounted and destroyed on switch, for the same reason — avoiding a visible reload.
Login goes through Twitch's standard OAuth flow. The backend exchanges the authorization code for Twitch's tokens itself and issues its own signed, session cookie to the frontend — Twitch's access and refresh tokens never leave the backend. Chat sending is handled by Twitch's own embedded chat widget, which authenticates the user with Twitch directly, so no token ever needs to pass through StreamHive's own backend for that action. Twitch removed API-based following in 2021, so "follow" opens the channel's own Twitch page instead of trying to fake the action through an API call that no longer exists.
See Roadmap for what's shipped against this architecture so far.