Syncora Rtc Platform

I maintain Syncora-RTC-Platform, a production-grade distributed team communication platform designed to emulate core Slack features. Its README names the project SyncGrid. I built it as a TypeScript monorepo for real-time team chat, using a raw ws WebSocket server, Redis Pub/Sub for horizontal scaling, and BullMQ workers for background processing. Further documentation is in docs/ARCHITECTURE.md, docs/WEBSOCKET_PROTOCOL.md, docs/API.md, and docs/DEPLOYMENT.md.

My repository metadata is TypeScript, 1 star; started 2026-06, last updated 2026-11.

My platform feature set is accounts, workspaces, channels, messaging, files, notifications, search, and activity feed.

• I support account registration and login with bcrypt and JWT, short-lived access tokens, rotating refresh tokens, email verification, password reset, and token revocation on logout. Workspaces have admin and member roles; invitations can go by email, including to addresses without existing accounts, or by invite link. Admins can access audit logs and usage insights. I support public, private, and archived read-only channels, one-to-one direct messages, message history with infinite scroll, editing and deletion, emoji reactions, threads, @mentions, attachments, typing indicators, read receipts, and online presence. Files can be uploaded, previewed inline when they are images, and downloaded; storage can be local or S3-compatible. Notifications cover mentions, direct messages, thread replies, and invites; they are delivered live and persisted, and offline mentions can trigger email. Search covers messages, users, and channels within the requester's access, and each workspace has an activity feed.

My React frontend uses Vite, Tailwind, Zustand, and React Query. REST /api and WebSocket connections serve horizontally scaled API and WebSocket servers. Redis provides Pub/Sub, caching, and presence; BullMQ queues feed workers for notifications, audit, email, activity, and analytics; MongoDB is the primary database.

• My monorepo contains apps/web/ for the React single-page app, apps/api/ for the Express REST API, apps/websocket/ for the ws server, and apps/worker/ for BullMQ consumers and event services. packages/shared-types/ contains WebSocket protocol zod schemas, DTOs, and event types; packages/database/ contains Mongoose models and shared queries; packages/queue/ contains Redis clients, BullMQ queues, event bus, presence, and token store. Other packages include packages/config/ for environment validation, packages/logger/ for Winston structured logging, and packages/ui/ for shared React components. ops/ holds Caddy, Prometheus, Alertmanager, and Grafana configuration; docs/ holds architecture, protocol, API, and deployment documentation. The repository also includes scripts/e2e.ts, a Dockerfile for API, WebSocket, and worker services, and docker-compose.yml and docker-compose.dev.yml. Internal packages are consumed as TypeScript source with no intermediate build step; Node services run through tsx.

Messages are persisted to MongoDB before broadcast, so clients receive the stored identifier and timestamp; failed writes are reported to the sender.

Client-bound frames are published on ws:broadcast and each WebSocket instance delivers them to its own sockets. Processes do not write to one another's sockets; domain events are published through Redis and consumed by workers, keeping the message path independent of notification and audit code.

Pub/Sub events are converted into retried, idempotent BullMQ jobs, with each event claimed by exactly one worker. This makes event work durable after consumers receive it, while the underlying Pub/Sub events themselves are fire-and-forget.

Channel access is checked on every frame against a Redis-cached member set; membership changes invalidate the cache and inaccessible resources are reported as not found.

Direct messages are channels of kind dm, so history, subscriptions, receipts, search, and access control can share one code path.

My read receipt scope is Direct messages and private channels only, avoiding quadratic fan-out in large public channels.

The WebSocket access token is sent in the connection URL because browsers cannot set headers on a WebSocket. I advise using TLS and avoiding query-string logging; an already-open socket remains connected until it reconnects, even after its token expires.

My authorization checks return inaccessible resources as not found rather than forbidden. Email is logged by the worker when SMTP_HOST is empty. Email verification does not block use of the application, but an invitation to an address can only be redeemed once that address is verified.

I require Node.js 22 or later, pnpm 11, and Docker Desktop. Local startup uses pnpm install, cp .env.example .env, and pnpm local. This starts MongoDB, Redis, and Mailpit in Docker, waits for health, then starts the API, WebSocket server, worker, and web app. The application is at http://localhost:5173 and the Mailpit inbox at http://localhost:8025. Verification, password-reset, and invitation emails arrive there when SMTP_HOST=localhost and SMTP_PORT=1025 are set; without SMTP settings, the worker only logs them. Stop with Ctrl+C, then run pnpm infra:down.

My local service ports are API 5000, WebSocket 8080, web app 5173, Mailpit 8025, SMTP 1025.

cp .env.example .env
docker compose up --build

For Docker startup I set JWT_SECRET, MONGO_PASSWORD, and REDIS_PASSWORD in .env; the README gives openssl rand -hex 24 as an example for generating secrets. Docker starts frontend (nginx), api, websocket, worker, mongodb, and redis. Optional Compose profiles add Caddy, Cloudflare Tunnel, a second WebSocket instance, Prometheus, Grafana, Alertmanager, and scheduled backups. All services read environment variables validated at startup by @repo/config; .env.example is the template.

My token lifetimes and auth limit are access token 1h; refresh token 30 days; 30 credential attempts per IP per 15 minutes.

My default local upload limit is 10 MB.

• I use pnpm local to start infrastructure and all apps; pnpm dev starts apps with hot reload and requires infrastructure already running. pnpm infra:up and pnpm infra:down start or stop MongoDB, Redis, and Mailpit. pnpm lint, pnpm typecheck, pnpm test, and pnpm build are Turbo-orchestrated CI checks; pnpm e2e runs the end-to-end suite against a running stack.

My Vitest unit tests cover protocol validation, mention parsing, notification rules, WebSocket registry fan-out, presence and token handling, client message reducers, and API authentication and validation; they need no database. The E2E suite uses real HTTP and WebSocket clients against a running stack. With Mailpit reachable (MAILPIT_URL, default http://localhost:8025), it exercises email verification, password-reset, and invitation flows. A second WebSocket instance on port 8082 lets test users connect to different instances to cover the Redis backplane.

My CI workflow is Pull requests run lint, type checking, unit tests, build, and end-to-end suite with Mailpit; merges to main build Docker images.

My operations include a Docker Compose stack, GitHub Actions pipeline, Prometheus metrics and alert rules, Grafana dashboard, and automated MongoDB backups. My message search uses a MongoDB text index. Pub/Sub events are not replayed, so if a worker is offline, notifications and activity derived from events during that period are lost; audit and email jobs created by the API are durable. MongoDB and Redis run as single nodes, without a replica set or Sentinel. Tokens are stored in localStorage. Search is word-based and does not match substrings.

My limitations are Pub/Sub events are not replayed; MongoDB and Redis are single nodes without replica set or Sentinel; tokens are stored in localStorage; message search is word-based and does not match substrings.