DevGuide

ليه الـ Caching مهم؟ وإزاي تختار الطريقة الأفضل؟ 🤔 - الجزء الثاني . . في البوست اللي فات تكلمنا شوية عن الـ Caching وبعض طرق استخدامه، إن شاء الله في البوست ده هنكمل باقي الطرق... ——— 4- الـ Write Around الـ Write هنا بيتكتب مباشرة في الـ Database، لكن مش في الـ Cache. والـ Cache بيتم تحديثه فقط لما يحصل Read بعد كده. 🔹 المميزات: ✅ مش بيحمل الـ Cache ببيانات ممكن متتطلبش قريبًا. ✅ بيقلل احتمالية إن الـ Cache يتبني ببيانات غير مستخدمة. 🔹 العيوب: ❌ ممكن يحصل Cache Miss كتير لو البيانات بتتطلب بشكل متكرر بعد الكتابة بفترة قصيرة. ❌ الأداء في القراءة ممكن يكون أبطأ مقارنةً بباقي الاستراتيجيات. 📌 إمتى تستخدمه؟ لما تكون بيانات الكتابة عندك أكتر بكتير من بيانات القراءة، زي الـ Logging Systems أو الـ Event Stores. ——— 5- الـ Read Through الـ Application مش بيطلب الـ Cache مباشرة. بدل كده، لما يحصل طلب، الـ Cache نفسه هو اللي بيروح يجيب الداتا من الـ Database لو مش موجودة عنده، ويرجعها للأبلكيشن. 🔹 المميزات: ✅ الأبلكيشن دايمًا بيطلب الداتا من مصدر واحد (الـ Cache). ✅ بيحسن الأداء لأنه بيضمن إن الـ Cache بيتعامل مع إدارة البيانات بشكل تلقائي. 🔹 العيوب: ❌ تعقيد في التنفيذ لأنك محتاج System يدعم Read Through Mechanism. ❌ لو الـ Cache حصل له Failure، الأداء ممكن يتأثر. 📌 إمتى تستخدمه؟ لما تكون عايز حل أوتوماتيكي لإدارة الـ Cache بدون الحاجة إن التطبيق نفسه يقرر إمتى يحفظ البيانات فيه. ——— 6- الـ Refresh Ahead الـ Cache هنا مش بيستنى لما يحصل طلب علشان يجدد البيانات، لا، هو بيبص على البيانات اللي بيتم استخدامها كتير، ويحاول يحدثها في الخلفية قبل ما تنتهي صلاحيتها (TTL)، بحيث لما يحصل طلب جديد، تكون البيانات جاهزة. 🔹 المميزات: ✅ بيقلل احتمالية الـ Cache Miss. ✅ بيضمن إن البيانات اللي في الـ Cache دايمًا حديثة. 🔹 العيوب: ❌ ممكن يحمل الـ Database لو البيانات مش بتتطلب كتير فعلًا. ❌ محتاج خوارزمية ذكية علشان يعرف إيه البيانات اللي لازم تتجدد تلقائيًا. 📌 إمتى تستخدمه؟ لما يكون عندك بيانات بتستخدم بشكل متكرر جدًا، وعايز تقلل احتمالية إن المستخدم يطلبها وتكون غير متاحة في الـ Cache، زي بيانات الـ Dashboards أو التقارير الحية. ——— الخلاصة 💯 اختيار Caching Strategy مش حاجة عشوائية. لازم تسأل نفسك: 🔹 هل التطبيق بيحتاج سرعة في القراءة ولا الكتابة؟ 🔹 هل البيانات بتتغير بسرعة ولا ثابتة لفترة؟ 🔹 هل ممكن أتحمل تأخير في الـ Sync بين الـ Cache والـ Database؟ الـ Cache Aside مناسب لحالات الـ Lazy Loading. الـ Write Through ممتاز للحفاظ على الـ Consistency. الـ Write Back مثالي للأداء العالي في الكتابة. الـ Write Around مفيد لو الكتابة أكتر من القراءة. الـ Read Through بيساعد لو عايز الـ Cache يدير نفسه. الـ Refresh Ahead بيقلل احتمالية الـ Cache Miss في البيانات اللي بيتم استخدامها كتير.

