عندما تسمع كلمة «بوت»، غالباً ما تتخيل شيئاً بسيطاً: ترسل أمراً، فيرد عليك البوت. لكن هذه الصورة أصبحت قديمة نسبياً. البوت الحديث يمكن أن يكون واجهة لنظام كامل يعمل في الخلفية. قد ترسل له ملفاً، فيعالجه خادم خارجي. قد تطلب منه البحث في قاعدة بيانات. قد يتصل بواجهة API. قد يستخدم نموذج ذكاء اصطناعي. وقد يعرض لك واجهة تفاعلية كاملة دون أن تغادر Telegram. وهنا تصبح الفكرة أكثر إثارة: **أنت لا تتعامل فعلياً مع البوت، بل تتعامل مع نظام كامل عبر البوت.** ## ماذا يحدث خلف الرسالة؟ لنفرض أنك أرسلت إلى بوت: > «لخّص هذا الملف.» ما يبدو للمستخدم كرسالة واحدة قد يمر خلفها بعدة مراحل: ```text Telegram ↓ Bot ↓ Backend ↓ File Processing ↓ AI / External API ↓ Database ↓ Bot ↓ Telegram ``` المستخدم لا يرى أياً من ذلك. هو يرى فقط: > تم تجهيز الملخص. وهذا أحد الأشياء التي تجعل بناء البوتات مثيراً من الناحية الهندسية. الواجهة بسيطة، لكن النظام الذي يقف خلفها قد يكون معقداً جداً. ## لماذا Telegram تحديداً؟ لأن Telegram لا تتعامل مع البوتات على أنها مجرد حسابات آلية ترد على النصوص. توفر المنصة Bot API، وأزراراً تفاعلية، وواجهات Web Apps، وإمكانية التعامل مع الملفات، والأوامر، والمجموعات والقنوات وغيرها. وهذا يسمح للمطور ببناء تجربة تتجاوز فكرة «أرسل أمراً وانتظر الرد». يمكن مثلاً أن تبدأ العملية بزر: **📚 المكتبة** ثم تختار: **🔎 بحث** ثم تختار كتاباً. ثم تنفذ عملية معينة. كل ذلك من داخل Telegram. وبالنسبة للمستخدم، تبدو التجربة بسيطة. لكن خلفها يمكن أن توجد قاعدة بيانات، وخادم، ونظام صلاحيات، وواجهات API، وطوابير مهام، وخدمات ذكاء اصطناعي. ## البوت كواجهة Microservice هنا تبدأ الفكرة التي نستخدمها في سديم. بدلاً من بناء كل شيء كتطبيق واحد ضخم، يمكن أن تكون لديك خدمات مستقلة: ```text شبكة سديم │ ┌───────┼────────┐ ↓ ↓ ↓ AI Bot Books Bot Tools Bot │ │ │ └───────┼────────┘ ↓ Backend ↓ Database ``` كل بوت يمكن أن يكون متخصصاً في وظيفة معينة. لكن الخدمات الموجودة خلفه يمكن أن تتشارك نفس البنية التحتية. وهذا يجعل البوت أشبه بـ **واجهة دخول إلى خدمة**، وليس الخدمة نفسها. ## المشكلة الحقيقية ليست في البوت كتابة بوت يرد على رسالة ليست الجزء الصعب. الجزء الصعب يبدأ عندما يصبح لديك مستخدمون حقيقيون. ماذا يحدث إذا أرسل 100 شخص ملفات في نفس الوقت؟ ماذا لو استغرقت معالجة الملف 30 ثانية؟ ماذا لو فشل API؟ ماذا لو انقطع الاتصال؟ ماذا لو أرسل المستخدم الطلب مرتين؟ ماذا لو احتجنا إلى حفظ حالة المستخدم؟ هنا تنتقل من: **بوت** إلى: **نظام موزع صغير.** وتبدأ الحاجة إلى أشياء مثل: * Redis * Queues * PostgreSQL * Rate Limiting * Workers * Caching * Logging * Monitoring * Authentication وهنا تحديداً تصبح هندسة البوتات ممتعة. ## لماذا نبني البوتات داخل شبكة سديم؟ لأننا لا ننظر إلى البوت كمنتج منفصل. ننظر إليه كإحدى الواجهات التي يمكن للمستخدم من خلالها الوصول إلى خدمات الشبكة. قد تستخدم الخدمة من موقع سديم. وقد تستخدم خدمة أخرى من خلال بوت Telegram. وقد تكون هناك خدمة ثالثة تعتمد على الذكاء الاصطناعي. الواجهة تتغير، لكن النظام الذي يقف خلفها يمكن أن يبقى واحداً. وهذا يقود إلى فكرة أكبر: **ليس المهم أين تستخدم الخدمة، بل كيف صُممت الخدمة من الأساس.** ## البوتات مجرد البداية عندما يصبح البوت متصلاً بقاعدة بيانات، وذكاء اصطناعي، وواجهات API، ونظام مهام، ومستخدمين حقيقيين، فإنه يتوقف عن كونه «بوتاً» بالمعنى البسيط. يصبح تطبيقاً صغيراً يعيش داخل منصة أخرى. وهذا هو الجانب الذي يجعلنا نهتم ببناء البوتات في شبكة سديم: ليس لأننا نريد إضافة المزيد من البوتات. بل لأننا نريد معرفة: **إلى أي مدى يمكن دفع فكرة التطبيق الذي لا يحتاج منك إلى فتح تطبيق جديد أصلاً؟**