yuragb/server_for_cam_det

Purpose and Entry Points

cam_serv is a Bun/Elysia WebRTC signaling service. It authenticates WebSocket upgrades, tracks connected peers, and relays SDP/ICE-style signaling payloads between peers; it does not carry media. Process startup is centered on src/server.ts, with application composition in src/Elysia/app.ts and Elysia bootstrap/export in src/Elysia/index.ts.

HTTP and WebSocket Surface

The route layer exposes root/health endpoints and the /ws signaling endpoint through src/Elysia/modules/Routes/index.ts and src/Elysia/modules/Routes/Signals/index.ts. WebSocket configuration, lifecycle handling, peer registration, forwarding, heartbeat cleanup, and connection limits are concentrated in:

• src/Elysia/modules/websockets/index.ts

• src/Elysia/modules/websockets/websocketConfig.ts

• src/Elysia/modules/websockets/wsLimits.ts

Control flow is: upgrade request → authenticate → connect socket → require register with peerId → map peer ID to socket → forward validated messages to targetPeerId with sender identity → remove peers on close/heartbeat expiry. Duplicate peer IDs replace the earlier connection.

Authentication and Request Security

JWT validation is applied at the Elysia module boundary, supporting bearer tokens and browser query-token fallback. Authentication components are:

• src/Elysia/modules/Authentication/index.ts

• src/Elysia/modules/Authentication/utils/index.ts

• src/Elysia/modules/Security/Cooclie/index.ts

Tokens may be validated via frontend-auth JWKS or shared-secret service JWTs, using issuer/audience and service-issuer environment configuration. Cross-cutting HTTP/security controls include rate limiting and security headers:

• src/Elysia/modules/Security/RateLimiter/index.ts

• src/Elysia/modules/Security/SecurityHeaders/index.ts

State, Persistence, and Cache Boundaries

Live signaling-peer state is inherently process-local WebSocket state. Redis is provisioned as infrastructure and is represented in application/cache modules:

• src/Redis/index.ts

• src/Elysia/modules/infrastructure/cache/cache.service.ts

• k3s/05-signaling-redis-deployment.yaml

SQLite/Drizzle persistence also exists, including a shallow-user schema and versioned migrations:

• src/db/drizzle/index.ts

• src/db/schema/ShalowUsers.ts

• drizzle/0001_lush_morlocks.sql

This separates transient connection routing from durable user-oriented data.

Runtime and Deployment

The service runs on Bun with Elysia, containerized by Dockerfile. It can run locally with Docker Compose or on k3s. Kubernetes manifests deploy separate signaling-app and Redis workloads, persistent volumes, services, secrets/config maps, and ingress:

• docker-compose.yml

• k3s/05-signaling-app-deployment.yaml

• k3s/09-ingress.yaml

Environment-driven limits include port, log level, maximum signaling-message bytes, JWT secret, issuer, audience, and allowed service issuers. /health supports probes and reports connected-peer state.

Supporting Service Boundaries

User synchronization is represented separately from realtime signaling:

• src/Elysia/modules/Routes/User/index.ts

• src/Elysia/modules/Routes/User/Controllers/sync.controller.ts

• src/Elysia/modules/Routes/User/Services/index.ts

src/cluster.ts indicates process/cluster orchestration as a runtime concern. Any scaling design must preserve peer-routing correctness: a sender and target located on different app instances need shared routing/session coordination, for which Redis is the likely infrastructure boundary.