ليه الـ Caching مهم؟ وإزاي تختار الطريقة الأفضل؟ 🤔 . . خليني أسألك سؤال: عمرك دخلت على تطبيق ولقيته سريع جدًا في تحميل البيانات؟ ولو فكرت ليه سريع كده، غالبًا الإجابة هتكون إنه بيستخدم الـ Caching. التخزين المؤقت (Cache) مش بس بيساعد في تحسين الأداء، بل ممكن يكون الفرق بين تجربة مستخدم ممتازة وتطبيق الناس بتكرهه بسبب البطء (وأكيد مر عليك تطبيقات بالشكل ده). لما بتطلب داتا، بدل ما ترجع للسيرفر في كل مرة، بتحفظ نسخة منها في الـ Cache، وده بيقلل الـ Latency، ويخفف الحمل على قواعد البيانات (Database)، ويوفر في التكلفة. لكن السؤال المهم: إيه أفضل طريقة تستخدم بها الـ Caching؟ 🤔 مش كل الـ Caching Strategy بتنفع في كل السيناريوهات. فيه Strategies مختلفة، وكل واحدة لها استخداماتها، مميزاتها وعيوبها. وعلشان كده، لازم تفهمهم كويس علشان تختار اللي يناسب حالتك. ——— 1- الـ Cache Aside (Lazy Loading) الـ Cache هنا شغال زي مساعد مش أساسي. لما التطبيق يحتاج داتا، بيشوف الأول هل موجودة في الـ Cache؟ لو موجودة (Cache Hit)، بيستخدمها، لو مش موجودة (Cache Miss)، بيروح للـ Database، يسحب الداتا، ويخزنها في الـ Cache علشان لو اتطلبت تاني تكون موجودة. 🔹 المميزات: - بسيط وسهل التطبيق. - الداتا مش بتتحمل في الـ Cache إلا لما يكون فيه طلب فعلي ليها، فمفيش تحميل غير ضروري. 🔹 العيوب: - أول طلب دايمًا هيكون بطيء لأنه هيروح للـ Database. - لو حصل تحديث في الداتا في الـ Database، الـ Cache مش هيعرف غير لما يتطلب تاني. 📌 إمتى تستخدمه؟ لما يكون عندك بيانات بتتغير بشكل غير متكرر، وعايز تقلل الـ Load على الـ Database بدون ما تستهلك مساحة كبيرة في الـ Cache. ——— 2- الـ Write Through هنا أي داتا جديدة بتتكتب في الـ Cache وفي نفس اللحظة بتتكتب في الـ Database. يعني مش هتلاقي حاجة في الـ Cache غير اللي متسجلة في الـ Database فعلًا. 🔹 المميزات: - الـ Cache دايمًا متزامن مع الـ Database. - البيانات مش هتضيع لو الـ Cache حصل له Restart، لأنها محفوظة في الـ Database. 🔹 العيوب: - الأداء ممكن يكون أبطأ لأن أي Write هيتنفذ مرتين (في الـ Cache وفي الـ Database). - مش دايمًا هتستفيد من الـ Cache، لأن البيانات الجديدة مش بيتم طلبها بنفس سرعة البيانات القديمة. 📌 إمتى تستخدمه؟ لو عندك نظام Critical لازم يكون دايمًا متزامن ومفيش أي احتمالية لفقد البيانات، زي الأنظمة المالية أو الطلبات في الـ E-commerce. ——— 3- الـ Write Back (Write Behind) عكس الـ Write Through، هنا أي داتا جديدة بتتكتب في الـ Cache الأول، وبعد كده بيتم إرسالها للـ Database بشكل غير متزامن (Asynchronously) بعد فترة معينة أو عند الوصول لحجم معين من البيانات. 🔹 المميزات: - أسرع في الكتابة لأنه مش بيعمل Load على الـ Database مع كل عملية Write. - بيساعد في تحسين الأداء لما يكون فيه عدد كبير من عمليات الكتابة. 🔹 العيوب: - لو الـ Cache حصل له Failure قبل ما يرسل البيانات للـ Database، البيانات هتضيع. - محتاج Mechanism قوية لإدارة الـ Synchronization بين الـ Cache والـ Database. 📌 إمتى تستخدمه؟ لما يكون عندك تطبيق بيحتاج سرعة عالية جدًا في الكتابة، بس ممكن يتحمل تأخير بسيط في تحديث البيانات في الـ Database، زي التطبيقات اللي فيها Logging أو Analytics. ——— إن شاء الله التكملة في الجزء الثاني...

