Source: Dev.to

Source: Dev.to

The Evolution from “Plumbing” to “Platform”

For the better part of a decade, building scalable real‑time video applications meant becoming a plumber. You didn’t just build an app; you:

• Managed janus-gateway config files
• Tuned mediasoup workers
• Wrestled with coturn for NAT traversal
• Wrote custom C++ wrappers to handle recording

In short, you were effectively building a telecom carrier from scratch just to add video chat to a website.

LiveKit represents the maturation of this stack. It is an opinionated, “batteries‑included” WebRTC infrastructure that abstracts the low‑level media transport (SFU) while exposing rigorous control via SDKs.

Why LiveKit Matters to a Python Backend Architect

LiveKit fundamentally shifts the responsibility model:

Your Python backend becomes the Orchestrator, using the livekit-api server SDK to:

• Provision rooms
• Mint security tokens
• Trigger cloud recordings

All communication with the LiveKit server happens over Twirp – a high‑performance RPC framework based on Protobuf.

LiveKit Topology

flowchart TB
    subgraph Client["Client SDKs"]
        direction TB
        C1[React] 
        C2[Swift] 
        C3[Kotlin] 
        C4[Unity] 
    end

    subgraph Server["LiveKit Server (Go – SFU)"]
        direction TB
        S1[SFU] 
    end

    subgraph Backend["Your Python Backend"]
        direction TB
        B1[Flask / FastAPI] 
        B2[Control Plane] 
    end

    %% Connections
    C1 -->|Signaling & Media| S1
    C2 -->|Signaling & Media| S1
    C3 -->|Signaling & Media| S1
    C4 -->|Signaling & Media| S1

    B1 -->|Server SDK (Python/Go/Node)<br/>Signaling & Control| S1
    B1 -->|Control API| B2

Components

---

The diagram above visualises the flow of signaling and media between client SDKs, the LiveKit SFU, and your Python control plane.

livekit-api – The Python Control‑Plane SDK

Note: livekit-api is for HTTP/RPC management only.
The livekit package (without -api) is for building real‑time agents that send/receive audio/video.

LiveKit delegates authentication entirely to your backend. The LiveKit server has no user database; it trusts JWTs signed with an API key and secret that you share between your Python backend and the LiveKit server.

Generating a participant token

import os
from livekit import api

# Ensure LIVEKIT_API_KEY and LIVEKIT_API_SECRET are in the environment
def create_participant_token(
    room_name: str,
    participant_identity: str,
    is_admin: bool = False,
) -> str:
    grant = api.VideoGrants(
        room_join=True,
        room=room_name,
        can_publish=True,
        can_subscribe=True,
        # Administrative powers (optional)
        room_admin=is_admin,
        room_record=is_admin,
    )

    token = (
        api.AccessToken()
        .with_identity(participant_identity)
        .with_name(f"User {participant_identity}")
        .with_grants(grant)
        .with_ttl(60 * 60)  # 1‑hour expiration
    )

    return token.to_jwt()

Architectural note: Never generate tokens on the client. Always generate them server‑side so you can revoke access, enforce bans, or dynamically assign permissions (e.g., a “stage hand” who can mute others but not publish video).

Provisioning a Room (Explicit Creation)

Although rooms can be auto‑created on first join, production systems often require explicit room provisioning (e.g., create a room 5 minutes before a meeting, set timeouts, limit participants).

import asyncio
import os
from livekit import api

async def provision_meeting_room(meeting_id: str) -> api.Room:
    # Initialise the API client
    lkapi = api.LiveKitAPI(
        url=os.getenv("LIVEKIT_URL"),
        api_key=os.getenv("LIVEKIT_API_KEY"),
        api_secret=os.getenv("LIVEKIT_API_SECRET"),
    )

    try:
        # Create a room with strict settings
        room_info = await lkapi.room.create_room(
            api.CreateRoomRequest(
                name=meeting_id,
                empty_timeout=300,               # Close after 5 min if empty
                max_participants=50,
                metadata='{"type":"webinar","host_id":"user_123"}',
            )
        )
        print(f"Room '{room_info.name}' created with SID: {room_info.sid}")
        return room_info
    finally:
        await lkapi.aclose()

