Online-Tech-Hiring-Platform: PeerChat: The Technical Hiring Platform That Treats Interviews Like Server-Captured Media
A close look at the Polyglot stack, the Mediasoup recording pipeline, and the workflow logic that turns a video call into a durable hiring system.
- PeerChat’s defining move is to make the server the source of truth for interview recording, which changes the product from a live call tool into a durable evidence system.
- The repo splits responsibilities cleanly: Java and Spring handle identity and hiring workflow, while Node and Mediasoup handle WebRTC transport and media capture.
- PlainTransport into FFmpeg is the architectural tell. It protects recordings from browser crashes, flaky clients, and other failures that would weaken client-side capture.
- The platform’s real competition is not another UI, but any workflow that treats interview media as disposable instead of operationally important.
Why this is not a meeting app
PeerChat is built like hiring software first and communication software second. That distinction matters, because the product’s value is not only that two people can talk. It is that the interview can be governed, recorded, and retrieved as part of a workflow that already knows who the candidate is, who the interviewer is, and what happens next.
That is the right mental model for this repo. The browser is a participant, not the owner. The platform’s real job is to preserve the interview as a durable artifact, then wrap access control and process around it.
The surprise: recordings happen on the server
The most interesting engineering decision in PeerChat is also the cleanest editorial hook: recording does not depend on the client. Media enters the system through Mediasoup, gets exposed through PlainTransports, and is fed into FFmpeg on the server side. That means the interview survives a flaky tab, a broken laptop, or a user who simply vanishes from the call.
How the media server is wired
The media layer is organized around Mediasoup’s usual cast of characters: worker, router, producers, consumers, and transports. The WebSocket server acts as the conductor. It creates rooms, connects transports, starts consumers, and keeps a recorder map keyed by room so the capture pipeline comes alive when a session does.
Candidate browser -> WebSocket signaling bridge -> Mediasoup router -> WebRtcTransport -> producers
Interviewer browser -> WebSocket signaling bridge -> Mediasoup router -> WebRtcTransport -> producers
Mediasoup router -> PlainTransport -> FFmpeg recorder -> archived composite recordingThe important part is the separation of planes. Signaling negotiates state. WebRTC carries live media. PlainTransport bypasses the browser path for recording. That split is what makes the system resilient, because the recording path is independent of the conversation surface.
Why the repo is polyglot
The Java and Node split is not accidental. Spring Boot owns the hiring brain: identity, authorization, persistence, and the business workflow around roles and sessions. Node owns the media heart: low-latency WebRTC, Mediasoup orchestration, and recording. That is a pragmatic architecture, not a novelty stack.
| Layer | Main job | Why it lives there |
|---|---|---|
| Java / Spring Boot | Users, roles, scheduling, persistence, JWT security | It is the stable system of record for hiring workflow and access control. |
| Node / Mediasoup | WebRTC signaling, routing, recording, transport lifecycle | It is closer to the real-time media loop and the FFmpeg pipeline. |
| Vanilla frontend | Candidate, interviewer, and admin portals | It keeps the UI simple while the backend handles the complexity. |
That division also keeps the complexity honest. The platform does not pretend one runtime should do everything. It lets each tier do the thing it is strongest at, which is usually the difference between a demo and a system you would trust in production.
The NAT problem is part of the product
PeerChat also pays attention to deployment reality. The media server’s announced IP logic exists because WebRTC does not care about your architecture diagram. It cares about whether peers can actually reach the server from behind NAT, across AWS, or through a messy network boundary.
In plain terms, the project tries to discover the public-facing address before the transport layer commits to it. That is a small detail with a big effect: connectivity becomes an operational concern the app handles, instead of a support issue users discover during an interview.
createWebRtcTransport(...)
-> choose listen IP
-> override with MEDIASOUP_ANNOUNCED_IP if present
-> expose the address WebRTC clients can actually reachWhat PeerChat is compared with
Generic conferencing tools optimize for conversation. Browser-recorded interview platforms optimize for convenience. PeerChat is trying to optimize for something harder: control over the interview artifact itself.
| System | Primary goal | Where recording happens | What breaks if the client fails | Hiring workflow support | Control over artifacts |
|---|---|---|---|---|---|
| PeerChat | Run technical interviews as a managed workflow | Server-side through Mediasoup and FFmpeg | The call may degrade, but the recording path stays controlled | Built in | High |
| Generic video conferencing | Host a live meeting | Usually client-side or optional cloud capture | Meeting continuity and capture can suffer together | Low | Medium |
| Browser-recorded interview tool | Capture quickly with minimal setup | Inside the browser | A tab crash can take the recording with it | Medium | Low |
That table is the whole story in miniature. PeerChat is not chasing polish for its own sake. It is chasing reliability, auditability, and workflow integrity.
What this project is really teaching
The lesson here is bigger than technical hiring. Once a product treats media as a first-class server responsibility, it can enforce process around it. That opens the door to stronger role separation, better failure recovery, and recordings that feel like evidence rather than leftovers.
That is why PeerChat feels distinctive. It is a hiring platform that behaves like a media engine. And that one design choice explains the rest of the stack.