المنصة العربية الرائدة في تجميع وتصنيف أدوات الذكاء الاصطناعي https://www.sijil.ai

دردشة سريعة عن Docker 💯 . . تعال ندردش شوية عن Docker بطريقة بسيطة ونفهم هو ليه شيء أساسي في تطوير التطبيقات... ——— 📌 إيه هو Docker؟ ببساطة، Docker هو منصة بتسمح لك تبني، تختبر، وتشغل تطبيقاتك في حاجة اسمها Container. طيب يعني إيه Container؟ فكر فيها زي علبة بتحط فيها التطبيق بتاعك بكل المكونات اللي محتاجها عشان يشتغل: الـ Code، الـ Libraries، والـ Dependencies اللي مستخدمها، والـ System Configurations. الفكرة الأساسية إن الـ Container ده بيشتغل زي ما هو على أي جهاز أو سيرفر، بغض النظر عن الـ Operating System أو الـ Environment اللي عليه. يعني لو التطبيق شغال عندك على جهازك الشخصي، هيشتغل بالضبط بنفس الطريقة على أي سيرفر تاني من غير مشاكل. ——— 📌 ليه Docker مهم في مجال السوفتوير؟ ⚡️ التوافق بين البيئات المختلفة: من أكتر المشاكل اللي معظمنا بيقابلها إنك تشتغل على مشروع على جهازك وكل حاجة تبقى تمام، لكن أول ما تيجي ترفعه على السيرفر، تبدأ المشاكل... ممكن الـ Libraries أو الـ Environment اللي على السيرفر تكون مختلفة عن جهازك، وده يخلي حاجات كتير تبطل تشتغل. وهنا بييجي دور Docker، من خلال الـ Container اللي بيبنيها، كل حاجة بتكون جاهزة ومتوافقة مع بعضها، فالتطبيق بتاعك هيشتغل بنفس الكفاءة على أي بيئة تانية من غير تعديلات. ——— ⚡️ سرعة الانتقال من مرحلة التطوير للإنتاج: العادي في أي مشروع إنك بتبدأ بـ Development Environment، وبعد كده تنقل المشروع لـ Production Environment. نقل المشروع ده ممكن ياخد وقت ومجهود كبير، خصوصًا لو بتحتاج تعيد تهيئة البيئة الجديدة كل مرة. Docker بيحل المشكلة دي عن طريق إنك بتجهز كل حاجة في Container واحد، وبتقدر تنقله مباشرة لأي مكان، وبالتالي بتقلل الوقت اللي بياخده المشروع عشان يبقى جاهز للنشر. ——— تقدر تعمل نسخ متعددة من الـ Containers وتشغلهم على أي عدد من السيرفرات بسهولة وفي وقت قليل، وبالتالي تقدر تتعامل مع زيادة الأحمال بدون مشاكل. ——— ⚡️ سهولة التجربة والاختبار: ميزة Docker إنه بيوفر لك بيئة معزولة لتجربة أفكار جديدة أو تعديل كود معين بدون التأثير على التطبيق الرئيسي. يعني، لو عايز تجرب Framework جديد أو تضيف Feature للتطبيق، تقدر تعمل Container جديد وتجرب براحتك من غير ما تأثر على البيئة اللي شغال عليها باقي الفريق أو المشروع الأساسي. ——— ⚡️ الحفاظ على استمرارية العمل: من خلال Docker تقدر تتأكد إن نفس الـ Setup شغال عندك، عند باقي الفريق، وعلى السيرفرات اللي بتشغل التطبيق. ده معناه إن مفيش مشاكل هتحصل بسبب فرق في الـ Configuration أو الـ Environment.

