إذا كنت تقوم ببناء مشروع جانبي باستخدام جافا سكريبت وإذا كنتَ بحاجة إلى مكالمات فيديو، فمن الطبيعي أن تراودك الشكوك: هل أستخدم WebRTC فقط، أم حزمة تطوير برمجية (SDK) مثل Agora أو Twilio أو Mux أو Zegocloud، أم أعتمد كليًا على RN-WebRTC في React Native؟ الخبر السيئ هو أنه لا يوجد حل واحد يناسب الجميع. أما الخبر الجيد فهو أنك تفهم لغة JavaScript في الوقت الفعلي، مما يضعك في موقع مثالي لاتخاذ قرار مدروس وتجنب إحداث أي خلل في بنية النظام.
ستشاهد في السطور التالية، خطوة بخطوة، كيفية عملها WebRTC Insideما هو دور أغورا (وغيرها من مزودي الخدمات المماثلة)؟ ما معنى إنشاء بنية تحتية خاصة بك (STUN/TURN، الإشارات، SFU، خوادم الوسائط...إلخ)؟ وما هي المفاضلات الحقيقية بين التكلفة والتعقيد وقابلية التوسع لمكالمات الفيديو والبث المباشر؟
ما هو WebRTC ولماذا هو أساس كل شيء؟
WebRTC (اتصالات الويب في الوقت الفعلي) هي مجموعة من المعايير وواجهات برمجة التطبيقات والبروتوكولات مفتوحة المصدر التي تُمكّن من بث الصوت والفيديو والبيانات في الوقت الفعلي مباشرةً من المتصفح أو التطبيق الأصلي، دون الحاجة إلى إضافات أو تطبيقات خارجية. وقد تم توحيدها من قِبل اتحاد شبكة الويب العالمية (W3C) وفريق هندسة الإنترنت (IETF)، وهي مدعومة من جميع المتصفحات الحديثة: كروم، فايرفوكس، سفاري، إيدج، أوبرا، والعديد من متصفحات الهواتف المحمولة.
فلسفتهم واضحة: تمكين التواصل نظير إلى نظير (P2P) بين المستخدمين بزمن استجابة منخفض للغاية، مع معالجة جميع مشكلات الشبكة غير المريحة - مثل برامج الترميز، والارتعاش، والصدى، وفقدان الحزم، والتشفير، وما إلى ذلك - في الخفاء. ويشمل ذلك كل شيء بدءًا من مكالمة فيديو فردية وحتى نظام من البث التفاعلي مع مئات أو آلاف المتفرجين إذا تم دمجها مع البنية التحتية المناسبة.
واجهات برمجة تطبيقات WebRTC الرئيسية: getUserMedia و RTCPeerConnection و RTCDataChannel
يعتمد WebRTC على ثلاث واجهات برمجة تطبيقات رئيسية من جانب المتصفح ستستخدمها بالتأكيد، سواء قمت ببناء حلك الخاص أو استخدمت SDK مثل Agora:
- MediaStream / getUserMedia: لالتقاط الفيديو والصوت (الكاميرا، الميكروفون، وحتى الشاشة أو علامات التبويب).
- RTCPeer الاتصال: للتفاوض ونقل تدفقات الصوت والفيديو بين النظراء.
- RTCDataChannel: لإرسال بيانات عشوائية (نص، ثنائي، ملفات) بزمن استجابة منخفض بين العملاء.
مع getUserMedia يمكنك طلب وصول المتصفح إلى الكاميرا والميكروفون واستلام MediaStream والتي تقوم بعد ذلك بربطها بعنصر <video> مع video.srcObject = stream. يمكنك التقديم قيود (الدقة، معدل الإطارات، الكاميرا الأمامية/الخلفية، إلخ.)، وإذا لم يتم استيفاء هذه الشروط، فستظهر لك أخطاء مثل: OverconstrainedErrorوالتي يجب عليك إدارتها لتقديم بدائل (على سبيل المثال، تقليل الحجم من 1080 بكسل إلى 720 بكسل وإجراء تعديلات لـ تحسين صوت الميكروفون).
واجهة برمجة تطبيقات RTCPeer الاتصال إنه جوهر المكالمات: فهو يتولى التفاوض على بروتوكول وصف الجلسة (SDP) (العرض/الاستجابة)، وجمع مرشحي بروتوكول ICE (الإيقاف/التحويل)، وإنشاء الاتصال، والإرسال الآمن عبر بروتوكول SRTP. من خلال التعليمات البرمجية الخاصة بك، يمكنك ببساطة إنشاء الاتصال، وإضافة مسارات الوسائط، والتفاعل مع أحداث مثل onicecandidate u ontrack وتتولى أنت أمر اللافتات.
وأخيرا، RTCDataChannel يُتيح لك هذا البرنامج إنشاء قنوات بيانات مشابهة لتقنية WebSocket، ولكنها من نوع الاتصال المباشر بين نقطتين مع تحكم دقيق في الموثوقية والترتيب. وهو مفيد للمحادثات المرئية، ومشاركة الملفات، ومزامنة حالة اللعبة، أو التعاون في الوقت الفعلي. صيغة البرنامج مألوفة. dataChannel.send() y onmessage في جهاز الاستقبال.
الإشارات: "الرابط" الذي لا تحدده تقنية WebRTC
سوء فهم شائع: WebRTC لا يشمل اللافتاتيحتاج بروتوكول RTCPeerConnection إلى تبادل المعلومات، لكنه لا يحدد كيفية القيام بذلك. عليك تحديد ذلك بنفسك، أو يمكن لحزمة تطوير برمجية (SDK) تابعة لجهة خارجية أن تتولى الأمر نيابةً عنك.
يتم إرسال الأزواج عبر الإشارات:
- رسائل التحكم في الجلسة: بدء المكالمة، إنهاء المكالمة، أخطاء.
- معلومات الشبكة: مرشحو ICE (عناوين IP/منافذ مكتشفة).
- بيانات تعريف الوسائط: عروض واستجابات بروتوكول وصف الجلسة (SDP) مع برامج الترميز والحلول وما إلى ذلك.
يتم عادةً تنفيذ هذه اللافتات باستخدام WebSocketsتُستخدم تقنيات مثل Socket.IO وHTTP (الاستقصاء/الاستقصاء المطوّل) وMQTT أو آليات ثنائية الاتجاه أخرى. ومن الأنماط الشائعة جدًا خادم Node.js مع Socket.IO الذي يدير "الغرف" ويعيد توجيه الرسائل نوع النص/JSON بين العملاء:
الخادم:يستقبل create or joinيقوم بإنشاء غرفة إذا لم تكن موجودة، ويدعم ما يصل إلى عميلين (لمكالمة فيديو أساسية)، ويقوم بإعادة توجيه الرسائل. message إلى المقابس الأخرى في الغرفة. أنت مسؤول عن عدم تجاوز الحد الأقصى لعدد المستخدمين أو عن تصميم منطق الغرفة الخاص بك.
زبونعند تحميل الصفحة، يطلب اسم الغرفة (أو يستنتجه من عنوان URL)، ثم يُصدر create or joinاستمع إلى أحداث مثل created, joined, full, ready ويتفق مع الطرف الآخر على بدء المكالمة أو رفضها.
هذا النمط مثالي لـ نموذج أولي أو مشروع جانبييوفر لك خادم إشارات خفيف الوزن يمكنك توسيعه باستخدام المجموعات وموازنات التحميل إذا لزم الأمر.
الصعق، والتحويل، والتجميد: تجاوز جدران الحماية وشبكات NAT دون فقدان السيطرة على نفسك
في عالم مثالي، سيكون المستخدمان دائمًا على شبكات متاحة ويتصلان مباشرةً. أما في العالم الحقيقي، فهناك تقنية NAT، وجدران الحماية، وتقنية CGNAT من مزودي خدمة الإنترنت وشبكات الشركات المتشككة. وهنا يأتي دور ICE، الذي يجمع بين تقنيتي STUN وTURN.
- STUN (أدوات اجتياز الجلسة لتقنية NAT) تسمح للعميل بمعرفة عنوان IP عام ومنفذلا يستجيب خادم STUN إلا بهذه المعلومات.
- منعطف أو دور (التنقل باستخدام المرحلات حول NAT) يعمل كـ خادم الترحيل في حالة عدم وجود طريقة لفتح قناة اتصال مباشرة بين المستخدمين، يمرّ عبر هذه القناة بيانات الصوت والفيديو، مما يستهلك عرض النطاق الترددي للخادم ويكلف مالاً.
- ICE (مؤسسة الاتصال التفاعلي) مسؤولة عن اختبار جميع المرشحين المحتملين (العناوين المحلية، التي تعكسها STUN، ومرحلات TURN) حتى يتم العثور على مسار قابل للتطبيق.
عمليًا، في كائن تكوين RTCPeerConnection الخاص بك، يمكنك إضافة مصفوفة من خوادم الجليد باستخدام عناوين URI الخاصة ببروتوكول STUN/TURN، يتولى المتصفح باقي العمليات. إذا قمت بإعداد بنيتك التحتية الخاصة، فسيتعين عليك نشر خوادم STUN/TURN وصيانتها؛ أما إذا كنت تستخدم حزمة تطوير برمجية (SDK) مثل Agora أو Twilio أو Zegocloud، فهي توفر لك هذه الميزة جاهزة للاستخدام الفوري.
البث المباشر منخفض التأخير: WebRTC مقابل HLS/DASH
عندما نتحدث عن بث مباشر يوجد عالمان متميزان: بروتوكولات HTTP (HLS، DASH) وWebRTC. تعمل بروتوكولات HLS/DASH عن طريق تنزيل مقاطع الفيديو وتشغيلها من جهاز المستخدم؛ وهذا مثالي لقابلية التوسع عبر شبكات توصيل المحتوى (CDN)، ولكنه يُدخل بعض المشاكل. زمن استجابة يصل إلى عدة ثوانٍ (5-30 ثانية بسهولة).
أما WebRTC، من ناحية أخرى، فيستخدم UDP + RTP ويقوم بتسليم الفيديو في وضع "الدفع" من المصدر إلى المشغل، مع أوقات بدء تشغيل قصيرة جدًا وفترات كمون نموذجية أقل من مللي 500 (غالباً حوالي ٢٥٠ مللي ثانية) إذا كانت الشبكة جيدة. ويتحقق ذلك بفضل:
- التحكم في الازدحام مدمج، والذي يقوم بضبط معدل البت والدقة في الوقت الفعلي وفقًا لفقدان الحزم أو الارتعاش أو زمن الاستجابة.
- استخدام برامج الترميز الفعالة (VP8، VP9، H.264؛ وبشكل متزايد AV1) مع تسريع الأجهزة عندما تكون متاحة.
- إمكانية استخدام SVC (ترميز الفيديو القابل للتوسع) بحيث لا يستقبل جهاز الاستقبال إلا الطبقات التي يمكن لشبكته/جهازه دعمها.
ولهذا السبب يُعد WebRTC الخيار الطبيعي لـ المزادات في الوقت الحقيقي، المراهنات الرياضية المباشرة، والتداول، والألعاب التفاعلية، والدعم عن بعد، والتطبيب عن بعد، والفصول الدراسية الافتراضية التشاركية، أو لوحات المعلومات المالية التي لا يمكنها تحمل عدة ثوانٍ من التأخير.
تكمن المشكلة في أن تقنية WebRTC القائمة على الند للند لا تتناسب جيدًا مع آلاف المشاهدين؛ لذلك أنت بحاجة إلى وحدات التخزين المنفصلة، أو خوادم الوسائط، أو المنصات الهجينةوهذا هو بالضبط المكان الذي تأتي فيه حلول مثل Flussonic أو Agora أو ما شابهها.
التوسع خارج نطاق الند للند: وحدات التخزين الصغيرة، وخوادم الوسائط، والبنى الهجينة
في مكالمة فيديو ثنائية، يعمل WebRTC بسلاسة تامة. لكن عند إضافة 10 أو 20 أو 100 مستخدم، تتغير الأمور: إذ يتعين على كل عميل إرسال/استقبال عدة تدفقات، مما يؤدي إلى ارتفاع درجة حرارة معالجه، وتعطل الشبكة. وتظهر هنا ثلاثة أنماط كلاسيكية:
- وحدة التحكم متعددة النقاط (MCU)يستقبل الخادم جميع البثوث، ويدمجها، ثم يرسل بثًا واحدًا لكل عميل. الميزة: استهلاك منخفض لموارد العميل. العيوب: ضغط كبير على الخادم، وضعف في مراقبة جودة البث.
- وحدة التوجيه الانتقائي (SFU)يستقبل الخادم البث المباشر ويعيد توجيهه بشكل انتقائي دون دمجه. يتلقى كل مشاهد البث الذي يحتاجه، ربما بجودات مختلفة. هذا هو النمط الأكثر شيوعًا اليوم لـ مؤتمرات الفيديو متعددة المستخدمين وبث تفاعلي قابل للتطوير.
- بنى هجينة WebRTC + HLS/DASHتُستخدم تقنية WebRTC للاستيعاب والتفاعل، بينما تُستخدم تقنية HLS/DASH للتوزيع على جماهير كبيرة لا تحتاج إلى تفاعل فوري. إنه توازن بين زمن انتقال منخفض للغاية بالنسبة لـ "الممثلين" وقابلية التوسع الهائلة لـ "المشاهدين".
خوادم الوسائط مثل فلوسونيك بينما توفر جهات أخرى البنية التحتية اللازمة: فهي تستقبل بث WebRTC، وتقوم بتحويل ترميزه عند الحاجة، ثم تعيد توجيهه عبر WebRTC إلى عملاء آخرين، أو تحوله إلى بروتوكولات من نوع HLS للتوزيع الجماعي. هذا النوع من البنية التحتية هو ما يجعل تجاوز المكالمات الثنائية ممكناً عملياً دون الحاجة إلى إعادة اختراع العجلة.
حالات الاستخدام النموذجية: مكالمات الفيديو، والبث المباشر، وإنترنت الأشياء، وغير ذلك الكثير
أصبحت تقنية WebRTC منتشرة على نطاق واسع، وربما تستخدمها يوميًا دون أن تدرك ذلك. ومن الأمثلة التي تناسبها بشكل خاص ما يلي... مكالمات الفيديو ومؤتمرات الفيديو:
- مكالمات الفيديو ومؤتمرات الفيديوتعتمد أدوات مثل Google Meet و Jitsi و Slack و Microsoft Teams وغيرها الكثير على WebRTC (جزئيًا أو كليًا) للفيديو والصوت ومشاركة الشاشة.
- خدمات البث المباشرتجمع منصات مثل Twitch و Meta Live و Vimeo Livestream أو أدوات مثل Streamyard بين WebRTC للاستيعاب وتقنيات أخرى للتوزيع الجماعي.
- الدردشة والمراسلة مع مشاركة الملفاتبفضل RTCDataChannel، يمكنك إجراء محادثات فورية، ومشاركة الملفات، ومزامنة الحالة، وما إلى ذلك، دون الحاجة إلى خوادم وسائط مركزية.
- الألعاب السحابية واللعب الجماعيتستفيد خدمات مثل GeForce NOW أو Xbox Cloud Gaming من تقنيات مماثلة للفيديو التفاعلي؛ وتستخدم العديد من ألعاب P2P تقنية WebRTC لمزامنة اللعب.
- إنترنت الأشياء والمراقبةيمكن للكاميرات الذكية، وأجهزة مراقبة الأطفال، وأجراس الأبواب المزودة بكاميرات فيديو، أو الطائرات بدون طيار أن ترسل فيديو في الوقت الحقيقي إلى الأجهزة المحمولة والمتصفحات باستخدام WebRTC.
- التعليم والطب عن بعد: الفصول الدراسية الافتراضية المزودة بلوحات بيضاء واختبارات قصيرة وفيديو ثنائي الاتجاه، أو الاستشارات الطبية عبر الإنترنت حيث يكون زمن الاستجابة والأمان أمراً بالغ الأهمية.
أمان WebRTC: التشفير، والأذونات، وأفضل الممارسات
الأمان في WebRTC ليس ميزة إضافية: إنه جزء لا يتجزأ من النظام. متكامل من التصميمجميع مكونات الوسائط مشفرة، ولا تعمل واجهات برمجة التطبيقات إلا من مصادر آمنة (HTTPS أو localhost)، على الرغم من أنه من المستحسن توخي الحذر. عمليات احتيال عبر مكالمات الفيديو.
- DTLS (أمان طبقة نقل البيانات) يقوم بتشفير البيانات أثناء نقلها.
- SRTP يحمي بروتوكول النقل الآمن في الوقت الحقيقي (Secure Real-time Transport Protocol) الصوت والفيديو بحيث لا يمكن التلاعب بهما أو اعتراضهما بسهولة.
- الوصول إلى الكاميرا والميكروفون يتطلب ذلك إذنًا صريحًا من المستخدم، مع مؤشرات مرئية واضحة (أيقونات، نقاط ملونة، إلخ).
- بما أنه لا توجد إضافات للتثبيت، فإن خطر البرمجيات الخبيثة مُقنّعة في إضافات أو ملفات تنفيذية تابعة لجهات خارجية.
ومع ذلك، عليك الاهتمام بطبقتك الخاصة: استخدم بروتوكول HTTPS في جميع أنحاء النظامراجع الأذونات التي تطلبها، وحافظ على تحديث المتصفحات والمكتبات، ولا تهمل أمان خادم الإشارات الخاص بك أو واجهات برمجة تطبيقات REST الخاصة بك.
تقنية WebRTC مقابل التقنيات الأخرى: VoIP وWebSockets والمنصات الاحتكارية
إذا كنت قادمًا من عالم تقنية VoIP التقليدية، فستكون على دراية ببروتوكول SIP، وأنظمة PBX، والهواتف البرمجية، والخوادم باهظة الثمن. أما تقنية WebRTC فتغير هذا النموذج: إذ لا تحتاج إلى مطالبة المستخدم بتقديم أي معلومات. عميل سطح المكتب لا حاجة إلى أجهزة محددة؛ يكفي متصفح وخادم إشارات بسيط نسبيًا.
مقابل بروتوكول نقل الصوت عبر الإنترنت التقليدييُخفف WebRTC العبء على البنية التحتية الأساسية ويفتح المجال أمام التطبيقات المدمجة مباشرةً في الويب. في كثير من الحالات، يمكنك إعادة استخدام نظام SIP الخلفي الخاص بك من خلال بوابات تُترجم الإشارات إلى WebRTC.
Respecto ل WebSocketsينبغي النظر إليهما على أنهما متكاملان: فهما مثاليان للإشعارات، والمحادثات الخفيفة، أو تحديثات الحالة، ولكنهما غير مناسبين للوسائط المتعددة المكثفة. تم تحسين WebRTC لـ الصوت/الفيديو في الوقت الفعليمع التحكم في الازدحام، وبرامج الترميز، ومخزن مؤقت للارتعاش، وما إلى ذلك. عمليًا، تستخدم العديد من المشاريع WebSockets للإشارة وWebRTC لنقل الوسائط.
إذا قارنتها بمنصات مثل Zoom أو GoToMeeting أو WebExيكمن الاختلاف في النموذج: فهذه الأدوات حلول مغلقة، وغالبًا ما تتطلب تطبيقات سطح مكتب إلزامية ونظامًا خلفيًا خاصًا. أما WebRTC، فهو تقنية أساسية؛ يمكنك بناء "اجتماع مصغر" خاص بك عليه أو دمجه مع الخدمات التي تستخدمه بالفعل (مثل Google Meet أو Microsoft Teams).
التطوير باستخدام WebRTC: التعقيد الحقيقي والمزالق الشائعة
على الرغم من أن واجهات برمجة التطبيقات تبدو بسيطة نظرياً، إلا أن تطبيق WebRTC من الصفر أكثر تعقيداً. سيتعين عليك التعامل مع ما يلي:
- لافتات مخصصةتصميم الرسائل والغرف وإدارة عمليات إعادة الاتصال وإعادة المحاولات والأخطاء.
- إدارة ICE/STUN/TURNنشر الخوادم، ومراقبة استخدام TURN (الذي يستهلك النطاق الترددي)، وضبط مهلات الاتصال.
- جودة الخدمة (QoS): تعديل معدلات البت، والتعامل مع الشبكات غير المستقرة، والتفاوض على برامج الترميز، واكتشاف متى يتدهور الاتصال والتفاعل معه.
- تصاعدت: الانتقال من نظام P2P البسيط إلى المجموعات، ثم إلى مئات المستخدمين، وإدخال وحدات SFU أو خوادم الوسائط دون الإخلال بالتصميم الأصلي.
- التوافق بين المتصفحاتعلى الرغم من أن الوضع جيد، إلا أنك ستجد بعض الفروقات الدقيقة. استخدم adapter.js لا يزال يُنصح به بشدة.
في مشروع جانبي صغير، قد يكون إعداد خادم Node باستخدام Socket.IO وSTUN عام كافيًا للمكالمات الفردية أو للمجموعات الصغيرة جدًا. ولكن إذا تطورت فكرتك واحتجت إلى حشد كبيرسواء تعلق الأمر بمراقبة الجودة الدقيقة، أو التسجيلات، أو التحليل، أو النسخ، أو تحقيق الدخل، فسيتعين عليك قريبًا التفكير في أو دمج خادم الوسائط الخاصةأو التحويل إلى مزود متخصص.
شبكة توصيل المحتوى (CDN) في الوقت الفعلي مع حزم تطوير البرامج (SDKs): أغورا، تويليو، موكس، زيغوكلاود...
خدمات مثل أغورا، تويليو، مكس، زيغوكلاود أو تقنيات مماثلة تبني طبقة قيمة فوق WebRTC توفر عليك شهورًا من العمل ومتاعب لا حصر لها:
- يقدمون لك شبكة إعلامية عالمية مع وحدات SFU موزعة حول العالم، ومحسّنة لتقليل زمن الاستجابة.
- خلاصة الصعق/الانعطاف، الإشارة، إعادة المحاولات، وإعادة الاتصال وإدارة الشبكات المعقدة.
- وهي تتضمن مجموعات تطوير برمجية (SDKs) جيدة الصيانة لـ الويب، iOS، أندرويد، React Native وغيرها من الأطر.
- يقدمون خدمات إضافية مثل التسجيل والبث عبر بروتوكول RTMP/HLS، الإشراف، والإحصائيات في الوقت الفعلي، وضوابط الجودة، وأدوار المستخدمين (المضيف، والجمهور، والمتحدث)، إلخ.
إن التكلفة، كما تتوقع على الأرجح، هي المشكلة الرئيسية: إذا كان لديك ولو القليل من المال دقائق عديدة من الفيديو أو، مع وجود عدد كبير من المستخدمين المتزامنين، ترتفع الفاتورة بشكل كبير. علاوة على ذلك، تصبح معتمداً على منصتهم وعلى أسعارها أو تغييرات واجهة برمجة التطبيقات (API).
في وضعك المحدد، مع خبرة قوية في جافا سكريبت في الوقت الحقيقييُعدّ البدء باستخدام حزمة تطوير برمجية (SDK) خيارًا منطقيًا لتسريع عملية التطوير، والتحقق من صحة المنتج، والتعرف على نموذج غرفه، وأدواره، ودورة حياة تدفق البيانات، وإدارة حالته. لاحقًا، إذا حقق المشروع نجاحًا وأصبح التكلفة عاملًا مهمًا، يُمكنك نقل أجزاء من الحل تدريجيًا إلى منصة أكثر قوة. بنية WebRTC الخاصة أو الاعتماد على خادم وسائط من نوع Flussonic للتحكم في طبقة التوزيع.
أفضل الممارسات والأدوات لتصحيح أخطاء WebRTC
لتجنب الضياع في متاهة WebRTC، يُنصح بالاعتماد على الأدوات الموجودة بالفعل في المتصفحات والنظام البيئي:
- الكروم: // webrtc-internals (o حول:webrtc (في متصفح فايرفوكس): لوحة تحتوي على إحصائيات مفصلة للاتصالات، ومعدلات نقل البيانات، وفقدان الحزم، وبرامج الترميز النشطة، وما إلى ذلك.
- adapter.js: برنامج وسيط يتم صيانته من قبل المجتمع يعمل على تلطيف الاختلافات بين المتصفحات والإصدارات.
- test.webrtc.org: للتحقق من توافق الكاميرا والميكروفون والشبكة والتوافق العام على الجهاز.
- عينات رسمية على الرابط webrtc.github.io/samples: أمثلة على القيود، اتصالات النظراء، قنوات البيانات، مشاركة الشاشة... مفيدة جدًا لنسخ الأنماط.
من المستحسن أيضاً تنظيم الكود من خلال الفصل الواضح بين طبقة الإشارة (المقابس، الغرف، الرسائل) من طبقة تقنية WebRTC النقية (إنشاء الاتصالات، وإدارة التدفق، ومعالجات الأحداث). يتيح لك هذا استبدال خادم الإشارات أو خادم الوسائط دون إعادة كتابة منطق العميل بالكامل.
مع وضع كل ما سبق في الاعتبار، بالنسبة لمشروع جانبي في بدايته وتقدر فيه قيمة كبيرة... وقت التطوير كما التكلفة متوسطة الأجلتتمثل الاستراتيجية الأكثر توازناً عادةً في البدء بـ SDK في الوقت الحقيقي يعتمد على WebRTC والذي يسمح لك بالتكرار بسرعة في React/React Native، واستيعاب كيفية تعاملها مع الأدوار والجلسات ودورة حياة البث والحالات المباشرة، وفي الوقت نفسه التعمق أكثر في WebRTC "من خلال الواجهة" (getUserMedia، RTCPeerConnection، RTCDataChannel، الإشارة باستخدام Node+Socket.IO، STUN/TURN، SFU) حتى لا تكون مرتبطًا إلى الأبد بمنصة واحدة وتكون قادرًا على الانتقال إلى حل أكثر تخصيصًا عندما يبرر المنتج ذلك.