FIVEM COMMUNITY / VIEWING + ARCHITECTURE
Hades.
One crew.
More than one view.
A FiveM viewing hub with several live viewpoints, shareable layouts, and a separately refreshed video archive.
Several views.
LIVE THEATER + SAVED ARCHIVE
- My contribution
- Viewing experience,
hub pages & deployment
- Context
- FiveM community
Documented 2026 project
- Built with
- JavaScript · Netlify
Provider embeds
01 / THE BUILDOne event, several viewpoints
Hades is a viewing hub for a FiveM content crew. The multi-stream theater brings Twitch, Kick, and YouTube viewpoints into the same page, with members, live status, and a video archive close by.
My work covered the multi-stream experience, the surrounding hub pages, and deployment. The interesting part is how those pieces fit together: the theater is for the live moment; the archive is for finding something afterward.
A shared layout carries a viewing arrangement to someone else. It does not mean every provider's player will arrive at the same frame, or that a saved layout guarantees a stream is still available.
02 / THE BUILDArrange the viewing space
The documented flow is straightforward: choose a theater layout, watch the embedded streams, and share a URL carrying that layout. The archive gives the hub somewhere to go when the live session is over.
More than one way to watch.
Choose a schematic layout, then distinguish the live theater from the saved archive.
Provider embed position
No live video is loaded.
Provider embed position
No live video is loaded.
Provider embed position
No live video is loaded.
Provider embed position
No live video is loaded.
Provider players.
Twitch, Kick and YouTube embeds belong to the viewing experience. They are not served from the archive list.
A saved list.
A scheduled refresh updates archive metadata. The supplied account does not say the video itself is cached.
Two schematic viewpoints. This does not synchronize provider playback.
Read the figure without interaction
The documented hub arranges embedded streams and shares a layout by URL. Its archive metadata is refreshed separately. This demonstration changes only the number of local cards; no player timing or URL-sharing behavior is verified.
This figure is a schematic explanation, not the original player interface. It switches between local viewpoint cards without loading a stream, recording a viewer, or copying a provider's player. The original share format has not been supplied, so this example does not invent one.
03 / THE BUILDKeep the archive off the page-view clock
The companion article describes an archive fed by the YouTube API. Fetching a fresh video list on every page load would tie upstream API traffic to visitor traffic.
The documented change was a scheduled function that refreshed the list daily and cached it. Page views could read that saved list instead of asking the upstream API for it again.
That is a specific architectural boundary. The archive metadata is cached; the live video itself is still delivered through the embedded providers. It would be misleading to draw the whole streaming experience as if it came out of one local cache.
Traffic and refreshes are different clocks.
Change the assumptions. These numbers are not measured Hades traffic or a provider quota.
Fresh result: the example has a saved list. Its freshness still depends on the last successful refresh.
Read the figure without interaction
Direct mode: visits multiplied by calls per refresh. Scheduled mode: refreshes multiplied by calls per refresh. Cache reads still equal visits. An old result needs honest freshness information; a missing result needs an explicit empty/error experience. The source does not prove those recovery implementations.
04 / THE BUILDThe tradeoff is freshness
A scheduled list is a snapshot. Its refresh interval determines how quickly new archive entries can appear, and a failed refresh introduces another question: what should someone see when the saved list is old or missing?
The supplied account does not show the storage implementation, invalidation logic, or complete error path. Those are the next things to inspect in the repository. The figure explains those questions rather than claiming the original application already answers all of them.
05 / THE BUILDWhat this build puts together
The theater demonstrates a multi-view interface. The shareable layout makes that interface portable. The scheduled archive separates a repeatable background task from the visitor's immediate page load.
Those are useful pieces of application design even at community-project scale. They also have different failure conditions: an unavailable stream, an unsupported embed, and a stale archive are not the same problem.
06 / THE BUILDWhat I would verify before extending it
I would start with the actual URL-state format, current provider embedding requirements, and the archive refresh/storage code. I would also check keyboard behavior inside the players, the small-screen layout, and what remains visible when a provider fails.
No load test, availability measurement, new upstream-quota figure, or synchronized-playback guarantee is being claimed here. The project story is the documented design and its decisions, not an invented scale benchmark.
Source, dates, and what this page verifies
Based on the complete supplied project/article account. Original publication dates and source URLs are retained. This is an edited reference, not a published update or a new audit of the original application.
Official technical clarifications checked September 29, 2026 are explicitly marked and linked beside the relevant passages. They are distinct from the original author's historical claims. The jq and Docker excerpts remain unchanged and carry their source limitations.
No live streams, provider requests or original sharing schema are loaded. No repository, staff account, service terms, résumé, price or live backend was changed.
See docs/batch-6/SOURCE-REVIEW.md for the separation of source-derived claims, external documentation and authored illustrations.