مسار تطوير تطبيقات Flutter

سنتعرف في المسار على طريقة بناء تطبيقات الموبايل والويب باستخدام Flutter، حيث تبدأ رحلتك بتعلم لغة Dart ثم تنتقل لتعلم مبادئ وأساسيات بناء التطبيقات باستخدام Flutter، كما ستتعرف على طريقة استخدام قواعد البيانات واستخدام أنظمة التحكم بالإصدارات Git و GitHub. https://satr.tuwaiq.edu.sa/path/OHarLRCHae/view

الـ DOM (Document Object Model) 💯 . . هي البنية اللي المتصفح بيستخدمها عشان يحوّل صفحة الويب من كود HTML لكائنات (Objects) يقدر يتعامل معاها. يعني ببساطة، الصفحة بتاعتك اللي بتتكون من عناصر زي العناوين، الفقرات، الصور، وغيرها بتتحول لشجرة من الكائنات، وكل عنصر بيتحول لكائن فيه خصائص زي النص، الألوان، الأحجام، وغيرها. ——— الجميل في الـ DOM إنه بيسمح لنا نغير الصفحة بعد ما تتحمل، وده اللي بنسميه "DOM Manipulation" باستخدام JavaScript. ✅ فكرة الـ DOM Manipulation ببساطة هي إنك بتقدر تعدل على عناصر الصفحة وتغيرها بناءً على تفاعل المستخدم، زي إنك تضيف زرار جديد، تشيل صورة، أو حتى تغير النص اللي مكتوب في الفقرات. 💯 ——— 📌 إزاي تجيب عناصر من الـ DOM؟ عشان تقدر تعمل DOM Manipulation، لازم الأول تعرف إزاي تجيب العناصر اللي عايز تعدلها. فيه طرق كتير عشان تجيب العناصر: ⚡️ الـ document.getElementById: دي بتجيب العنصر اللي له ID معين. مثلًا:

const element = document.getElementById("myElement");

⚡️ الـ document.querySelector: دي طريقة أقوى شوية لأنها بتستخدم CSS Selectors، يعني تقدر تجيب أي عنصر بناءً على الاسم، الـ class، أو حتى الـ ID:

const element = document.querySelector(".myClass");

⚡️ الـ document.getElementsByClassName والـ document.getElementsByTagName: دول بيرجعوا لك مصفوفة (Array-like) من العناصر اللي لها نفس الـ class أو الـ tag. ——— 📌 إيه اللي ممكن تعمله بـ DOM Manipulation؟ ⚡️ إضافة عناصر جديدة: لو عايز تضيف عنصر جديد في الصفحة، زي زرار أو صورة، تقدر تستخدم JavaScript عشان تعمل Create Element، وبعد كده تضيفه للشجرة باستخدام appendChild. مثال بسيط:

const newButton = document.createElement("button");
newButton.innerHTML = "اضغط هنا";
document.body.appendChild(newButton);

الكود ده بيعمل زرار جديد مكتوب عليه "اضغط هنا" وبيضيفه في آخر الـ body. ——— ⚡️ تعديل محتوى العناصر: تقدر بسهولة تغير النص أو الـ HTML اللي موجود جوا أي عنصر باستخدام innerHTML أو textContent. يعني مثلًا لو عندك فقرة فيها نص وعاوز تغير النص ده لما المستخدم يضغط على زرار:

document.getElementById("myButton").addEventListener("click", function() {
  document.getElementById("myParagraph").innerHTML = "النص اتغير!";
});

