أنشأت تطبيق Instant Messenger بالكامل على @Cloudflare. استغرق الأمر يوما واحدا، 3 ملفات، 4 موارد... وهي جاهزة للتوسع من 0 إلى ملايين. → الموظف للتحقق والتوجيه قاعدة بيانات D1 → تخزين المستخدم/التمرير ملف المستخدم → وأصدقائه المحادثة → الرسائل اكتب المدونة ردا، لكن لمحة سريعة هنا: جعلت مكتبة Cloudflare/Actors هذا الأمر سهلا للغاية من خلال خصائص الاستمرار (persist خصائص)، وإدارة اتصال منفذ الويب السهلة، وإرسال الرسائل لجميع المستمعين. لكن ماذا فعل كل قطعة؟ المصادقة والتوجيه (عامل + D1) جميع الطلبات تأتي عبر العامل إما مصادقة أو لا. إذا لم تكن المصادقة، فإن الإجراءات المتاحة هي تسجيل الدخول أو التسجيل. عند المصادقة، يمكنه تمرير الطلب إلى أي من كائناتنا المتينة (المستخدم أو المحادثة) لإنشاء اتصال منفذ ويب. جميع معلومات المصادقة الخاصة بالمستخدمين مخزنة في قاعدة بيانات D1 (احتفظت بالجميع CF في هذا المثال). خدمة المستخدم (الكائن الدائم) عرض قائمة الأصدقاء لدينا يتصل مباشرة بأداة Durable Object الخاصة بالمستخدم عبر منفذ الويب. عندما نقوم بتحديث حالتنا نرسل رسالة إلى مدير الإرسال الخاص بنا والذي يمكنه بعد ذلك البث عبر RPC إلى موظفي إدارة أصدقائنا وتحديد ما إذا كانوا متصلين بالإنترنت لإرسال رسالة عبر الإنترنت لتحديث مباشر. هنا نخزن أيضا قائمة أصدقائنا في قاعدة بيانات SQLite مخصصة لمستخدمنا. خدمة المحادثة (الكائن الدائم) كل محادثة فردية بين مستخدمين تحصل على نسخة DO خاصة بها. مسؤوليته الوحيدة هي تخزين الرسائل، وإرسال الإشعارات (عبر المقابس) عند إرسال رسائل جديدة، وإرسال إشعار عندما يبدأ المستخدم بالكتابة حتى نتمكن من رؤية "الشخص يكتب..." ملخص; بناء تطبيقات للمتعة من أجل إعادة عيش ذكريات الطفولة الحنينية هو... يستحق ذلك.