Moderation & Bidirectional Orchestration

Your backend can mute, promote, or remove participants at runtime:

# Example: mute a participant
await lkapi.room.mute_participant(
    room_name="my_room",
    participant_identity="troublemaker",
    muted=True,
)

LiveKit also pushes events back to your service via webhooks (e.g., recording finished, room closed, participant disconnected). Verify the cryptographic signature of each webhook to ensure authenticity.

Handling LiveKit webhooks (Flask example)

from flask import Flask, request, jsonify
from livekit import api

app = Flask(__name__)

# Initialise a verifier with your API secret
verifier = api.TokenVerifier()
receiver = api.WebhookReceiver(verifier)


@app.route("/livekit/webhook", methods=["POST"])
def handle_webhook():
    auth_header = request.headers.get("Authorization")
    body = request.data.decode("utf-8")

    try:
        event = receiver.receive(body, auth_header)
    except Exception:
        return "Invalid signature", 401

    # React to the event type
    if event.event == "room_finished":
        print(
            f"Room {event.room.name} ended. Duration: {event.room.duration}s"
        )
        # Trigger billing, cleanup, etc.

    elif event.event == "participant_joined":
        print(f"User {event.participant.identity} joined.")

    # Add more event handling as needed...

    return jsonify({"status": "ok"}), 200

---

Simulcast & Advanced Media Features (Quick Note)

In raw WebRTC stacks (e.g., mediasoup), enabling simulcast—sending multiple qualities of the same video—requires:

• Client‑side: configuring multiple encodings.
• Server‑side: handling RTP streams and bandwidth allocation.

LiveKit abstracts all of that. You can enable simulcast with a single flag in the client SDK, and the server automatically manages the multiple streams.

---

TL;DR

By moving from “plumbing” to a platform, you spend time building features instead of infrastructure. 🚀

LiveKit – Why It Matters for Python Architects

The Problem with Traditional WebRTC

• Manual spatial‑layer negotiation – you have to decide which video quality to send.
• Bandwidth & CPU waste – each client must handle multiple streams and switch them manually.
• Recording headaches – packets are encrypted (SRTP), arrive out of order, and have variable bitrates.
  • Typical workaround: spin up a headless Chrome instance with Selenium, join the call, and screen‑record it.
  • This approach is brittle, resource‑heavy, and hard to maintain.

LiveKit’s Built‑In Solutions

One‑Call Composite Recording

async def start_recording(room_name: str):
    lkapi = api.LiveKitAPI(...)

    # Configure output to S3
    s3_output = api.EncodedFileOutput(
        filepath=f"recordings/{room_name}/{{time}}.mp4",
        s3=api.S3Upload(
            access_key="...",
            secret="...",
            bucket="my-bucket",
            region="us-east-1"
        )
    )

    request = api.RoomCompositeEgressRequest(
        room_name=room_name,
        layout="grid",               # or 'speaker-dark', 'single-speaker'
        file=s3_output,
        # Encode options (H.264 High Profile)
        preset=api.EncodingOptionsPreset.H264_1080P_30
    )

    info = await lkapi.egress.start_room_composite_egress(request)
    print(f"Recording started. Egress ID: {info.egress_id}")

This single function call replaces weeks of engineering work required to build a custom recording pipeline using FFmpeg or GStreamer directly.

When You Need Low‑Level Control

LiveKit doesn’t lock you out of the metal. You can still write raw Go services that interface directly with the SFU if a niche use‑case demands it.

Bottom Line

• Managed WebRTC → shift effort from infrastructure (keeping the SFU alive, handling reconnects) to product features (moderation tools, AI integration, recording workflows).
• For 95 % of use cases—telehealth, virtual classrooms, live events—the Python SDK’s abstraction is the “sweet spot.”

In today’s real‑time economy, that velocity is your competitive advantage.