هنا، لما المستخدم يضغط على الزرار اللي ID بتاعه "myButton"، النص اللي في الفقرة اللي ID بتاعها "myParagraph" هيبقى "النص اتغير!". ——— ⚡️ تعديل تنسيق العناصر (CSS): عن طريق الـ DOM، تقدر تعدل في التنسيق (CSS) بتاع أي عنصر بسهولة باستخدام element.style. يعني لو عاوز تغير لون الخلفية لزرار معين لما المستخدم يضغط عليه:

document.getElementById("myButton").addEventListener("click", function() {
  document.getElementById("myButton").style.backgroundColor = "red";
});

هنا الزرار هيغير لونه للأحمر بعد ما المستخدم يضغط عليه. ——— ⚡️ حذف عناصر من الصفحة: مش بس بتقدر تضيف أو تعدل، كمان تقدر تحذف عناصر من الصفحة تمامًا باستخدام remove():

document.getElementById("myButton").remove();

الكود ده هيحذف الزرار اللي ID بتاعه "myButton" من الصفحة. ——— 📌 إيه أهمية DOM Manipulation؟ الـ DOM Manipulation بيلعب دور كبير جدًا في مجال الويب، وده لأنه بيخليك تقدر تبني صفحات ويب ديناميكية تستجيب لتفاعل المستخدم في اللحظة. على سبيل المثال، في تطبيقات زي الـ Single Page Applications (SPA) زي اللي معمولين بـ React أو Vue، الـ DOM بيتم تحديثه باستمرار عشان يعرض للمستخدم المحتوى اللي هو محتاجه بدون ما نعمل Reload للصفحة كلها. كمان، لو بتشتغل على تحسين تجربة المستخدم (UX)، هتلاقي إن DOM Manipulation بيساعدك توصل للنتائج اللي أنت عايزها، سواء بتعديل في التنسيق أو بتحريك العناصر على الصفحة بشكل سلس. ملحوظة: رغم إن DOM Manipulation مهم جدًا، إلا أنه ممكن يبقى مكلف شوية لو عملت تعديلات كتير مرة واحدة على الصفحة، عشان كده من الأفضل دايمًا تستخدم تقنيات زي الـ Virtual DOM في مكتبات زي React عشان تحسن الأداء.

Build a Simple Express Server 🔥

Learn Dynamic Programming Through Dynamic Visuals 💯

Dynamic programming (DP) is often considered one of the most intimidating topics in coding interviews. It has a reputation for being abstract and counterintuitive, but it doesn't have to be. https://youtu.be/66hDgWottdA

