When I reached the viewer side of the live system rebuild, I had to redraw the frontend/backend boundary.

In the early version, keeping the viewer page and admin backend together was convenient. Routes, permissions, and data were in one application. But as viewer experience, mobile layout, player behavior, comments, and realtime features became more important, keeping the viewer tied to the admin app slowed iteration.

The Viewer Side Is First a User Interface

The admin side cares about management efficiency. The viewer side cares about user experience. Their rhythms are different.

The viewer side has to handle initial load, player state, mobile gestures, comment input, login or token behavior, error messages, and the state after a live session ends. The admin side cares about room configuration, users, statistics, permissions, and maintenance.

When these concerns live together, code starts constraining itself. Once the viewer frontend is separated, the frontend can focus more directly on the viewing experience.

APIs Should Provide Stable Boundaries

An independent viewer frontend does not mean moving all logic to the frontend. It needs clear and stable APIs from the backend.

Room information, playback URL, comment list, comment submission, online state, user identity, and cover image all need clear boundaries. The frontend should not know how the admin backend stores rooms internally, and it should not depend on admin page structure.

I prefer the frontend to receive data shaped for the viewing scenario, not a shadow of the backend database.

The Player Is Not an Isolated Component

An HLS player looks like a component, but it pulls many states with it.

Whether the live session has started, whether the stream is available, whether the network failed, whether the user is on mobile, whether autoplay needs muting, and whether comments conflict with the player all affect the viewing experience.

So I do not treat the player as a standalone technical point. It should be designed together with room state, error messaging, comment area, and mobile layout.

Separation Makes Responsibilities Clearer

After the viewer side is separated, frontend and backend responsibilities become clearer.

The backend owns rooms, permissions, playback URLs, comment data, and realtime events. The frontend organizes these capabilities into a stable viewing experience. The two sides collaborate through APIs and events instead of depending on the same page template.

This also makes maintenance easier. Adjusting the viewing experience does not always touch admin. Changing admin management does not always affect the viewer.

Clear Boundaries Make Speed Sustainable

This split reminded me that speed does not always come from putting everything together.

Putting things together is fast early on. After the business grows, clearer boundaries are faster. When the viewer, admin, APIs, and realtime events each become stable, iteration no longer means worrying that every change affects another part.