بناء منتج واجهته خيط محادثة

أغرب مراجعة تصميم شاركت فيها لم يكن فيها ولا شاشة واحدة. «الواجهة» موضع النقاش كانت خيط محادثة: قائمة غنية، وحفنة قوالب رسائل، ولوحات تطبيق مصغّر تُفتح داخل الحوار. بنيتُ خلفية منتج بحث عقاري عاش بالكامل داخل LINE — يكتشف المستخدمون القوائم، ويحفظون المفضلة، ويحجزون جولات معاينة دون تثبيت تطبيق أو فتح تبويب متصفح بالمعنى المعتاد. أقنعني العمل عليه بأن هندسة منصات المحادثة انضباطٌ خلفي يرتدي زيّ الواجهات.

المنصة هي واجهتك الأمامية — بشروطها هي

تحلّل سطح المنتج إلى ثلاث بدائيات، لكلٍّ تبعاتها الخلفية:

• القائمة الغنية — شبكة أهداف اللمس المثبتة أسفل المحادثة — كانت شريط التنقل. كل مدخل يقفز إلى تدفق بوت أو عرض تطبيق مصغّر. تصميم التنقل هنا إعدادات لا كود، لكن الخلفية هي التي تعرّف كل وجهة.
• تدفقات البوت تولّت التفاعلات السريعة: رسائل تُوجَّه بالكلمات المفتاحية تدخل، وردود قوالب تخرج. تصوّر كل تدفق مسارًا وخلفه آلة حالات صغيرة.
• تطبيقات LIFF المصغّرة (عروض الويب المضمّنة في المنصة) حملت كل ما هو نموذجي — مرشحات البحث، المقارنات، تقويمات الحجز. من منظور الخلفية هذه عملاء ويب عاديون: كشفت خدمتنا قرابة ستين نقطة REST، واستهلكتها التطبيقات المصغّرة كما تفعل أي SPA.

الرؤية الهندسية أن الثلاثة تتشارك نموذج هوية خلفيًا واحدًا، وهناk يبدأ العمل الحقيقي.

الهوية: تحقق، لا تثق

يصل التطبيق المصغّر حاملًا رمز هوية أصدرته المنصة. الإغراء أن تقرأ منه معرّف المستخدم وتمضي. القواعد التي أبقت هذا آمنًا:

1. تحقق من الرمز على الخادم، في كل مرة. سلّمنا رمز العميل إلى نقطة تحقق المنصة وحللنا المستخدم من الملف المتحقق منه — والتحقق المحلي من التوقيع مقابل مفاتيح المنصة المنشورة هو الطريق الشرعي الآخر. في الحالين، ادعاءات SDK جهة العميل وسيلة راحة، لا مرجعية.
2. اربط هوية المنصة بسجل مستخدم خاص بك، يُنشأ عند أول تواصل. ما جرى في بقية النظام كان معرّفنا الداخلي لا معرّف المنصة — وهو ما أتاح لاحقًا مطابقة المستخدمين عبر البوت والتطبيقات المصغّرة ونظام إدارة عقارات خارجي دون أن يتسرب معرّف المنصة إلى كل جدول.
3. أحداث الـ webhook تنال الارتياب نفسه: تحقق من التوقيع على كل حدث وارد، ومعالجات مكتوبة لتكون آمنة عند إعادة التشغيل، لأن المنصة قد تعيد التسليم.

لا شيء من هذا OAuth غريب — لكن منصة المحادثة تسلّمك ثلاثة أسطح دخول (webhook، تطبيق مصغّر، وAPI البوت)، والانضباط هو جعلها تلتقي على مسار هوية واحد بدل ثلاثة.

رسائل Flex: عرض من جهة الخادم، نسخة JSON

خرجت نتائج التوصيات والبحث أشرطةَ بطاقات Flex Message — رزم بطاقات قابلة للتمرير تُعرض أصليًا في الخيط. بناؤها جيدًا شعر تمامًا كأنه server-side rendering:

• الخلفية تؤلف العرض. البطاقة وثيقة JSON (صورة، عنوان، شريحة سعر، أزرار أفعال) تُجمَّع لكل مستخدم. لا كود عميل يُرقّع لاحقًا — ما ترسله هو ما يبقى، إلى الأبد، في ذلك الخيط.
• كل زر رابط عميق بنيّة. أزرار البطاقات فتحت عرض LIFF عند قائمة بعينها (وتنقل جهة البوت ركب رسائل مطابَقة بالكلمات المفتاحية)، فعرفت الخلفية دائمًا أي بطاقة ولّدت الضغطة — قصة التحليلات تُصمَّم داخل الرسالة، وإلا فلن توجد.
• القوالب تحتاج انضباط إصدارات. الرسائل القديمة لا يُعاد عرضها حين يتطور تنسيقك؛ الخيط تاريخ ثابت لكل نسخة قالب شحنتها يومًا. جمعنا تأليف القوالب في وحدة واحدة تُعامل كعقد عام.

نقطة الثبات تستحق التوكيد: في تطبيق ويب تُصلح الواجهة فيحصل عليها الجميع. في خيط محادثة، لا يمكنك إصلاح إلا المستقبل. نالت طروحات تنسيقات الرسائل الحذر المخصص عادةً لترحيلات قواعد البيانات.

أين سكن المنطق فعلًا

بقيت التطبيقات المصغّرة رقيقة لأن المشاكل الممتعة — من هذا المستخدم، ماذا تحمل هذه البطاقة، ماذا يحدث عند هذه الضغطة — كانت كلها أسئلة جهة الخادم. هذا الانقلاب هو الخلاصة. على هذه المنصة، امتلك فريق الخلفية تجربة المستخدم عمليًا: كمون الاستجابة يُحَس بوصفه «التطبيق بطيء»، وتأليف الرسائل هو التصميم البصري، وعطل الـ webhook واجهةُ متجرٍ مظلمة.

إن كنت تقيّم بناء منتج محادثة-أولًا: ضع قيود المنصة في الميزانية مبكرًا (حدود حجم القوالب، حصص المراسلة، دلالات تسليم الـ webhook)، ومركز التحقق من الهوية من اليوم الأول، وعامل كل قالب رسالة كاستجابة API ذات إصدار. غياب الواجهة التقليدية لا يمحو عمل الواجهة — بل ينقله إلى طبقة الخدمات، حيث يمكن اختباره على الأقل.