دردشة سريعة عن الـ API Gateway 💯 . . لو بتشتغل على مشروع كبير أو على بيئة Microservices معقدة، أكيد هتحتاج تتعامل مع الـ API Gateway، لأنها ببساطة بتشتغل كـ "بوابة" أو وسيط بين المستخدمين (Clients) وبين مجموعة الخدمات اللي بيقدمها التطبيق. ——— 📌 يعني إيه API Gateway؟ خلينا نقول إنك بتشتغل على مشروع كبير زي موقع بيع منتجات، وفيه خدمات كتير مستقلة، زي خدمة للمشتريات، خدمة للدفع، خدمة للمخزون، وخدمة للملف الشخصي. الـ API Gateway هي الجزء اللي بتستلم الطلبات من الـ Clients (زي تطبيق الموبايل أو الويب) وتوجهها للـ Microservice الصحيحة. يعني بدل ما التطبيق يبعت طلب مباشر لكل خدمة ويضيع وقت في فهم مسارات كتير، الـ API Gateway بتستقبل الطلب وتنفذه وتبعت البيانات للي عاوزها. ——— 📌 الـ API Gateway بتعمل إيه بالضبط؟ ✅ توجيه الطلبات: لما ييجي طلب من العميل، الـ API Gateway بتختار الخدمة المناسبة اللي هتقدر تستجيب للطلب ده وتبعته لها. ✅ توحيد البيانات: لو عندك خدمات مختلفة والعميل محتاج بيانات من أكتر من خدمة، الـ API Gateway بتجمع البيانات دي كلها وترجعها للعميل في رد واحد. ✅ التحكم في الأمان: بتسمح لك تعمل قواعد الأمان زي التحقق من الهويات (Authentication) والترخيص (Authorization)، عشان تضمن إن الطلبات اللي جايه كلها من مصادر موثوق فيها. ✅ التحكم في المعدل (Rate Limiting): تقدر من خلالها تحدد عدد الطلبات اللي ممكن يجريها العميل في وقت معين، بحيث تحمي خدماتك من أي ضغط غير طبيعي أو هجمات زي DDoS. ✅ التوجيه الديناميكي (Dynamic Routing): لو عندك إصدارات مختلفة من نفس الخدمة، تقدر تحدد أي إصدار يستخدمه الـ Client أو تغير التوجيه حسب الوقت أو حسب الـ Load. ✅ التحسين والأداء (Caching): ممكن كمان تقوم بعمل Cache للطلبات اللي بيتكرر استخدامها، وده بيساعد في تخفيف الحمل على الخدمات. ——— 📌 ليه مهم نستخدم الـ API Gateway؟ لو عندك تطبيق بيدير أكتر من خدمة، التعامل المباشر بين العميل وكل خدمة على حدة ممكن يبقى معقد ويتطلب وقت طويل، وده بيأثر على أداء التطبيق. هنا بقى بييجي دور الـ API Gateway اللي بتسهل التعامل وتوفر طريقة منظمة وبسيطة للتفاعل مع الخدمات. كمان، لو محتاج تطبق سياسات الأمان بشكل موحد، أو محتاج تعمل Analytics للطلبات اللي بتيجي، يبقى الـ API Gateway هي المكان الصح اللي تعمل فيها كل ده، لأنها نقطة التحكم الرئيسية اللي بتشوف وتتحكم في كل الطلبات اللي جاية ورايحة بين العميل والخدمات. ——— 📌 أدوات ومكتبات الـ API Gateway فيه أدوات كتير تقدر تستخدمها كـ API Gateway، زي: ⚙️ Kong ⚙️ NGINX ⚙️ AWS API Gateway ⚙️ Zuul كل أداة من دول بتقدم مزايا مختلفة حسب احتياجات المشروع، وعادةً بنختار حسب حجم المشروع، الأمان المطلوب، وسرعة الاستجابة اللي محتاجينها.

Flutter Gems is a curated list of 7000+ useful Dart & Flutter packages that are categorized based on functionality.

https://fluttergems.dev

دردشة خفيفة عن مفهوم الـ Critical Rendering Path ⚡️ . . ببساطة الـ Critical Rendering Path هو "الطريق اللي بيمشي فيه المتصفح عشان يقدر يحول الكود بتاعنا (HTML, CSS, JavaScript) لشكل مرئي للمستخدم." يعني احنا بنكتب الكود، لكن المستخدم بيشوف صفحة شكلها جميل قدام عينه...إيه اللي حصل بين الكتابة دي وعرض الصفحة؟ ——— 📌 LinkedIn: https://www.linkedin.com/posts/dev-alisamir_frontend-webdeveloper-frontenddeveloper-activity-7432862974408777730-rB8Y 📌 Qabilah: https://qabilah.com/posts/فهم-الـ-critical-rendering-path-خطوات-تسريع-ظهور-صفحات-الويب~219532766721605632

Everything about JS Loops 💯

Stop writing CSS like it's 2015

Modern CSS code snippets, side by side with the old hacks they replace. Every technique you still Google has a clean, native replacement now. https://modern-css.com

