السلام عيكم ورحمة الله وبركاته
كيف حال أعضاء منبر حسوب؟
أنا بصدد برمجة تطبيق ويب وهو عبارة عن موقع تواصل اجتماعي واحتاج فيه لنظام اشعارات و كذلك تحديث تلقائي للمنشورات حينما يحدث تغير في قاعدة البيانات
أرجو من الاخوة ان يفيدونا، قرأت عن تقنيات webSockets و SSE و long polling
ما هي اقوى تقنية و أفضله؟ و سؤال اخر ماهي يا ترى القنية المستخدمة في موقع facebook
ليست لي خبرة في التقنيات المذكورة ، لكن بالنسبة لعمل نظام إشعارات فيمكنك عمل جدول في قاعدة البيانات و عند عمل لايك مثلا يتم تخزين الإشعار في الجدول و يظهر للمستخدم.
و بالنسبة لتحديث تلقائي للصفحات او المشنورات فيمكنك إستعمال AJAX.
شكرا أخي ،لكن اظنني لم اطرح سؤالي جيدا فأنا مشكلتي في كيفية جلب التحديثات من قاعدة البيانات ، ولا اظن ajax حلا لها
تستخدم الـAjax في الـlong polling بشكل متكرر من صفحة تعالج الأمر من قاعدة البيانات دائمًا ما أقول عن ذاك الحل أنه غبي أحيانًا في استخدامه، يفضل استخدام SSE أو WebSockt الأخير لا تحتاجه لأنك لن ترسل الردود إلى الخادم، شاهد أيضًا هذا المقال:
ال AJAX بالتاكيد ليس الحل المثالي لكنه الشائع و الأكثر إستخدام و مناسب للمواقع الصغيرة و المتوسطة.
نعم هو الشائع، لكنه ليس مناسبًا للمواقع الصغيرة -أكثر-، عملية بداية الطلب عمومًا تأخذ الكثير من الوقت/الموارد في الكثير من خوادم الويب ومع الكثير من الطلبات يصبح الأمر كارثيًا، لذا SSE أفضل في هاته الحالات.
ال SSE تحتاج الى long execution time وقد لايكون متاح في الاستضافات المشتركة غالباً في المواقع الصغيرة .. وكذالك ال websockets تحتاج تشغيلها كخدمة على السيرفر المشترك وقد لايكون متاح .. لذالك الlong polling عبر الـ AJAX هو الخيار الامثل لكل المشاريع الصغيره من حيث سرعه التطبيق والامكانيه :) ..
استخدمتُ استضافة مجانية من قبل وكانت تسمح بتغيير ذلك في ملف php.ini أغلبها تسمح بذلك من الدالة set_time_limit(0) مثلًا، أستبعد الـWebSocket تمامًا :)
شاهد هذا السؤال على أكاديمية حسوب والرد عليه عن هاته الثلاث:
فيسبوك يستخدمون long polling لكنه ليس الأفضل دائمًا.
في حالتك SSE، لأنّ WebSocket سيكون أصعب بدون داعي، لن ترسل ردودًا إلى الخادم، وبالنسبة للسرعة فلن يكون هنالك فرق كبير أو صغير(غالبًا)، الإختلاف في السرعة في طريقة كتابتك للبرمجية.
حالة نظام الدردشة WebSocket بكل تأكيد الـSSE لا يدعم إرسال ردود إلى الخادم الـWebSocket يدعم التحدث معه، رأيتُ بعض الحلول مع HTTP/2 لكنها ما تزال حديثةً حتى الآن.
لقد اشكل علي الامر في عرض المنشورات
ساستخدم تقنية SSEف ي عرضها ، المشكلة في تنسيق العرض ، هل اضعه في صفحة العرض ام في صفحة المعالجة ؟
سؤال اخر هل SEE تعتمد على الوقت الحقيقي م تستغرق مدة معينة
هل اضعه في صفحة العرض ام في صفحة المعالجة ؟
لم أفهم ما تقصد هنا،
سؤال اخر هل SEE تعتمد على الوقت الحقيقي م تستغرق مدة معينة
المفترض الوقت الحقيقي لأن الإتصال يكون مفتوحًا وأي إرسال سيصل إلى العميل في نفس اللحظة، المشكلة هي شيفرتك التي ستتابع التحديثات، والأخرى التي ستعالجها.
انا سيء في الشرح ولكن يمكنني القول انها عبارة عن عملية لارسال اشعارات اعتمادا على device id دون الحاجة لارسال request للسرفر
يعني يمكن ارسال معلومات للتطبيق مباشرة باستخدام خدمات مقدمة من جوجل GCM وبالنسبة للابل Apn يمكنك الاطلاع عليه من هنا
او البحث في جوجل
هذه تعتمد على أن الموقع هو من يرسل التحديث إلى خوادم جوجل الذي بدوره يرسل التحديث إلى هاتف المستخدم.
هذا الخدمة مخصصة لإرسال التنبيهات إلى هواتف المستخدمين بدون إلى الحاجة إلى تنصيب تطبيق أندرويد عندهم.
لننظر قليلًا خادم الموقع -> خادم جوجل -> المستخدم!.
هذا شيء وما يريد شيء أخر صديقي :)
هذا شيء وما يريد شيء أخر صديقي :)
صحيح و لكن لو اضافها الى موقعه الاجتماعي ستضيف ميزة اضافة وهي ظهور التنبيهات حتى بعد اغلاق الموقع .
نعم، هذه إضافة للموضع شكرًا @megasoft صاحب الموضوع كان يقصد الإشعارات في الموقع على المتصفح.
هناك سحر يسمى سحر الXMPP العجيب ، وقد استخدم من طرف جمعية الشر العالمية WhatsApp
تفضل
أوه ، أجل ذلك خليط سحري لكنه يحتاج إلى شيء يتفاعل معه.
لم أنتبه آسف.
ماذا عن SPDY -ليس مقبس أؤكد لك-
HTTP هو بالنهاية مقبس :) لكن ينغلق من جهة الخادم بعد رده SPDY سرعان ما تحول إلى HTTP/2 تحدثنا عنه هنا وهو رائع عندما جربته، لكنه ما زال جديدًا، وهو مقبس آخر كل شيء في الشبكة مقابس مقابس :)
شاهد هذه الصفحة:
وهذه الشيفرة أفضل ما وجدته الآن- لتفهم كيف يجري اتصال HTTP عادي:
جميلة جدا، ممكن تفصل أكثر عن السحر XMPP :) كيف تعمل عليه الاشعارات؟
مشلكتي لدي مشروع يقدم اكثر من 1000 ريكوست لتظهر النتائج realtime على صفحة المستخدم من قاعدة البيانات و ليس فقط شيفرات هل من حلول لفك ضغط السيرفر و عدم حدوث buffer للذاكرة + الحفاظ على السيرفر لان مصاريفه غالية علي كثيرا.
استخدم WebSocket هو الأنسب والأسهل في حالتك، مقبس بين الخادم والمتصفح يتراسلون بين بعضهم دونما انقطاع في إتصال واحد، إن تستخدم socket.io سيسهل عليك الأمر.
لا تنسى أنا اقصد 1000 ريكوست في مدة ثانية الى ثانيتين اضافة الى العرض في صفحة كل من 100 مستخدم لأَنِّي اعمل على طلبات من مواقع و سيرفرات من هنا هناك سيثقل حتما.
Websocket جيد، و لم اجرب socket بعد ممكن تفصل لي حلول معينة لتقسيم الطلبات
شكرًا لك
على العموم استخدم الـCache بقدر الإمكان لكل ما لن يتحدث من البيانات الكاش من جهة الخادم أيضًا، استخدم HTTP/2 للطلبات لكي تجعل الطلب واحد لكل مستخدم لجلب مصادر الويب، تأكد من أمور مثل ضغط الطلبات وكل هاته الأمور، أيضًا جرب الـWebSocket وأخبرنا بكيف أصبح الأمر معك.
بقدر الإمكان لكل ما لن يتحدث من البيانات
أي عنصر لن يحتاج إلى تحديث مثل ملفات CSS، JS صور ثابتة هذه الملفات لا تحتاج إلى تحميلها إلا في أول مرة.
لا شكر على شيء صديقي لم أفعل شيء.
أي عنصر لن يحتاج إلى تحديث مثل ملفات CSS، JS صور ثابتة هذه الملفات لا تحتاج إلى تحميلها إلا في أول مرة.
الا تعد هذه الامور بديهية عند العمل على مشاريع اونلاين . اعتقد اطر عمل جافا سكربت كلها لا تقوم بتحديث الصفحة في تلك الحالة . المعضلة تبقى في الاتصال الخام (إن صح القول) إرسال و استقبال بيانات بين الزائر و السيرفر في الوقت الحقيقي ! أعتقد تطبيقات الدردشة لسطح كانت تعتمد على هذا المبداء اساساً .
السبب أنها لا تسمح بصلاحيات التصنت على منفذ في الخادم، يوجد بعض الحلول الممكن تقديمها من الاستضافة لكن حتى الآن قليل ما ستجد هذا يوجد بعض الاستضافات تسمح به، إن كان هدفك إرسال التنبيهات SSE ستعمل كمثلها، أو Long Polling كحل سائم، إن أردتَ بناء نظام تراسل(شات) عليك التغيير وإلا ستنشيء صفحتين صفحة تستقبل الرسائل وتخزنها، وصفحة أخرى تعيد إرسالها -طبعًا أتحدث عن PHP وأخواتها-، وهذا حلٌ ممللٌ وغير عملي.
:) أصبت بالدوار -امزح فقط-
ما الحل الانسب اذن أيها الاخوة و يجب أن يكون سريعا و آمنا و مدعوما من الاستضافات و المتصفحات؟
الحلول كثيرة، لا ادري قوة و طاقة مشروعك لاختيار احدى التطبيقات لتجربتها.
ابدأ ب Ajax & database request لتظهر على الصفحة. و انصحك مباشرة بما ذكره لك الأخ عبر طلبات html5 SSE
التعليقات