sangeeth-47/live

1. Application shape

- This is a client-side browser app with two primary modes: Presenter and Viewer.

- The app starts from index.html, with src/js/main.js and src/js/app.js acting as the JavaScript entry points for bootstrapping, routing, and mode selection.

2. Top-level orchestration

- router.js, view.manager.js, state.js, and config.js form the application shell.

- Their job is to decide which flow is active, coordinate view rendering, and share global state/config across the presenter and viewer subsystems.

3. Domain split: presenter vs viewer

- The repository is intentionally split into two feature domains:

- src/js/presenter/* for the session owner who shares a screen.

- src/js/viewer/* for participants who request access and watch.

- Each side has its own actions, events, store/state, service, and view/layout modules, which suggests a clean separation between control UI and watching UI.

4. Presenter subsystem

- The presenter side includes presenter.service.js, presenter.store.js, presenter.view.js, layout.manager.js, and multiple section modules.

- Presenter UI is composed of sections such as header, sidebar, statistics, pending requests, and viewers.

- This side is responsible for creating a sharing session, approving viewers, monitoring session status, and displaying session metrics.

5. Viewer subsystem

- The viewer side includes viewer.service.js, viewer.store.js, viewer.state.js, viewer.view.js, viewer.layout.js, plus actions/events modules.

- Its responsibility is much narrower: enter/join a room, wait for approval, and render the live shared screen.

- The viewer likely consumes state from the room/session flow and renders a simplified experience compared to the presenter dashboard.

6. Room and sharing domain

- src/js/room/* and src/js/sharing/* appear to represent the business workflow for creating or joining a room and tracking access/sharing state.

- sharing.actions.js, sharing.service.js, sharing.store.js likely handle room-code generation and session lifecycle.

- room.actions.js, room.service.js, room.store.js, and room.events.js likely manage join requests, approvals, and room membership state.

7. Realtime control plane: WebSocket

- src/js/websocket/* is the signaling/control layer used for session coordination.

- It includes connection management, protocol/message handling, heartbeat, event routing, sender utilities, and event registration.

- The events/presenter.events.js and events/system.events.js files imply server-pushed events are routed back into the app to update state such as pending requests, approvals, and connection health.

8. Media plane: LiveKit

- src/js/livekit/* is the media streaming subsystem and likely carries the actual screen-share video/audio stream.

- The presence of livekit.connection.js, livekit.service.js, livekit.store.js, and livekit.actions.js shows a dedicated integration layer around the LiveKit SDK/bundle.

- In the architecture, WebSocket appears to handle session signaling and approval, while LiveKit handles low-latency media transport once a viewer is admitted.

9. Event-driven application flow

- eventbus.js and the various *.events.js files indicate an internal pub/sub style for decoupling UI, services, and transport events.

- Data likely flows from transport layers into stores, then into views through event notifications rather than direct cross-module calls.

10. UI component system

- Reusable visual primitives live under src/js/components/ (button, badge, card, spinner, base component).

- These are consumed by presenter and viewer views/sections to keep the UI modular and consistent.

11. Styling and layout

- Styles are split by concern: reset, typography, variables, layout, responsive behavior, animations, and component styles.

- There are also dedicated style bundles for presenter and viewer screens, reinforcing that the two modes have distinct layouts and visual hierarchies.

12. Assets and browser runtime assumptions

- The app is entirely browser-based and depends on modern browser screen-capture APIs, which matches the README’s browser support notes.

- ico/site.webmanifest and favicon assets suggest a PWA-like shell, but the core architecture is still a single-page web application rather than a multi-page site.

13. Likely end-to-end data flow

- Presenter creates a session → sharing/room logic establishes a room code → WebSocket notifies the backend/control plane → viewer submits join request → presenter approves via the presenter dashboard → viewer joins the LiveKit session → LiveKit carries the live screen stream.

- This is the main flow to show in an architecture diagram, with WebSocket as the coordination channel and LiveKit as the media channel.

14. State boundaries to show in a diagram

- Good diagram boundaries would be:

- App shell / routing

- Presenter dashboard

- Viewer experience

- Room/sharing workflow

- WebSocket signaling

- LiveKit media streaming

- Shared UI components and styling

- The key architectural idea is that the UI is split by role, while realtime signaling and media transport are separate infrastructure layers underneath.