الفرق بين SSR و CSR و SSG 💯 . . في عالم الويب، لما بتيجي تختار الطريقة اللي هيتم بها عمل (Render) لصفحات الموقع بتاعك، أكيد قابلت المصطلحات دي: 📌 الـ Server-Side Rendering (SSR) 📌 الـ Client-Side Rendering (CSR) 📌 الـ Static Site Generation (SSG) تعال ندردش شوية ونعرف الفرق بينهم وإمتى تختار كل واحد منهم وشوية تفاصيل لذيذة... ——— 📍 الـ Server-Side Rendering (SSR): الـ SSR يعني الصفحة بيحصل لها "Rendering" بالكامل في السيرفر قبل ما توصل للمستخدم. يعني أول لما المستخدم يفتح الموقع، السيرفر بيعمل معالجة للبيانات ويرجع صفحة HTML كاملة. ✅ مميزاته: - أسرع في أول تحميل للصفحة (First Contentful Paint)، لأن الصفحة بتوصل جاهزة. - ممتاز للـ SEO، لأن محركات البحث زي Google بتقدر تفهم الصفحة بسهولة. - مفيد جدًا لو عندك محتوى بيتغير كتير أو بناءً على بيانات المستخدم (زي الصفحات الشخصية أو الـ Dashboards). ❌ عيوبه: - وقت استجابة السيرفر (Server Response Time) ممكن يبقى طويل مع الضغط الكبير. - السيرفر نفسه محتاج يبقى قوي عشان يقدر يتعامل مع عدد المستخدمين. ⚡️ أمثلة: - مواقع الأخبار اللي محتواها بيحتاج تحديث لحظي. - مواقع التجارة الإلكترونية زي Amazon (محتوى متغير ومهم للـ SEO). ——— 📍 الـ Client-Side Rendering (CSR): في الـ CSR الـ Render بيحصل في جهاز المستخدم. يعني السيرفر بيبعت ملف HTML بسيط مع JavaScript، والـ JavaScript دي بتتكفل بكل حاجة بعد كده. ✅ مميزاته: - أسرع بعد أول تحميل للصفحة، لأن الـ JavaScript بتحول التطبيق لحاجة ديناميكية وسريعة. - مناسب جدًا للـ SPAs (Single Page Applications). - تقليل العبء على السيرفر مقارنة بـ SSR. ❌ عيوبه: - الـ SEO ضعيف شوية، لأن محركات البحث ساعات بتواجه صعوبة في قراءة المحتوى. - أول تحميل للصفحة ممكن يبقى بطيء (Initial Load Time) لأن الجهاز بيحتاج يحمّل كل الـ JavaScript. ⚡️ أمثلة: - تطبيقات زي Gmail أو Trello اللي المستخدم بيتفاعل معاها كتير بعد التحميل الأول. - أي حاجة فيها Dynamic Interactions كتير. ——— 📍 الـ 3. Static Site Generation (SSG): الـ SSG يعني كل الصفحات بيحصل لها "Render" مرة واحدة أثناء الـ Build Time (وقت بناء الموقع). والصفحات دي بتتبعت للمستخدم جاهزة من غير معالجة إضافية. ✅ مميزاته: - أسرع حاجة في التحميل (Load Time) لأن الصفحة ثابتة وجاهزة. - ممتاز جدًا للـ SEO. - مفيش عبء على السيرفر تقريبًا، لأن الصفحات كلها جاهزة وموجودة على CDN (شبكة توصيل المحتوى). ❌ عيوبه: - مش عملي للمواقع اللي محتواها بيتغير باستمرار (Dynamic Content). - لو عندك عدد ضخم من الصفحات، وقت الـ Build هيبقى طويل جدًا. ⚡️ أمثلة: - المدونات (Blogs) زي Gatsby أو Hugo. - المواقع اللي محتواها ثابت زي المواقع التعريفية (Portfolio Websites). ——— 📌 إمتى تستخدم إيه؟ - الـ SSR: لو محتاج محتوى ديناميكي مع SEO ممتاز. - الـ CSR: لو بتعمل SPA ومش محتاج SEO قوي. - الـ SSG: لو عندك محتوى ثابت وعايز سرعة عالية في التحميل.