بنيناه نظام مطاعم متكاملاً
من الصفر — أكشاك، POS، وكل شيء

يواجه برنامج المطاعم مشكلة لا يتحدث عنها أحد بصوت عالٍ بما فيه الكفاية. تم بناء معظمها على شكل قطع، من قبل بائعين مختلفين، في أوقات مختلفة، دون منطق مشترك بينهم. نقطة البيع الخاصة بك لا تتحدث مع نظام المخزون الخاص بك. يعمل كشكك على بيانات مختلفة عن تلك التي تعرضها شاشة مطبخك. تقوم لوحة معلومات مكتبك الرئيسي بسحب الأرقام التي مضى عليها أربع ساعات بالفعل. وينتهي بك الأمر بمجموعة من الأدوات التي تم تجميعها معًا من خلال العمليات اليدوية، والحلول البديلة للموظفين، وجدول بيانات يقوم شخص ما بتحديثه كل صباح يوم الاثنين.

لقد بنينا Doyfood لأننا أردنا حل هذه المشكلة بشكل صحيح. ليس مع طبقة تكامل أخرى فوق الأنظمة المعطلة الموجودة. من خلال نظام أساسي موحد واحد - قاعدة تعليمات برمجية واحدة، ونموذج بيانات واحد، ومصدر واحد للحقيقة - يتعامل مع كل شيء بدءًا من الكشك الذي يتعامل مع العملاء وحتى لوحة معلومات إدارة المكتب الرئيسي. ونحن نقوم بتشغيله مباشرة في دبي وفرنسا.

إليك ما بنيناه وكيف يعمل.

الهندسة المعمارية: محركان ونظام واحد

ينقسم Doyfood إلى نظامين أساسيين يعملان جنبًا إلى جنب.

الأول هو RMS – نظام إدارة المطاعم. هذه هي طبقة المقر. فهو يتعامل مع البيانات الرئيسية: القوائم، والأسعار، وتكوينات المنتج، والتحليلات على مستوى الأعمال، وأي شيء يحتاج إلى أن يكون متسقًا في كل موقع. إذا قمت بتشغيل خمسة فروع وقمت بتغيير سعر عنصر القائمة، فإنك تقوم بتغييره مرة واحدة في نظام إدارة الموارد (RMS) ويتم نشره. يحصل المديرون على لوحة تحكم مركزية تمنحهم رؤية حقيقية للأعمال، وليست رؤية متأخرة.

والثاني هو OMS – نظام إدارة الطلبات. هذه هي الطبقة التشغيلية في المتجر. فهو يتعامل مع دورة الحياة الكاملة لكل طلب من لحظة تقديم العميل له حتى لحظة مغادرته المطبخ. يتم تشغيله محليًا، وهو ما يهم - لا ينبغي أن يمنع فشل التبعية السحابية مطعمك من تلقي الطلبات.

OMS هو المكان الذي توجد فيه معظم مساحة السطح. إنه يدعم أربع واجهات متميزة: لوحة الإدارة لمديري المتجر، وKiosk للخدمة الذاتية للعملاء، ونقطة البيع للموظفين الذين يتعاملون مع الطلبات المباشرة والعدادات، والواجهة الخلفية التي تربط كل ذلك معًا مع معالجة الطلبات في الوقت الفعلي.

يتواصل هذان المحركان - RMS وOMS - ولكنهما يعملان أيضًا بشكل مستقل. يمكن أن يعمل نظام OMS بدون اتصال مباشر بـ RMS. يعد هذا قرارًا معماريًا متعمدًا، وهو أحد الأشياء التي تجعل Doyfood عمليًا في بيئات المطاعم الحقيقية وليس فقط في الظروف التجريبية.

الكشك: ما بنيناه بالفعل

الكشك هو الجزء الأكثر وضوحًا في Doyfood والقطعة التي تتطلب أكبر قدر من العناية للوصول إلى المستوى الصحيح.

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

تبدو معظم الأكشاك الموجودة في السوق وكأنها مصممة من قبل نفس الفريق الذي صمم ماكينة الصراف الآلي التي تستخدمها في المطار. واجهة المستخدم وظيفية بالمعنى الضيق - فهي تقبل الإدخال - ولكنها ليست سريعة، وليست ممتعة، ولا تعكس العلامة التجارية للمطعم الذي يديرها. إنها محطات عامة ترتدي شعارًا.

لقد بنينا كشك Doyfood ليكون شيئًا مختلفًا. تعمل الواجهة على React 19 مع Tailwind CSS 4 وFramer Motion للتعامل مع الرسوم المتحركة. والنتيجة هي تجربة تبدو أقرب إلى تطبيق المستهلك المصمم جيدًا من محطة المعاملات. يتم تحميل القوائم بسرعة. تدفقات التخصيص واضحة. تأكيد الطلب فوري ولا لبس فيه.

يتصل الكشك مباشرة بالواجهة الخلفية لـ OMS عبر WebSocket، مما يعني أنه في اللحظة التي يتم فيها تقديم الطلب يكون في النظام - بدون تصويت، بدون تأخير، وبدون فجوة بين ما يراه العميل وما يتلقاه المطبخ.

نقاط البيع: مصممة للموظفين، وليس للعروض التوضيحية

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

تم تصميم Doyfood POS مع أخذ ذلك في الاعتبار. الواجهة عالية الأداء — Bun كوقت التشغيل، وHono كإطار عمل للواجهة الخلفية، ويتعامل TanStack Query مع مزامنة البيانات على الواجهة الأمامية. والنتيجة العملية هي أن نقطة البيع سريعة بطريقة مهمة من الناحية التشغيلية: إدخال الطلب سريع، والتعديلات سريعة، والانتقال من أمر إلى آخر دون أي تأخير.

