fullStackChatApp
1.0.0
تحذير: هناك القليل من اليسار لإنهاء التطبيق. يحتاج إلى إضافة شاشات تسجيل المستخدم والإشعارات في الخلفية وتحديثات بيانات طلبات الصداقة والأصدقاء الجدد عبر مآخذ.
في الوقت الحالي ، تم تطوير التطبيق لمدة شهر ، وهو شهر مرت به فترات من الوقت في تنفيذ كل متطلبات أساسية.
عند الانتهاء من المتطلبات الأساسية ، ستستمر تنفيذ المتطلبات الجديدة التي تم اكتشافها والمواعيد الأكثر تعقيدًا.
بدأ إنشاء التطبيق برسمات بسيطة للواجهة الرسومية. فقدت هذه الرسومات لهذا السبب لا يمكنني وضعها هنا. يرجى الاطلاع على القسم الأخير حيث يتم عرض صور المشروع.
تم تنفيذ الواجهة الرسومية أثناء استخدام بيانات الاختبار الثابت.
هذا هو المشروع الأول الذي لديه فرق كبير إلى حد بعيد عن المشروع القديم الذي قمت به. لقد جربت بالطريقة الأكثر منطقية والثانية الممكنة لاستخدام أنماط التصميم للحصول على رمز نظيف وحماية منطق الأعمال.
في حد زمني تم تنفيذ التصميم ، التصميم الذي كان لا بد من تغييره قليلاً (فقط الفئات المتعلقة بالرسائل) بسبب قيود الخلية.
لإعطاء تطبيق سريع ومثل ، قررت حفظ الرسائل في ذاكرة الجهاز. للقيام بذلك بطريقة استخدمت أداة Hive ، والتي تعمل كقاعدة بيانات NOSQL محلية.
كحل مثالي ، في كل مرة تأتي فيها الرسائل الجديدة ، سأقوم بحفظها في الجهاز ، وكذلك في ذاكرة الوصول العشوائي بحيث لا يتعين على شاشة الدردشة جعل المستخدم ينتظر. سيتم حفظ الرسالة الأخيرة فقط من التحويلات الموجودة للجهاز في ذاكرة الوصول العشوائي.
كما تجدر الإشارة هنا إلى أنه سيتم تخزين صور ملف تعريف المستخدمين على جهاز المستخدم ، بينما سيتم تخزين عناوين الصور المحلية في ذاكرة الوصول العشوائي.
لإظهار منطق الخادم ، راجع الصورة أدناه.
انظر إلى الصورة ، التي تحاكي جلسة المستخدم الذي يرسل طلب صداقة إلى مستخدم آخر.
تم تقديم المثال لمعرفة متى ستكون هناك حاجة إلى استخدام WebSockets ومتى استخدام API REST.
ستستخدم العمليات في الوقت الفعلي مثل إرسال الرسائل وطلبات الأصدقاء WebSockets بينما ستستخدم عمليات مثل فتح جلسة وتحديث بيانات المستخدم واجهة برمجة تطبيقات REST.
هذا هو القسم الذي يبقى مصقول. مفقود بشكل أساسي هو تحسين رمز API REST (بطريقة أكثر صحة) ، إضافة طرق جديدة إلى جزء القنوات لإضافة إشعارات جديدة وإضافة طرق إلى API REST والقنوات للتسجيل.
لإعطاء تجربة مستخدم أفضل (بمعنى السرعة) ، كان من الضروري استخدام قاعدة بيانات NOSQL ، لأنه بهذه الطريقة يمكن الوصول إلى بيانات المستخدم بسرعة أكبر.
من الواضح أنه لا يمكن القول أن هذا الفكر صحيح ، لأنه نظرًا لوجود علاقات بين الهويات ، يجب تحديث البيانات من المستخدمين الآخرين المتعلقة بالمستخدم الرئيسي.
قريبا يمكن تغيير هذا القسم وإعادة تشكيله. في الوقت الحالي ، يكون منطق النموذج أساسيًا للغاية ، وسيحتوي كل مستخدم على رسائل لم يتم قراءتها بعد ، وأسماء المستخدمين التي هي أصدقائهم وأسماء المستخدمين التي أرسلت طلبات صداقة وبيانات مثل اسم المستخدم والصور (المشفرة) والمزيد.
تجدر الإشارة أيضًا إلى أن Django لا يحتوي رسميًا على تكامل قاعدة بيانات NOSQL ، ولهذا السبب استخدمت أداة Djongo ، وهي فضولي للغاية ومفيدة للغاية ، فهو يطبق نماذج SQL على MongoDB لحماية منطق العمل.
