تطبيق الميزات الفورية باستخدام WebSockets وأطر العمل الحديثة

الخلاصة السريعة: استخدم WebSockets عندما يجب على الخادم دفع التحديثات فورًا — الطلبات الحية، الدردشة، التتبع، لوحات التحكم. واستخدم الاستطلاع الأبسط (Polling) أو أحداث الخادم المرسلة (SSE) عندما يكون تأخير بضع ثوانٍ مقبولًا. تضيف الميزات اللحظية نحو 30,000–90,000 ريال قطري إلى ميزانية المنتج حسب الحجم، وهي ما يفصل تطبيقًا يبدو حيًا عن آخر يبدو كنموذج جامد.

بعض المنتجات لا تبدو حيّة إلا حين تتفاعل في اللحظة نفسها التي يتغيّر فيها شيء ما. في هيرودوتس نبني هذه التجارب اللحظية في قطاعات شديدة الاختلاف، ويتكرّر النمط نفسه في كل مرة: ما إن تتأخّر المعلومة بضع ثوانٍ حتى يفقد المنتج ثقة مستخدميه. وإليك كيف نتعامل مع ذلك.

ما الذي يُعدّ ميزة لحظية؟

الميزة اللحظية تُحدّث كل شاشة معنية في اللحظة التي يقع فيها الحدث، دون أن يحدّث أحد الصفحة. في Xionys، منصتنا لعمليات الفنادق، تُتتبَّع حالة الغرف لحظياً ليبقى قسم التدبير ومكتب الاستقبال متزامنين دائماً. وفي Heronys، تُتتبَّع المركبات لحظياً ويُرسَل عمّال صفّ السيارات فوراً. وفي Hairaholic، تُطلِق الحجوزات والتعديلات والإلغاءات إشعارات فورية حتى لا يحصل عميلان على الموعد نفسه أبداً. قطاعات مختلفة، والحاجة الأساسية نفسها.

كيف تجعل WebSockets ذلك ممكناً؟

تسأل صفحات الويب التقليدية الخادم «هل من جديد؟» مراراً وتكراراً. أما WebSocket فيُبقي اتصالاً واحداً مفتوحاً ليتمكّن الخادم من دفع التحديثات لحظة حدوثها. هذا التحوّل — من السؤال المتكرر إلى الإخبار المباشر — هو ما يجعل لوحات الغرف الحيّة والإرسال الفوري والجداول اللحظية تبدو فورية لا متأخّرة، وبأعباء أقل بكثير من الاستطلاع المستمر.

لماذا الأمر اللحظي أصعب مما يبدو؟

العرض التوضيحي سهل، لكن الحالات الاستثنائية هي التي تكسر المنتجات. فالاتصالات تنقطع ويجب أن تتعافى بسلاسة، وقد يتصرّف مستخدمان على البيانات نفسها في الوقت نفسه — على Hairaholic أن يمنع وقوع حجزين على المعالِج نفسه في الدقيقة نفسها — والأجهزة تفقد الاتصال في منتصف العملية في ساحة فندق أو في صالون مزدحم. نصمّم لهذه المنطقة الفوضوية منذ البداية، لأنها بالضبط حيث يكسب المنتج اللحظي ثقة مستخدمه أو يفقدها.

اللحظي، بالشكل الصحيح

الميزات الحيّة من أكثر ما نستمتع ببنائه — ومن أقلّه تسامحاً مع الأخطاء. على مدى تسع سنوات من العمل لعملاء في قطر والخليج وخارجهما، تعلّمنا أن نتعامل مع الموثوقية كجزء من الميزة لا كإضافة لاحقة. إذا كان منتجك يحتاج أن يكون حيّاً بحق، فيسعد فريقنا في لوسيل بمساعدتك: [email protected].

WebSockets مقابل Polling مقابل SSE — المقارنة الصريحة

التقنية	زمن الاستجابة	كلفة الخادم	استخدمها في
الاستطلاع (Polling)	ثوانٍ	مُهدِرة عند التوسع	فحوصات حالة بسيطة، وأدوات إدارة منخفضة الحركة
أحداث الخادم المرسلة (SSE)	أقل من ثانية، اتجاه واحد	رخيصة	التغذيات الحية والإشعارات ولوحات القراءة فقط
WebSockets	فوري، اتجاهان	تتطلب إدارة اتصالات	الدردشة والطلبات الحية والأدوات التعاونية والتتبع

أين نستخدم اللحظية في مشاريع قطر

لوحات الطلبات الحية في تطبيق مخبز الغرافة، ولوحات التشغيل في XIONYS، وتتبع طلبات الخدمة في Heronys كلها تدفع التحديثات لحظة حدوثها. معماريًا يُبنى هذا على أسس دليلنا للواجهات الخلفية القابلة للتوسع — فاللحظية ميزة لواجهة خلفية حسنة التصميم، لا إضافة مُلصقة.

How much does a real-time feature cost, and how long does it take?

For the Qatar projects we scope, a first real-time feature usually lands between QAR 30,000 and 90,000 on top of the base product. The spread comes from three things: how many concurrent users must stay connected at once, whether updates must be delivered in order and never lost (a payment or valet dispatch) or can simply be refreshed (a dashboard tile), and whether the mobile app needs to recover cleanly after the phone sleeps or loses signal. A single live-status screen for a few hundred staff sits at the low end; a guest-facing feature with thousands of connections, offline recovery and audit trails sits at the top.

On timeline, expect three to six weeks for the first real-time feature inside an existing app, and longer if the backend was never designed to push events. The work that takes time is rarely the socket itself: it is deciding the event model, adding a message queue so nothing is lost when a server restarts, and testing reconnection on real Qatari mobile networks rather than on office Wi-Fi.

Five questions to answer before you commit to real-time

• Does a delay of five seconds change a decision? If a manager would act differently with a five-second-old number, you need push. If not, polling every 30 seconds is cheaper and simpler.
• Who is on the other end of the update? Staff on a shared dashboard tolerate a spinner; a guest waiting for a car does not. Guest-facing features need the stricter delivery guarantees.
• What happens when the connection drops? Every real-time screen needs an honest “last updated” state and an automatic resync. This is where most rushed implementations fail.
• How many devices at peak, not on average? Hotel check-out at 11:00 or a bakery promotion at Eid sets the number your infrastructure must hold.
• Who owns the backend after launch? Real-time systems need monitoring. Agree on who watches connection counts and error rates in month two, not just at go-live.

Answer those five and the build decision usually makes itself. In Xionys the answer to the first question was an immediate yes: housekeeping cannot act on a room status that is minutes old. In Heronys it was yes for dispatch and no for reporting, so the reports poll while the dispatch board streams. That split is the difference between a system that costs what it should and one that is over-engineered everywhere.

الأسئلة الشائعة