انا هدفي من السؤال مش ازاى اشغل feature لأ انا عرفتها من زمان لكن التحدي دلوقتى هو ازاى اصممها علشان اتأكد انها هتستحمل عدد كبير و كل المتطلبات ال NFR
تعديل : انا حسيت السؤال مش واضح فا هحاول اوضحه , انا مش عايز اسيب حاجة للصدفة و عايز اعرف كل حاجة سببها ايه فى حدود ال position بتاعي زي مثلا اخترت التقنية دي ليه؟ و اشمعنا ال structure ده؟و هكذا
على حسب برده انت عاوز توصل لايه..
ليها ارتباط وثيق اصلا بمين هيتسخدم الابليكشن..
و ده الفرق بين برنامج هيستخدمه شخص واحد عشان يقوم بدور معين ليه هو شخصيا ، على اللوكال بتاعه جوة بيئة معزولة… او برنامج هيستخدموا ٥٠٠٠ واحد يوميا، و فيه بيانات حساسة.
انت لازم تبدأ من الاخر للأول:
"مين اصلا هيستخدم البرنامج و ايه هي حالات الاستخدام؟"
و على اساسها هتحدد .. هو المفروض يكبر لحد قد ايه.. هو المفروض يكون مؤمن ضد ايه بالظبط (انا ذكرت بيئة معزولة قاصد)…
انما كل ده يتحط في خانة … و في خانة تانية خالص تتحط لوحدها:
ال maintainability
دي لازم تتعمل ايا كان حجم البرنامج.. و ايا كان مين هيشتغل عليه و هيشتغل عليه فين
طب كل ده يأثر ازاي في القرارات؟
المفروض ان كل ده هيأثر في:
اختيار التكنولوچيا
(لولا اختلاف المتطلبات.. مكانش ظهر اصلا اي تنوع في التكنولوجيات)
في مشاريع مش محتاجة غير ابسط تك ستاك في الدنيا… و في مشاريع لازم فيها تك ستاك معينة…. كمثال: ارابك تك شغالة على نوود و postgresql لان معظمها crud .. - الموضوع مش محتاج اكتر من كدة- زائد طبقة كاش ب redis … الهدف من ارابك تك ان يكون فيه اريحية شديدة في التعامل مع داتا relational جدا… و عادي جدا يتعملها كاش عنيف ..و في الموبايل.. شغالين برياكت نيتف.. و ده لان برده ده ابليكشن معظمه crud فمش محتاج تعقيد الnative و لا الوقت اللي هيضيع عليه… انما ريموت كان لازم يتكتب بحاجة ليها تأثير طفيف جدا على الميموري.. ف go كانت اختيار موفق.. و في الفرانت اند… اخترت preact لان ده يعتبر single page application و المكتبة دي حجمها اصغر من react نفسها.. و احنا مش محتاجين حاجات اكتر من كدة (تاني الهدف مع ريموت هو دايما استخدام اقل حاجة للميموري)
اختيار معمارية طبقة ال transport : دي في حد ذاتها من اهم النقاط… بتلاقي دلوقتي كتير بيذكر rpc و websockets و sse … الخ الخ .. ده برده مهم جدا يتحدد في البداية.. لان ده بيأثر على اختيار فين هيترفع الابليكشن.. كمثال: جرافيكس كلها كمعمارية بتتعامل بنسبة ٨٠٪ مع كلاودفلير.. و بالذات cloudflare workers و الdurable objects بتاعتهم… و ده لان كل project لكل فيديو (يشمل الشات و الادوات و الوركفلو) ممكن تكون قاعدة بيانات كاملة بذاتها و ملهاش اي علاقة باي project تاني… و عشان كدة الdurable objects بتاعت كلاودفلير كانت اختيار افضل عشر مرات من postgresql عملاقة.. هتكلفني فلوس كتير جدا… مقابل كلاودفلير…. و لو حبينا نتكلم عن ال websockets فهي من افضل و اعظم انواع التواصل في اي transport layer … و لكن عيبها انها محدودة… متقدرش تفتح عدد لا نهائي من السوكتس (نظريا)… هتكون محدود بعدد معين علي كل سرفر ، و الحل هيكون توسع افقي بعدد سيرفرات كبير (غير عملي و غالي)… عشان كدة مش بيتم استخدامها في كل الحالات… لكن في ريموت كمثال…في اعتماد شديد جدا عل ويبسوكتس، و ده لان بكل بساطة معندناش مشكلة عدد المستخدمين… حرفيا عندنا عدد مستخدمين قليل جدا … لان مفيش سرفر مركزي لكل مستخدمين ريموت.. احنا عندنا باكند لكل نسخة ريموت جاهزة، و عدد المستخدمين هو عدد الاعضاء في اي نسخة ريموت منفصلة عن غيرها * في عدد الاجهزة اللي داخلين منها في نفس الوقت = رقم صغير جدا، و تقدر على اساسه تستخدم ويبسوكتس في كل حاجة
… الخ الخ
