DataBase قواعد بيانات

حل “الطلبات المتزامنة المكررة” في Local-First: Request Coalescing (Single-flight) ✅ المشهد معروف: شاشة Product List تُرندر عدة منتجات في نفس اللحظة (Product A / B / C…) وكلهم يحتاجون نفس الـ Reference Data مثل: Get Section #4. بدون حل، كلهم يطلقون API Calls متطابقة قبل ما يكتمل أول طلب ويكتب للكاش. 🧠 الحل: SDK Request Coordinator (In-flight Map) نضيف طبقة داخل الـ SDK تعمل كـ “مُنسّق طلبات”: - تحتفظ بخريطة: Map<Key, Future> - المفتاح = (Section#4) - القيمة = Shared Future (طلب جاري) كيف يعمل؟ 1) أول طلب (Product A): - لا يجد المفتاح في الـ In-flight Map - ينشئ Shared Future - ويرسل 1x API Request فقط 2) الطلبات التالية (Product B / C…): - تجد Shared Future موجودة - لا تُنشئ طلبات جديدة - فقط “تنتظر” نفس الطلب الجاري (Await existing in-flight request) 📦 عند وصول النتيجة - يتم كتابة البيانات إلى Local DB (Cache) ✔️ - يتم توزيع نفس النتيجة فوراً لكل عناصر UI المنتظرة (Fan-out) ✔️ 📌 النتيجة - 1x Optimized API Request بدل 20x Duplicate Requests - Minimal Backend Load - Fast & Consistent UX - Cache يُملأ مرة واحدة ويُستخدم للجميع 🔎 مصطلحات مرتبطة - Request Coalescing - Single-flight Mechanism - In-flight Deduplication - Shared Future / Promise - (وأحياناً يُستخدم كـ Lock per Key) هل تطبّقون Single-flight في الـ SDK أو على مستوى Repository Layer؟ #API #MobileArchitecture #DistributedSystems

حل “الطلبات المتزامنة المكررة” في Local-First: Request Coalescing (Single-flight) ✅ المشهد معروف: شاشة Product List تُرندر عدة منتجات في نفس اللحظة (Product A / B / C…) وكلهم يحتاجون نفس الـ Reference Data مثل: Get Section #4. بدون حل، كلهم يطلقون API Calls متطابقة قبل ما يكتمل أول طلب ويكتب للكاش.

مشكلة شائعة في Local-First: “Race Condition” تسبّب رحلات API مكررة 🚨 تخيّل شاشة Product List تُرندر عدة عناصر في نفس اللحظة (Product A / B / C…). كل منتج يحتاج نفس الـ Reference Data مثل: Section #4. الـ SDK يعمل Local-First → يفحص Local DB (Cache) أولاً. ⚠️ أين المشكلة؟ لأن الطلبات متزامنة، الجميع يصلون للكاش قبل أن يكتب أول طلب النتيجة: Local DB = MISS (Not Found Yet) فيقوم كل منتج بإطلاق طلب شبكة مستقل لنفس البيانات… فتتحول العملية إلى 20+ طلب متطابق قبل أن يكتمل الأول. 🔥 الأثر على الخلفية (Backend) - High Concurrency Load - Wasted Bandwidth - Risk of Rate Limiting - UX أبطأ بسبب ازدحام الشبكة 🧠 المصطلحات الشائعة - Cache Stampede / Thundering Herd - Race Condition (In Local-First Cache) - Redundant API Calls (وأحياناً تُرى كـ N+1 / Over-fetching حسب السياق) ✅ كيف نعالجها عادة؟ - Single-Flight / In-Flight Deduplication: “طلب واحد لكل مفتاح” والبقية تنتظر نفس الـ Future/Promise - Request Coalescing: تجميع الطلبات المتطابقة - (اختياري) Prefetch/Batch للـ Reference Data عند تحميل المنتجات هل واجهت هذا السيناريو في تطبيقك؟ وكيف تعاملت معه؟ الحل في المنشورات القادمة #API #MobileArchitecture #DistributedSystems