كما أنه يشترك في نفس الواجهة الخلفية لـ OMS مثل الكشك. يدخل الطلب الذي يتم تقديمه في الكشك والطلب الذي يقدمه أحد الموظفين في نقطة البيع إلى نفس قائمة الانتظار، وتتم معالجته بنفس المنطق، ويصلان إلى المطبخ عبر نفس المسار. لا يوجد نظام منفصل للتوفيق في نهاية اليوم.

لماذا دبي وفرنسا

من الواضح أن هذين السوقين لا ينتميان معًا، ولكن بالنسبة لـ Doyfood، فإنهما يعتبران نقطة انطلاق لأسباب محددة.

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

إن فرنسا تمثل تحديا من نوع مختلف. ثقافة المطعم أقدم، كما أن دمج التكنولوجيا في تجربة تناول الطعام هو أكثر إثارة للجدل. لكن المشاكل التشغيلية هي نفسها. الأنظمة المنفصلة، ​​والتسوية اليدوية، وبرامج نقاط البيع التي تم تحديثها آخر مرة بشكل مفيد عندما كان التصميم المسطح لا يزال مثيرًا للجدل. هناك سوق حقيقي لنظام حديث وسريع ومتكامل فعليًا - فهو يتطلب فقط محادثة مبيعات مختلفة عن تلك الموجودة في دبي.

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

المكدس ولماذا اخترناه

تم اتخاذ الاختيارات الفنية وراء Doyfood مع وضع الأداء التشغيلي وسرعة المطور في الاعتبار، وليس متابعة الاتجاه.

Bun هو وقت التشغيل عبر جميع الخدمات الخلفية. إن تحسين الأداء عبر Node.js حقيقي وقابل للقياس - بدء تشغيل بارد أسرع، وتثبيت أسرع للحزمة، وتقليل الحمل على الذاكرة. بالنسبة للنظام الذي يحتاج إلى التعامل مع معالجة الطلبات في الوقت الفعلي في مطعم مزدحم، فهذا أمر مهم.

Hono هو الإطار الخلفي. إنه خفيف الوزن وسريع ويعمل على الكعكة دون احتكاك. لم نكن بحاجة إلى الوزن الكامل لإطار أكبر. هونو يعطينا ما نحتاجه ويبتعد عن الطريق.

يتعامل Drizzle ORM مع طبقة قاعدة البيانات عبر Postgres. إدارة المخطط نظيفة، وأمان النوع مع Zod محكم، ويمنحنا Drizzle Studio مستكشف قاعدة بيانات مرئي كان مفيدًا أثناء التطوير وتصحيح الأخطاء في بيئات الإنتاج.

على الواجهة الأمامية، يوفر لنا React 19 مع Tailwind CSS 4 وFramer Motion مزيجًا من الأداء وجودة الواجهة التي يتطلبها الكشك ونقطة البيع. يعالج TanStack Query حالة الخادم عبر جميع تطبيقات الواجهة الأمامية بتناسق يجعل قاعدة التعليمات البرمجية أسهل في التفكير.

يتم استخدام WebSocket طوال الوقت للاتصال في الوقت الفعلي بين أنظمة الكشك ونقاط البيع والأنظمة المواجهة للمطبخ. يجب أن يظهر الطلب المقدم في الكشك في المطبخ في أقل من ثانية. الاقتراع لا يفي بهذا الشريط. يفعل WebSocket.

تم تصميم النظام بأكمله باعتباره monorepo - مستودع واحد يحتوي على الواجهة الخلفية لـ RMS، والواجهة الأمامية لـ RMS، والواجهة الخلفية لـ OMS، ومسؤول OMS، وكشك OMS، وOMS POS. هذا هو الاختيار المتعمد. الأنواع المشتركة ومنطق التحقق المشترك والأدوات المشتركة عبر جميع التطبيقات الستة. عندما نقوم بتحديث نموذج البيانات، نقوم بتحديثه مرة واحدة. عندما نقوم بإجراء عمليات فحص الكتابة، فإننا نجريها على كل شيء.

ما الذي يتغير بالنسبة لمشغلي المطاعم؟

الحالة العملية لنظام مثل Doyfood ليست معقدة. إذا كنت تدير مطعمًا اليوم ولديك نقطة بيع من بائع واحد، وكشك من بائع آخر، ولوحة تحكم إدارية من بائع ثالث، وكنت تقضي ساعتين كل أسبوع في تسوية البيانات فيما بينهم - فهذه ليست مشكلة تقنية. هذه مشكلة معمارية. والحل ليس تكاملا آخر. إنه نظام تم بناؤه كشيء واحد منذ البداية.

Doyfood هو هذا النظام. يعمل كل من الكشك ونقطة البيع وطبقة إدارة المتجر ولوحة معلومات المكتب الرئيسي على نفس نموذج البيانات، ويتم تحديثه في الوقت الفعلي، دون تسوية يدوية. ينعكس تغيير القائمة الذي يتم إجراؤه في المقر الرئيسي على كل كشك ومحطة نقاط بيع على الفور. يكون الطلب المقدم في الكشك موجودًا في قائمة انتظار المطبخ قبل أن يستلم العميل إيصاله.

نحن على قيد الحياة. نحن نجري في دبي وفرنسا. ونحن نبني الطبقة التالية.