مقدمه
backend Bedrud یک پلتفرم جلسه تکباینری نوشتهشده در Go 1.24+ است. تمام وابستگیها — media server، frontend، TURN server — در یک executable embed شدهاند.
فناوریهای کلیدی
- فریمورک: Fiber v2 (روتر zero-allocation، API مشابه Express)
- دیتابیس: GORM با SQLite (پیشفرض) و PostgreSQL (production)
- Media engine: LiveKit (embed شده)
- احراز هویت: چندلایه — JWT، OAuth2 (Google/GitHub/Twitter)، Passkey (FIDO2)
- Static assets: از
embedدر Go 1.16+ برای بستهبندی frontend React (SSR) - استقرار: نصبکننده خودکار Debian/Ubuntu با systemd و ACME (Let’s Encrypt)
چرا این معماری؟
پلتفرمهای WebRTC معمولاً سرویسهای جداگانه برای signaling، TURN، وب و دیتابیس اجرا میکنند. Bedrud همه را در یک باینری ادغام کرده:
۱. استخراج باینری media server در runtime. ۲. Proxy ترافیک media از طریق پورت HTTP(S) اصلی. ۳. اتوماسیون پیکربندی سیستم (SSL، systemd) توسط خود باینری.
معماری سطح بالا
backend از معماری لایهای پیروی میکند:
۱. Server (internal/server): Fiber app، مسیرها و middleware.
۲. Handler (internal/handlers): پردازش درخواست و پاسخ HTTP.
۳. Repository (internal/repository): queryهای دیتابیس با GORM.
۴. Model (internal/models): جداول دیتابیس و structهای Go.
۵. Service: در handlerها و repositoryها ادغام شده، با پکیجهای internal/auth و internal/livekit.
نقطه ورودی
برنامه در server/cmd/bedrud/main.go شروع میشود. سه حالت دارد:
run: سرور کامل جلسات را شروع میکند.livekit: فقط media server داخلی را شروع میکند.install: نصب خودکار در Debian/Ubuntu.
بخشهای مستندات
- ساختار کد: همهچیز کجاست؟
- دیتابیس و مدلها: دادهها چطور ذخیره میشوند؟
- احراز هویت: کاربران چطور login میشوند؟
- Handlerهای API: درخواستها چطور پردازش میشوند؟
- یکپارچگی LiveKit: video server چطور کار میکند؟
- اتصال WebRTC: کلاینتها چطور اتصال media برقرار میکنند؟ (STUN/ICE/TURN/SFU)
- TURN server: معماری، پیکربندی و عیبیابی TURN
- نصب و استقرار: نصبکننده خودکار چطور کار میکند؟