مشكلة شائعة في Local-First: “Race Condition” تسبّب رحلات API مكررة 🚨

حل مشكلة “الطلبات المكررة” في Reference Data بطريقة أبسط وأذكى داخل MyApp ✅ بدل ما الـ SDK يعيد جلب كل شيء عند انتهاء TTL أو عند تكرار فتح الشاشة، طبقنا 3 أفكار مع بعض: 1) Delta Sync (Incremental Updates) كل مرة نطلب فقط التغييرات عبر: ?since=lastSentAt يعني: “أعطني ما تغيّر منذ آخر مزامنة ناجحة” بدل Full Fetch. 2) Throttle Window (مثلاً 10 دقائق) لو المستخدم أعاد فتح الشاشة أو كرر نفس الطلب خلال 10 دقائق: لا نرسل API Call جديد → نكتفي بالمحلي. وبعد انتهاء النافذة نسمح بطلب Delta جديد. 3) Stale-While-Revalidate (SWR) نعرض البيانات المحلية فوراً (حتى لو قديمة قليلاً) ونحدّث بصمت في الخلفية. النتيجة: تجربة أسرع بدون “فلاش” بيانات ناقصة. 📌 النتيجة النهائية: Optimized Network ✅ Low Server Load ✅ Fast & Fluid UX ✅ Tiny Delta Payload بدل Massive Payload ✅ هل تستخدمون lastSyncAt / lastSentAt أو Delta Sync في مشاريعكم؟ #API #MobileArchitecture #DistributedSystems

هل صادفت شاشة منتجات “تفلاش” بيانات ناقصة… ثم تبدأ الطلبات تتكرر على الـ API بدون سبب؟ في MyApp واجهنا سيناريو شائع في Local-First داخل الـ SDK: عند عرض Product List، كل منتج يحتاج Reference Data: Section / Unit / Manufacturer. لكن عند انتهاء TTL تصبح البيانات Stale. ⚠️ المشكلة (The Blind Spot) بدون سياق مزامنة مثل since أو lastSentAt، الـ SDK لا يعرف ما تغيّر فعلاً → يلجأ إلى Blind Full Fetch (Get All). 🔥 النتيجة Redundant API Calls + High Server Load + Poor UX + نفس الداتا تُرسل مراراً. ✅ الحل Delta/Incremental Sync + إرسال since = lastSentAt عند إعادة الطلب، مع نافذة منع تكرار (10 دقائق) + (اختياري) Stale-While-Revalidate، ومع ضغط UI العالي: Single-Flight / In-Flight Deduplication. هل تستخدمون updatedSince / ETag / lastSyncAt في مشاريعكم؟ شرح الحل في المنشورات القادمة #API #MobileArchitecture #DistributedSystems

‏. بشكل مبسط و سهل , انفوجرافيك يشرح الفرق بين تعليمات الـ JOINS في لغة SQL استبدل كلمة Full ب cross في بعض البيئات ك SQL server

ماذا تعني CRUD ؟ هي اختصار لأربع عمليات اساسية نستخدمها كثيرا عند برمجة نظام او تطبيق يتعامل مع البيانات وهي إنشاء وقراءة وتحديث وحذف وتستخدم كثيراَ مع قواعد البيانات , وتنفذ من خلال لغة الاستعلام SQL بواسطة هذه التعليمات ‎INSERT‎ و ‎SELECT‎ و ‎UPDATE‎ و ‎DELETE‎ .

فقرات تعليمة select

ماهي SQL ؟

اضافه فهرسة للمحتوى يسهل به التنقل الموقع الرسمي لتعلم markdown https://www.markdownguide.org/

رسم الجداول الموقع الرسمي لتعلم markdown https://www.markdownguide.org/

رسم المخططات التسلسلية. الموقع الرسمي لتعلم رسم المخططات https://mermaid.js.org/intro/ اداة الرسم بالواجهات https://mermaid.live/edit

يمكن ايضا رسم المخططات العلائقية للجداول الموقع الرسمي لتعلم رسم المخططات https://mermaid.js.org/intro/ اداة الرسم بالواجهات https://mermaid.live/edit