من الصفر إلى بناء Backend Framework خاص بي: تعرفوا على RiserBob

  • zen

مرحباً بالجميع،

من فترة قررت خوض تجربة مختلفة عن بناء التطبيقات المعتادة: قررت تطوير Backend Framework خاص بي باستخدام Bun وTypeScript، وأطلقت عليه اسم RiserBob.

كانت الفكرة أن أبني إطاراً يجمع بين حرية Express.js، وسرعة Elysia، والتنظيم الذي تقدمه NestJS، مع تجربة تطوير بسيطة وممتعة.

ما الذي يقدمه RiserBob؟

  • Modular Architecture لتنظيم المشاريع.
  • Middleware وAuthentication جاهزة.
  • Validation وError Handling.
  • CLI لتوليد Modules وملفات المشروع بسرعة.
  • دعم WebSocket وSocket.IO مدمج في RiserBob.
  • Packages إضافية مثل JWT وCookie وCloudinary.
  • Funny Mode مستوحة من عالم قاع الهامور لإضافة لمسة مرحة ومختلفة أثناء التطوير! 😂

ماذا عن الأداء؟

أجريت مجموعة اختبارات Benchmark قارنت فيها RiserBob مع Gin (Go) وElysia وNestJS وExpress، باستخدام سيناريوهات متعددة مثل Hello World وJSON وCPU-bound وPipelining وStress Testing.

كانت النتائج مختلفة حسب نوع الاختبار، واحتل RiserBob المركز الثالث في الترتيب الإجمالي ضمن المقارنة التي أجريتها.

والأهم بالنسبة لي أن RiserBob حافظ على استقراره ولم ينهَر في أي جولة من جولات اختبارات الضغط التي أجريتها.

لماذا أشارككم هذا المشروع؟

لأنني أؤمن أن بناء الأدوات مفتوحة المصدر تجربة تعليمية وهندسية عظيمة، وأتمنى أن يصبح RiserBob مشروعاً يستفيد منه مطورو TypeScript وBun.

يسعدني سماع آرائكم وانتقاداتكم واقتراحاتكم، خصوصاً من المطورين الذين لديهم خبرة في تصميم Backend Frameworks.

روابط المشروع

  • GitHub:
  • Website:
  • Benchmarks:
  • npm: https://www.npmjs.com/packa...

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

نعم، اختبرت هذا السيناريو بشكل مباشر ضمن اختبارات WebSocket الخاصة بـ RiserBob.

أجريت اختباراً أرسلت فيه 1,000 رسالة/ثانية بحجم 1KB لمدة 20 ثانية، مع عملاء طبيعيين وعملاء بطيئين توقفوا عن قراءة الرسائل.

النتائج كانت مثيرة للاهتمام:

  • العملاء الطبيعيون استقبلوا 200,000 من أصل 200,000 رسالة دون فقدان أو تكرار.
  • العملاء البطيئون استقبلوا 87,099 من أصل 100,000 رسالة، أي فُقدت 12,901 رسالة، رغم أن الاتصالات بقيت مفتوحة.
  • ارتفعت ذاكرة السيرفر من 45.2MB إلى ذروة 133.2MB، ثم انخفضت إلى 47.2MB بعد فترة الخمول.
  • راقبت أيضاً outgoing buffers، ووصلت الذروة إلى 16MB لكل اتصال بطيء.

لم أكتفِ بهذا السيناريو؛ اختبرت أيضاً حالات مختلفة للعملاء البطيئين، منها بطء القراءة، وتوقف القراءة مؤقتاً، واستعادة استقبال الرسائل، بالإضافة إلى حالات انتهت بفصل الاتصال بسبب ping timeout.

هذه الاختبارات كشفت لنا نقاطاً تحتاج إلى تحسين في إدارة Slow Consumers والـ backpressure، لذلك أعمل على جعل هذه السلوكيات قابلة للضبط ووضع حدود اختيارية للـ outgoing buffer لكل اتصال.

شكراً على الملاحظة، لأنها بالفعل من الاختبارات المهمة التي لا تكشفها اختبارات الأداء القصيرة.