PROTOCOL ATLASخريطة مراجعة امتحان Advanced Web

ONE-DAY COMMAND CENTER

ادرس بترتيب الامتحان، لا بترتيب الملفات.

ابدأ بالمحاضرات بعمق، مرّ سريعاً على عروض الطلاب، ثم راجع نقاط الخلط واختبر نفسك بنسبة الامتحان الحقيقية.

أكمل من هناHTTP Evolution & gRPC

افتح المحور

FULL SYSTEM LANDSCAPE

كيف ترتبط مواضيع المقرر داخل نظام واحد؟

اتبع المسار الرئيسي من المتصفح إلى البيانات، ثم اقرأ الشرائط السفلية كطبقات تعبر أكثر من مرحلة.

محاضرة عرض مسار runtime

Browser / Client
واجهة المستخدم والتنفيذ داخل المتصفح
يعمل offline، وينفذ compute محلياً، أو يعمل بلا واجهة
Service Worker & Push WebAssembly (Wasm)Headless Browsers & Crawling Web Automation & ETL Workflows
Transport
الاتصال واتجاه حركة البيانات
ينقل request/response أو streams أو peer-to-peer
HTTP Evolution & gRPC Real-time Web Protocols WebRTC Data Channels
Service / API
العقد وطريقة التواصل بين الأنظمة
يعرّف sync API أو async contract أو hub push
REST vs gRPC OpenAPI & AsyncAPI WebSub
Event Backbone
إدخال الأحداث والاحتفاظ بها
يحرّك NiFi البيانات؛ ويحفظها Kafka لإعادة التشغيل
Apache NiFi Apache Kafka
Compute
الحساب اللحظي أو الدفعي
يعالج Flink الـstateful stream؛ وينفذ Spark الـbatch وSQL
Apache Flink Apache Spark
Data
التخزين الموزع والاستعلام
يوفر Hadoop الـfoundation؛ ويقدم Hive الـcatalog وSQL
Apache Hadoop Apache Hive

Identity & Trust

يمتد من العميل إلى الـAPI

Client ↔ Authorization Server ↔ API

OAuth 2.1, OIDC & JWT

Architecture Pattern

ينظم مسارات الأحداث والحساب والبيانات

Events ↔ Compute ↔ Data

Big Data Architectural Patterns

Deployment Plane

يشغّل المكوّنات؛ ليس hop جديداً للبيانات

Image → Container → Workload → Cluster

Docker Kubernetes

اقرأها كخريطة أدوار، لا كسلسلة إلزامية: ليس كل تطبيق يمر بكل صندوق؛ Docker / Kubernetes يشغّلان المكوّنات، وOAuth يحمي حدود الثقة، بينما تحدد الأنماط كيف تتعاون طبقات الأحداث والحساب والبيانات.

CANONICAL STUDY ROUTE

مساران، ثم محاكاة واحدة.

0 من 20 محوراً تمت مراجعتها

المحاضرات · دراسة عميقة

60% · Multiple-answer — افهم الآلية والفروق والفخاخ.

النقل والوقت الحقيقي

افهم الاتجاه، الاتصال، والـlatency قبل حفظ أسماء البروتوكولات.

0/3

HTTP Evolution & gRPC Real-time Web Protocols WebRTC Data Channels

المتصفح كمنصة بيانات

ميّز الحساب داخل المتصفح عن الاستخراج وعن أتمتة workflow.

0/3

WebAssembly (Wasm)Headless Browsers & Crawling Web Automation & ETL Workflows

الهوية وحدود الوصول

ثبّت الفرق بين authorization، identity، والtoken validation.

0/1

OAuth 2.1, OIDC & JWT

العروض · مرور سريع

40% · Single-choice — ثبّت الوظيفة والمصطلحات العامة.

منصة البيانات

أعطِ كل أداة وظيفة واحدة واضحة داخل pipeline.

0/7

Apache Kafka Apache Hadoop Apache Hive Apache Spark Apache Flink Apache NiFi Big Data Architectural Patterns

الحزم والتشغيل

لا تخلط packaging على host مع orchestration على cluster.

0/2

Docker Kubernetes

أنماط الويب والـAPI

اختر contract أوdelivery pattern من شكل التواصل المطلوب.

0/4

Service Worker & Push WebSub OpenAPI & AsyncAPI REST vs gRPC

02 · STUDY READER

اقرأ بعمق حيث تأتي العلامة.

المحاضرات للفهم متعدد الإجابات؛ العروض لخلاصة عامة سريعة. ابحث بالمفهوم أوالأداة أوالمقارنة أوحتى اسم الملف.

0/20إجمالي المراجعة

ابحث في كل محتوى المقرر

20 نتيجة من 20

الجزء الأول · 60%

محاضرات المدرّس

افهم الآلية، ثبّت الفروق، وانتبه للفخ؛ قد يحمل السؤال أكثر من إجابة صحيحة.

0/7مُراجع

L01محاضرة المدرّس · 60%HTTP Evolution & gRPCمن نقل مستند واحد إلى streams مستقلة وRPC ثنائي

الفكرة في جملة

كل جيل يعالج bottleneck مختلفاً: HTTP/1.1 يقلّل فتح الاتصالات، HTTP/2 يضاعف streams داخل TCP واحد، وHTTP/3 ينقل النقل إلى QUIC فوق UDP لتقليل أثر packet loss.

لماذا يهم؟

اختيار protocol يغيّر latency وbandwidth وطريقة التوسع؛ والامتحان مرشح جداً لأسئلة المقارنة بين الإصدارات وبين REST وgRPC.

افهم الآلية

كيف يعمل المفهوم؟

ما يجب أن تعرفه

HTTP/1.1 أضاف persistent connections وpipelining وCache-Control، لكنه بقي text-based ويحتاج عدة TCP connections لتجاوز التسلسل.
HTTP/2 يستخدم connection واحدة مع multiplexing وbinary framing وHPACK header compression؛ لكن فقدان packet في TCP قد يؤخر جميع streams على مستوى النقل.
HTTP/3 يعمل فوق QUIC/UDP: streams مستقلة، TLS مدمج، 0-RTT عند إعادة الاتصال، وconnection migration عند الانتقال من Wi‑Fi إلى 5G.
gRPC = Protocol Buffers + HTTP/2 + code generation، وله Unary وServer streaming وClient streaming وBidirectional streaming.
REST أفضل عادةً للـpublic/browser APIs؛ gRPC أفضل للـinternal services عالية الحجم عندما نملك الطرفين.

الفروق الحاسمة

HTTP/2 يحل multiplexing على مستوى التطبيق

لكن TCP head-of-line blocking يبقى عند packet loss

REST: JSON مقروء وbrowser-native

gRPC: Protobuf أصغر وأسرع لكنه يحتاج gRPC-Web للمتصفح

L02محاضرة المدرّس · 60%Real-time Web ProtocolsPolling، Long Polling، SSE، WebSockets وBackpressure

الفكرة في جملة

الفرق الحاسم هو direction وconnection lifetime: SSE قناة push أحادية من server، بينما WebSocket قناة full-duplex دائمة للطرفين.

لماذا يهم؟

الـreal-time ingestion لا يكفيه request/response متكرر؛ يجب حماية النظام من slow consumers وتوزيع الاتصالات stateful أفقياً.

افهم الآلية

كيف يعمل المفهوم؟

خريطة بصريةrealtime-protocols

CONNECTION CHOOSER

كيف تستمر المحادثة؟

اختر التقنية لترى اتجاه البيانات، عمر الاتصال، وكلفة الاستمرار.

Client

GET text/event-stream →← event← eventauto-reconnect

Server

الاتجاه: Server → Client
الاتصال: HTTP دائم
Binary: Text فقط
Reconnect: مدمج + Last-Event-ID

أفضل اختيار عندماDashboard / logs / alerts

BACKPRESSURE

المنتِج أسرع بعشر مرات من المستهلِك

10,000 msg/s تدخل، و1,000 msg/s فقط تخرج.

Producer10k/s

→

Consumer1k/s

Bounded: أبطئ المنتج أو استخدم buffer / drop / coalesce وفق سياسة معلنة.

ما يجب أن تعرفه

Polling يهدر requests ويضيف delay؛ Long Polling يبقي الطلب مفتوحاً حتى وصول حدث لكنه يكرر دورة HTTP والheaders.
SSE يستخدم Content-Type: text/event-stream، يعمل عبر HTTP، يعيد الاتصال تلقائياً، ويمكنه الاستئناف عبر Last-Event-ID.
WebSocket يبدأ بـHTTP upgrade ثم يصبح اتصالاً bidirectional منخفض overhead يدعم text وbinary frames؛ إعادة الاتصال مسؤولية التطبيق.
Backpressure تعني أن المنتج الأسرع يجب أن يبطئ أو يbuffer/drop وفق سياسة، وإلا تتضخم الذاكرة حتى الانهيار.
للتوسع: Sticky sessions أو shared ownership في Redis، وPub/Sub عبر Redis/Kafka لإيصال الرسائل بين servers.
نمط المقرر: WebSocket Gateway → validation/enrichment → Kafka → Flink/analytics/storage.

الفروق الحاسمة

SSE: Server → Client، text، auto-reconnect

WebSocket: طرفان، text/binary، reconnect يدوي

SSE مناسب dashboards/logs/alerts

WebSocket مناسب IoT/games/collaboration

L03محاضرة المدرّس · 60%WebRTC Data Channelsنقل P2P مشفّر، Signaling، ICE، STUN وTURN

الفكرة في جملة

WebRTC ينقل البيانات مباشرة بين peers، لكن إنشاء الطريق يحتاج signaling خارجي وICE لاختيار Host أوSTUN أوTURN.

لماذا يهم؟

يقلل server bandwidth وlatency في edge-to-edge transfer، لكنه لا يلغي servers تماماً ولا يناسب mesh ضخمة.

افهم الآلية

كيف يعمل المفهوم؟

ما يجب أن تعرفه

واجهات WebRTC الأساسية: MediaStream للوسائط، RTCPeerConnection للاتصال، وRTCDataChannel للبيانات الثنائية أوالنصية.
Signaling غير مضمّن: نتبادل SDP offers/answers وICE candidates عبر WebSocket أوHTTP؛ server يرى metadata لا payload.
ICE يجرب Host أولاً، ثم STUN لاكتشاف public address، ثم TURN كـrelay مدفوع وأعلى latency عند فشل الاتصال المباشر.
DataChannel يدعم ordered/unordered وreliable/limited retransmission؛ file transfer يحتاج reliable ordered، وlive metrics قد تقبل loss.
bufferedAmount هو إشارة backpressure؛ أوقف الإرسال عند threshold واستأنف بعد انخفاضه.
WebRTC مناسب factory IoT وP2P files وedge analytics؛ mesh لا يتوسع جيداً لأن كل peer يحمل connections وuploads متعددة.

الفروق الحاسمة

STUN يكشف public IP/port

TURN يمرر payload فعلياً كـrelay

Signaling ينشئ الاتصال

DataChannel يحمل البيانات بعد الإنشاء

L04محاضرة المدرّس · 60%WebAssembly (Wasm)Compute ثقيل قرب native speed داخل sandbox

الفكرة في جملة

Wasm binary instruction format يشغّل كود Rust/C/C++ قرب native speed؛ JavaScript يبقى مسؤولاً عن DOM وI/O بينما Wasm يعالج CPU-bound work.

لماذا يهم؟

تصفية أوanonymization أوcompression على client تقلل upload bandwidth وcloud CPU قبل وصول البيانات إلى server.

افهم الآلية

كيف يعمل المفهوم؟

خريطة بصريةwasm

أين يكسب WebAssembly فعلاً؟

مرّر العمل الحسابي الكبير كدفعة واحدة، واترك DOM والشبكة وقيادة التطبيق لـJavaScript.

Browser / Client device

File / Sensor100 MBبيانات خام على الجهاز
Uint8ArrayLinear memorybuffer مشترك مع ضبط النسخ
Wasmfilter · anonymize · compressloops رقمية وbinary processing
fetch()10 MB uploadمثال المحاضرة، لا نسبة مضمونة
Serverless ingressbandwidth وCPU أقل

JavaScriptDOM · I/O · strings · fetch · orchestration

JS ↔ Wasm boundaryالنسخ وbindings والاستدعاءات الصغيرة المتكررة لها كلفة

WebAssemblynumeric · bitwise · ArrayBuffer · compression

Wasm مرشّح قويحساب كثيف على bytes كثيرة، ويمكن تمريرها دفعة واحدة عبر الحدود.

خطأ: Wasm أسرع دائماًخطأ: يصل إلى DOM مباشرةقاعدة: CPU-bound + binary + batch كبير

ما يجب أن تعرفه

Wasm language-agnostic ومكمّل لـJavaScript لا بديل كامل عنه؛ يتم التحميل والinstantiate عبر WebAssembly JavaScript API.
يتفوق عادةً في numeric/bitwise/ArrayBuffer/filter/map/reduce/compression/encryption، وليس في JSON native parsing أوstrings أوDOM.
Linear memory مشتركة كـbuffer بين JS وWasm؛ عبور الحدود ونسخ strings قد يمحو مكسب الأداء إذا تكرر كثيراً.
Sandbox يحترم browser permissions وsame-origin؛ module لا يلمس DOM مباشرة ويستدعي JS عند الحاجة.
أهم use cases في الشرائح: client-side filtering، anonymization، وcompression قبل الرفع.
القيود: startup/download، memory management، threading محدود عبر Workers، وinterop overhead.

الفروق الحاسمة

JavaScript: DOM، I/O،strings،orchestration

Wasm: loops رقمية وbinary processing

CPU-bound → مرشح جيد

I/O-bound أوDOM-heavy → ابقَ في JavaScript

L05محاضرة المدرّس · 60%Headless Browsers & Crawlingتنفيذ JavaScript للـSPAs ثم extraction موثوق على scale

الفكرة في جملة

الـSPA ترسل HTML shell وتبني DOM بعد XHR/fetch؛ headless browser يشغّل JavaScript كمتصفح حقيقي ثم يتيح navigation وextraction وnetwork interception.

لماذا يهم؟

curl أوRequests قد يرى div فارغاً؛ نجاح crawler يعتمد على انتظار الإشارة الصحيحة وإدارة تكلفة Chrome والالتزام القانوني.

افهم الآلية

كيف يعمل المفهوم؟

خريطة بصريةheadless

العنوان نفسه، واقعان مختلفان

HTTP client يرى المصدر الخام؛ headless browser يشغّل JavaScript ويراقب الشبكة وDOM الناتج.

/products

HTTP Client / View Source

GET /products

<div id="root"></div>
<script src="bundle.js"></script>

لا توجد product cards في المصدر بعد.

/products

Headless Browser / Rendered DOM

GET /api/products → 200 JSON

Product AProduct BProduct C

.product-card × 24 جاهزة للاستخراج.

متى أصبحت الصفحة جاهزة؟

اختر signal مبنياً على الحالة، لا مدة زمنية عمياء.

1HTML
2Bundle
3XHR starts
4API · 200
5DOM populated
6Lazy assets

waitForResponse — دقيق عندما نعرف endpoint الحاسم؛ وصول JSON لا يضمن وحده اكتمال تحديث DOM.

لا تخلط: SPA تحتاج تنفيذ JavaScript، لكن API مباشر ومسموح قد يكون أبسط.عند scale: Queue → browser/context reuse → bounded concurrency → retry.حد فاصل: القدرة التقنية لا تعني الإذن القانوني.

ما يجب أن تعرفه

Puppeteer ممتاز لـChrome وبسيط؛ Playwright متعدد المتصفحات ويملك auto-waiting وnetwork/mobile tools؛ Selenium أوسع legacy لكنه أبطأ وwaits يدوية.
استراتيجيات الجاهزية: network idle، waitForSelector، waitForResponse، أوwaitForFunction؛ اختر signal يمثل اكتمال البيانات فعلاً.
كل browser process ثقيل؛ scale عبر context/browser reuse، concurrency محدودة، queues، containers أوserverless وفق الحالة.
Network interception قد يكشف API خلف الصفحة أويسمح بحجب images/fonts لتقليل الموارد.
Selectors الدلالية وdata-testid أكثر ثباتاً من nth-child؛ failure rate صغير يصبح آلاف الصفحات عند scale.
Technical capability لا يساوي permission: راجع robots.txt وTerms، طبّق rate limiting، ولا تجمع private/login-walled data دون صلاحية.

الفروق الحاسمة

HTTP scraper: أخف وأسرع

Headless browser: أثقل لكنه ينفذ SPA

waitForSelector بسيط

waitForResponse أدق عندما نعرف API

L06محاضرة المدرّس · 60%Web Automation & ETL WorkflowsPlaywright كـETL connector عندما لا توجد API

الفكرة في جملة

الـbrowser يمكن أن يكون Extract actor: يسجل الدخول، يختار report، ينتظر background job، ينزل الملف؛ ثم transform/load خارج الصفحة.

لماذا يهم؟

Legacy وenterprise portals مبنية للبشر. automation تقلل latency والأخطاء، لكن reliability تعتمد على sessions وtimeouts وselectors ومراقبة workflow.

افهم الآلية

كيف يعمل المفهوم؟

خريطة بصريةautomation

المتصفح Extract actor داخل ETL أكبر

Playwright يعبر واجهة صُممت للبشر؛ Airflow يغلّف المسار بالجدولة والاعتمادية والمراقبة.

Airflowschedule · dependencies · retries · logs · alerts · backfill

1Portallegacy UI
2Restore sessionor login / MFA
3Navigatedates + report
4Trigger exportbackground job
5Bounded pollstatus + timeout
6DownloadCSV / Excel / PDF
7Validatereject bad extract
8Transformparse + normalize
9Warehouse / Lakepermanent target

حالة المصادقة

Saved state?Session valid?Continue

لا يوجد أوانتهت الصلاحية → secret store → login / MFA → حفظ state محمية.

Hardcoded password
auth-state.json في Git

انتظار bounded، لا loop أبدي

PROCESSINGwait 5s → log status → check deadline → poll again

Playwright: login، navigation، trigger، download.Airflow: schedule، dependencies، retries، monitoring.قاعدة: اكتمال download لا يعني أن البيانات valid.

ما يجب أن تعرفه

ETL: Extract يجمع ويطبق validation؛ Transform يوحد schema والقيم؛ Load ينقل الناتج إلى target دائم.
Playwright يتعامل مع login وnavigation وforms وuploads/downloads وcookies/localStorage وiframes/dialogs/new tabs.
Secrets في environment/secrets manager لا في الكود؛ احفظ session state وأعد login فقط عند انتهاء الصلاحية.
Asynchronous report generation يحتاج polling bounded بtimeout وstatus logging وretry policy، لا loop بلا نهاية.
Airflow DAG يضيف scheduling وdependencies وretries وmonitoring وbackfill؛ browser task خطوة ضمن pipeline لا pipeline كاملة.
Selector priority: role/label/data-testid/text ضمن context، ثم fallback chain محدودة؛ major redesign يحتاج تدخل بشري.

الفروق الحاسمة

Scraping يقرأ content

Automation ينفذ workflow ويغيّر state أيضاً

Browser task للواجهة

Airflow للجدولة والاعتمادية بين tasks

L07محاضرة المدرّس · 60%OAuth 2.1, OIDC & JWTAuthorization للبيانات، Identity للمستخدم، Tokens للـpipelines

الفكرة في جملة

OAuth يفوض access، OIDC يضيف authentication وID Token، وJWT format موقّع يمكن للـresource server التحقق منه دون الرجوع كل مرة إلى auth server.

لماذا يهم؟

Password مشترك لا يتوسع مع rotation وMFA وrevocation؛ flows وscopes تمنح automated clients أقل صلاحية ولوقت محدود.

افهم الآلية

كيف يعمل المفهوم؟

خريطة بصريةoauth

اختر flow من وجود الإنسان، ثم وجّه كل token إلى مستهلكه

OAuth يفوّض الوصول؛ OIDC يضيف هوية المستخدم؛ JWT مجرد format يحتاج تحققاً كاملاً قبل الثقة.

هل يوجد إنسان يملك البيانات ويوافق؟

اختر السيناريو، لا تحفظ أسماء flows منفصلة عن السبب.

لا يوجد إنسان: التطبيق يعمل بهويته

Client Credentials · confidential client · access token فقط عادةً؛ عند الانتهاء يعيد client المصادقة.

1Client / Airflowacts as itself
2/tokenclient credentials
3Access Tokenshort-lived
4Resource APIBearer token

أرسل كل token إلى المكان الصحيح

Access TokenAuthorization + scopes

Resource Server / APIالمستهلك الصحيح

لا تعامله كبطاقة هوية للواجهة.

JWT: القراءة ليست ثقة

HEADERalg · kid.PAYLOADiss · sub · aud · exp · scope.SIGNATUREintegrity + authenticity

Select Decode, Verify, or Tamper

JWKS + signature
iss
aud
exp
scope / tenant

ابدأ بـDecode للفحص أوVerify للثقة.

Authorization CodeAccess expiresRefresh Token → Auth ServerNew Access

Client CredentialsAccess expiresAuthenticate client againNew Access

ما يجب أن تعرفه

الأطراف: Resource Owner، Client، Authorization Server الذي يصدر tokens، وResource Server الذي يحمي API/data.
Client Credentials للـmachine-to-machine بلا user أوconsent؛ client يعيد طلب access token عند انتهاء الصلاحية.
Authorization Code + PKCE للـuser-delegated access: redirect/consent → code → tokens؛ refresh token يتيح الاستمرار لاحقاً.
OIDC فوق OAuth يضيف ID Token لإثبات هوية subject؛ access token مخصص لاستدعاء API وليس بطاقة هوية للواجهة.
JWT = header.payload.signature؛ claims المهمة iss وsub وaud وexp وiat وscope وtenant_id.
Decode لا يساوي verify: يجب فحص signature عبر JWKS، issuer، audience، expiry، ثم authorization scopes.

الفروق الحاسمة

OAuth: ماذا يسمح للتطبيق؟

OIDC: من هو المستخدم؟

Access token قصير للـAPI

Refresh token طويل للحصول على access جديد

الجزء الثاني · 40%

عروض الطلاب

ابدأ بالخلاصة والخريطة العامة، وافتح التفاصيل فقط عندما تحتاج تثبيت المصطلحات.

0/13مُراجع

P01عرض طلابي · 40%Apache KafkaDistributed commit log: fan-out، replay وthroughput

الفكرة في جملة

Kafka ليس queue تقليدية تحذف الرسالة بعد التسليم؛ إنه append-only distributed log، وكل consumer group يملك offsets مستقلة.

لماذا يهم؟

نفس event يمكن أن تقرأه alerts وanalytics وstorage كل بسرعتها، ويمكن model جديد أن يعيد قراءة history ضمن retention.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةkafka

P01 · APACHE KAFKA

سجل واحد، قراءات مستقلة

Producer · Patient monitorsTopic · patient-vitalsRetention · 7 days

Partition 0patient_id=A

A·e0A·e1A·e2A·e3A·e4A·e5A·e6

Partition 1patient_id=B

B·e0B·e1B·e2B·e3B·e4

Partition 2patient_id=C

C·e0C·e1C·e2C·e3C·e4C·e5

Bookmarks على نفس الـlog — لا مجموعة توقف الأخرى

alert-groupoffset 6

0123456

archive-groupoffset 5

0123456

ml-groupoffset 3

0123456

3 partitions → 3 active consumers / groupConsumer 4 · idle

افتح التفاصيل الكاملة5 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

Topic stream مسمّى؛ Partition sub-log مرتب ووحدة parallelism؛ Offset موضع القراءة؛ Broker server؛ Retention مدة الاحتفاظ.
داخل consumer group يقرأ partition عضو واحد فقط في الوقت نفسه؛ groups المختلفة تقرأ نفس data دون تنافس.
Ordering مضمون داخل partition لا عبر topic كلها؛ partition by key يحافظ على ترتيب أحداث نفس entity.
السرعة من sequential disk I/O وzero-copy وbatching، لا من الاحتفاظ بكل شيء في RAM.
RabbitMQ أفضل غالباً لـtask dispatch وrouting معقد وحجم صغير؛ Kafka عندما نحتاج replay + fan-out + throughput.

الفروق الحاسمة

Queue: deliver ثم delete

Kafka log: retain ثم consumers يختارون offset

Partition = parallelism + local order

Consumer group = workload sharing

P02عرض طلابي · 40%Apache HadoopHDFS للتخزين، MapReduce للمعالجة، YARN للموارد

الفكرة في جملة

Hadoop يقسم data إلى blocks موزعة ويحرّك code إلى مكان data، ثم ينفذ Map → Shuffle/Sort → Reduce على commodity hardware.

لماذا يهم؟

المشكلة ليست حجم disk فقط بل زمن نقل/قراءة petabytes؛ parallelism وreplication يجعلان التخزين والمعالجة قابلين للتوسع والتحمل.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةhadoop

P02 · APACHE HADOOP

انقل الكود إلى مكان الـblocks

NameNode · metadata onlyلا يخزن محتوى الملف

/weather.csv → B1:A,B · B2:B,C · B3:C,A

DataNode A

B1B3′

Map container ↓ same node

DataNode B

B2B1′

Map container ↓ same node

DataNode C

B3B2′

Map container ↓ same node

YARNResourceManagerNodeManagersContainers · CPU / RAM

01 · MAP(2024, 32)(2023, 28)(2024, 35)

02 · SHUFFLE & SORT2024 → [32, 35]2023 → [28]

03 · REDUCE2024 → 352023 → 28

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

HDFS: files كبيرة، blocks 128MB، replication افتراضي 3، ونمط Write Once Read Many.
NameNode يحفظ namespace وmetadata ومواقع blocks ولا يحفظ content؛ DataNodes تحفظ blocks وترسل heartbeats.
Map ينتج key/value، Shuffle & Sort يجمع القيم حسب key، Reduce يحسب output لكل key.
Data locality = نقل code الصغير إلى node التي تحمل block بدلاً من نقل data الضخمة عبر network.
YARN ResourceManager عالمي، NodeManager لكل machine، والـcontainers هي حصص CPU/RAM لتشغيل tasks.
CRC يكشف corruption ويتيح جلب replica سليمة؛ SequenceFile يعالج مشكلة ملايين tiny files.

الفروق الحاسمة

NameNode = metadata

DataNode = actual blocks

MapReduce = processing

YARN = resource scheduling

P03عرض طلابي · 40%Apache HiveSQL وmetadata فوق HDFS/Object Storage

الفكرة في جملة

Hive data warehouse/query engine يترجم SQL إلى distributed plan؛ لا يخزن data بنفسه بل يدير metadata ويقرأ files من HDFS أوobject storage.

لماذا يهم؟

جعل batch analytics وETL متاحاً لمستخدمي SQL بدلاً من كتابة MapReduce Java لكل query.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةhive

P03 · APACHE HIVE

صورة أشعة للاستعلام: metadata مقابل bytes

SELECT city, AVG(fare)
FROM trips
WHERE country = 'SY'
GROUP BY city;

Client · JDBC / BIHiveServer2DriverCompilerOptimizer · CBOTez / SparkResult

HDFS / S3 · actual bytes✓ /trips/country=SY/*.orc · scanned× /trips/country=DE/*.orc · pruned

Partitioningقيمة column → مجلداتBucketinghash(key) % N → fixed buckets

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

المسار: Client → HiveServer2 → Driver → Compiler → Optimizer → Tez/Spark → Storage، والMetastore يزوّد الجميع بالschema/partitions/statistics.
Metastore catalog مركزي تشاركه engines مثل Spark وTrino وPresto؛ هذه إحدى أسباب استمرار Hive.
ORC columnar ومفضل في Hive؛ Parquet cross-engine؛ Avro جيد لـschema evolution؛ text/CSV أبسط وأبطأ للتحليل.
Partitioning يقسم حسب column ويتيح partition pruning؛ Bucketing يستخدم hash ويحسن joins/sampling.
Optimizations: predicate/column/partition pruning، vectorization، map-side join، CBO وjoin reordering.
ACID عبر write IDs وdelta files وsnapshot isolation وcompaction، ويدعم INSERT/UPDATE/DELETE/MERGE.

الفروق الحاسمة

Hive يخزن metadata

HDFS/Object Storage يخزن bytes

Partitioning حسب قيمة column

Bucketing حسب hash إلى عدد buckets

P04عرض طلابي · 40%Apache SparkLazy DAG وin-memory unified analytics

الفكرة في جملة

Spark يبني DAG كسولاً من transformations ثم ينفذه عند action؛ caching وlineage يجعلان iterative analytics أسرع من disk-heavy MapReduce.

لماذا يهم؟

يجمع SQL وstreaming وML وgraphs في engine واحدة ويدعم Python/Scala/R/Java/SQL.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةspark

P04 · APACHE SPARK

لا شيء يُنفذ قبل أول Action

df.filter(...) .groupBy(...) .select(...)

0 jobs · 0 tasksTransformations · lazySpark يجمع العمليات ويحسن الخطة أولاً.

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

RDD immutable fault-tolerant collection مقسمة؛ DataFrame أعلى abstraction مع schema وoptimizer.
Transformations مثل map/filter/select lazy؛ Actions مثل count/show/collect/save تشغل DAG.
Driver يبني DAG ويجدول؛ Cluster Manager يخصص الموارد؛ Executors على workers تنفذ tasks على partitions وتخزن cache.
Fault recovery عبر lineage وإعادة حساب partition المفقودة، لا replication لكل intermediate result.
استخدم Spark للـlarge ETL وiterative ML وunified analytics؛ تجنبه لبيانات صغيرة أوsub-millisecond serving أوmutable state.
مشكلات شائعة: data skew، shuffle كبير، insufficient executor memory وcollect() على driver.

الفروق الحاسمة

Transformation لا تنفذ فوراً

Action تشغل الـDAG

Driver ينسق

Executors تنفذ وتcache

P05عرض طلابي · 40%Apache FlinkStateful true streaming مع Event Time وExactly-once

الفكرة في جملة

Flink يعالج كل event عند وصوله ويحتفظ distributed state؛ event time وwatermarks يصححان النتائج حتى مع late/out-of-order data.

لماذا يهم؟

مناسب لـfraud detection وdynamic pricing وtelemetry حيث milliseconds وstateful windows والدقة بعد failures مهمة.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةflink

P05 · APACHE FLINK

Watermark للزمن، Checkpoint للتعافي

#1 · event_time 10:00:01#2 · event_time 10:00:04WM = 10:00:03تقدّم Event Time

Window · [10:00:00–10:00:05)Allowed lateness · 10sKeyed State · rider-42 → count = 2

Kafka offsets + Operator stateCheckpoint #51Failure → restore + resume

Watermark → event-time progressCheckpoint → failure recovery

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

يتعامل مع unbounded streams وbounded data بالمحرك نفسه؛ batch حالة محدودة من stream processing.
Processing Time وقت وصول event إلى operator؛ Event Time timestamp داخل event؛ Ingestion Time حل وسط.
Watermark تقدير لتقدم event time ويحدد متى تغلق windows مع السماح بدرجة lateness.
Keyed State لكل key، Operator State للoperator؛ backends مثل memory أوRocksDB حسب الحجم والمتانة.
Checkpoint snapshot متسق للstate وpositions؛ recovery يعيد التشغيل لتحقيق exactly-once مع sources/sinks متوافقة.
JobManager ينسق job/checkpoints، وTaskManagers يشغلون task slots؛ DataStream API يبني operators graph.

الفروق الحاسمة

Flink: event-at-a-time true streaming

Spark Streaming تقليدياً micro-batches

Watermark يعالج lateness

Checkpoint يعالج failure recovery

P06عرض طلابي · 40%Apache NiFiVisual dataflow: ingest، route، transform وprovenance

الفكرة في جملة

NiFi يدير حركة data عبر graph مرئية من Processors وConnections؛ كل FlowFile يحمل content وattributes ويتتبع provenance.

لماذا يهم؟

يوصل مصادر وبروتوكولات متنوعة بسرعة مع backpressure وrouting وretry دون كتابة pipeline كاملة يدوياً.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةnifi

P06 · APACHE NIFI

FlowFile يتحرك، والـqueue تحمي النظام

Web Server Logs → Apache NiFi → HDFS

TailFilereads app.log

Queue · 14/100

RouteOnAttributeERROR / WARN only

Queue · 14/100

UpdateAttributetimestamp + source

Queue · 14/100

PutHDFS/logs/

FlowFile inspector

Attributesseverity=ERROR · source=web-01

Contentactual log bytes

ProvenanceRECEIVE → ROUTE → ATTRIBUTES_MODIFIED → SENDPutHDFS failure → retry queue

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

FlowFile = content + attributes؛ Processor ينفذ ingest/route/transform/output؛ Connection queue تربط processors.
Controller Services تشارك clients/configs مثل DB connection؛ Process Groups تنظّم flow وتعيد استخدامها.
Backpressure يوقف upstream عندما تمتلئ queue وفق object count أوdata size.
Repositories: FlowFile Repository للحالة، Content Repository للbytes، Provenance Repository لتاريخ كل حدث.
NiFi مناسب data movement وvisual orchestration؛ Kafka مناسب durable high-throughput event log وreplay.
يعملان معاً غالباً: NiFi يجمع وينظف ويرسل إلى Kafka؛ Kafka يفصل consumers ويحفظ stream.

الفروق الحاسمة

NiFi = flow management وتحويل/route

Kafka = durable log وconsumer decoupling

Attributes = metadata

Content = bytes الفعلية

P07عرض طلابي · 40%Big Data Architectural PatternsBatch، Stream، Lambda، Kappa وMedallion

الفكرة في جملة

الاختيار يبدأ من trade-off بين latency وthroughput/reprocessing؛ Lambda وKappa time architectures، بينما Medallion ينظم جودة data lake ويمكن تركيبه مع أي منهما.

لماذا يهم؟

الـpattern يقرر عدد paths، source of truth، طريقة replay، وكلفة إبقاء logic متطابقة.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةbigdata-patterns

P07 · BIG DATA PATTERNS

اختر مسار الزمن، ثم نظّم جودة الـlake

AppsKafkaFlinkMatching / fraud · <200ms

يفوز بالـlatency، لكن ordering وstate وexactly-once أصعب.

BRONZEraw · immutableSILVERclean · deduplicate · conformGOLDbusiness-ready · BI / MLMedallion = quality axis، وليس latency path

ONE TRIP EVENT · SEVEN ROLES

Apps / APIsNiFiingest · routeKafkaretain · replay

Flinkevent time · stateAlerts / live product

HDFS · Bronzeraw bytesSparkETL · MLHiveSQL · MetastoreBI / reports

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

Batch لمعالجة history بكفاءة ونتائج متأخرة؛ Stream لأحداث unbounded ورد فعل sub-second.
Lambda: Batch layer للحقيقة وإعادة الحساب + Speed layer للنتائج الفورية + Serving layer لدمج views.
عيب Lambda الأكبر duplicate logic وreconciliation بين batch وspeed paths.
Kappa: stream log واحد وprocessing code واحد؛ replay من log لإعادة البناء، أبسط إذا stream-first والretention كافٍ.
Medallion: Bronze raw/immutable → Silver cleaned/conformed → Gold business-ready aggregates.
Medallion orthogonal: ينظم lake quality ولا يقرر وحده batch أمstream.

الفروق الحاسمة

Lambda = مساران batch + speed

Kappa = stream path واحد + replay

Time architecture: Lambda/Kappa

Lake organization: Medallion

P08عرض طلابي · 40%DockerImages قابلة للنقل وContainers معزولة على host واحد

الفكرة في جملة

Container يشغّل application وdependencies كعملية معزولة تشارك host kernel؛ Image template read-only مبني من layers.

لماذا يهم؟

يحل اختلاف البيئات: Build مرة، push إلى registry، run بنفس السلوك على أي host متوافق.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةdocker

P08 · STUDY MAP

Docker · Build, Ship, Run

افصل بين تعليمات البناء، القالب الثابت، مكان التخزين، والعملية التي تعمل فعلياً.

01Dockerfileتعليمات بناء نصية

02Imageطبقات للقراءة فقط

03Registryتخزين ومشاركة الصورoptional for local run

04Containerعملية تعمل + طبقة قابلة للكتابة

Image Container

على الجهاز نفسه يمكن التشغيل مباشرة؛ الـRegistry ليست شرطاً.

Virtual Machine~ GB · slower boot

App + Bins/Libs
Guest OS per VM
Hypervisor
Host OS
Infrastructure

Container~ MB · near-instant

App + Bins/Libs
Isolated containers
Docker Engine
Host OS · shared kernel
Infrastructure

الفاصل الامتحاني: الـVM تجرّ نظام تشغيل ضيفاً لكل نسخة؛ الـContainer تشارك نواة المضيف.

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

VM virtualizes hardware وتحمل Guest OS؛ Container virtualizes OS/user space ويشارك kernel، لذا أصغر وأسرع وأعلى density.
Dockerfile تعليمات build؛ Image template read-only؛ Container instance running بطبقة writable؛ Registry يخزن images.
Docker client يرسل أوامر إلى daemon عبر socket/network؛ daemon يبني images ويدير containers/networks/volumes.
Networks: bridge افتراضي، host بلا network isolation، none معزول، وport publishing مثل 8080:80.
Container ephemeral؛ Volume مستقل عن lifecycle، وBind Mount يربط directory من host.
Docker Compose يصف multi-container app في YAML ويشغله على host؛ Kubernetes يدير scale وself-healing عبر hosts كثيرة.

الفروق الحاسمة

Image = template ثابت

Container = instance تعمل

Volume يديره Docker

Bind mount path مباشر من host

P09عرض طلابي · 40%KubernetesDeclarative orchestration، self-healing وservice discovery

الفكرة في جملة

Kubernetes يقارن desired state المعلن في YAML بالactual state ويشغل reconciliation loops لإعادة pods وتوسيعها وتحديثها.

لماذا يهم؟

Docker وحده يدير host واحدة؛ cluster تحتاج scheduling وself-healing وrolling updates وstable networking عبر machines.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةkubernetes

P09 · STUDY MAP

Kubernetes · Reconciliation Never Stops

أنت تصرّح بالحالة المطلوبة، والمكوّنات تعيد الواقع إليها باستمرار.

01Desired state · YAMLkubectl apply

02API Serverبوابة كل قراءة وكتابة

03etcdيخزن حالة العنقود

04Controller Managerيكتشف الفرق ويطلب التصحيح

05Schedulerيختار Worker Node

06Kubelet → Running Podيشغّل ويراقب ثم يعيد status

Pod status → API Server → etcd → compare againRECONCILIATION LOOP

MANAGEMENT

DeploymentReplicaSetPod A · Pod B · Pod C

الـDeployment يصرّح بالنسخ والتحديث؛ لا ننشئ Pods يدوياً عادةً.

TRAFFIC

ClientIngressServiceHealthy Pods

الـService عنوان ثابت أمام Pods تتبدل عناوينها.

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

Control Plane: API Server بوابة، etcd state store، Scheduler يختار node، Controller Manager يصحح الفرق.
Worker: kubelet يضمن تشغيل Pods، container runtime يشغّل containers، kube-proxy/service networking يوجّه traffic.
Pod أصغر deployable unit ويشارك containers داخله network/storage؛ غالباً container واحدة رئيسية.
Deployment يدير ReplicaSet وrolling updates؛ Service عنوان ثابت/load balancing؛ Ingress يوجه HTTP/HTTPS من الخارج.
Self-healing يعيد pod أوينقلها، HPA يوسع حسب metrics، readiness تمنع traffic قبل الجاهزية.
التسلسل التشغيلي: kubectl/YAML → API Server → etcd/controllers/scheduler → kubelet → Pod.

الفروق الحاسمة

Deployment يدير replicas/rollout

Service يعطي endpoint ثابتاً للPods المتغيرة

Docker يشغّل container

Kubernetes ينسق containers كcluster

P10عرض طلابي · 40%Service Worker & PushProgrammable network proxy، offline cache وbackground events

الفكرة في جملة

Service Worker script معزول عن الصفحة يعترض fetch events ويدير Cache API ويستيقظ لأحداث push/sync؛ لا يملك DOM ويحتاج secure context.

لماذا يهم؟

يمنح offline-first loading وcache policies وpush notifications حتى عندما لا تكون الصفحة مفتوحة.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةservice-worker

P10 · STUDY MAP

Service Worker · Event-Driven, Not Always Alive

افصل دورة الحياة عن اشتراك Push الذي يحدث مرة، وعن تسليم كل رسالة لاحقاً.

01Registerregister('/sw.js')
02InstallPre-cache assets
03ActivateClean caches · claim clients
04Idle / terminatedالمتصفح قد يوقفه
05Event wakes itfetch · push · sync · click

No DOMHTTPS requiredPage ↔ SW via postMessageGlobal memory is not durable

ONE TIME

Subscription

PermissionPushManager.subscribe()endpoint + p256dh + authPOST /api/subscribeApp Server stores it

EACH MESSAGE

Encrypted delivery

App Server · VAPIDPush ServiceBrowser wakes SWpush eventshowNotification()notificationclick

FCM / Mozilla Autopush / APNs تمرر bytes مشفّرة؛ لا تحتاج قراءة المحتوى.

CACHE CHOOSER

Match policy to resource

CSS · JS · images · fonts: Cache First
Fresh API data · HTML: Network First
Fast now + refresh later: Stale-While-Revalidate
Guaranteed pre-cached file: Cache Only
POST · payment · never cache: Network Only

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

Lifecycle: register → install (precache) → activate (cleanup/claim) → idle/terminate → fetch/push/sync events.
Cache First للstatic assets، Network First للfresh API/HTML، Stale-While-Revalidate لعرض سريع مع تحديث خلفي، وNetwork Only للpayments/POST.
HTTP cache تلقائي بالheaders؛ Cache API programmable/versioned ويحتاج cleanup وسياسة واضحة.
Push flow: permission → PushManager subscription → حفظ endpoint/keys → application server يرسل عبر browser push service → browser يوقظ SW → showNotification.
VAPID يعرف application server، والpayload مشفر end-to-end؛ push service يمرر الرسالة ولا يحتاج قراءة المحتوى.
notificationclick يفتح/يركز window؛ Background Sync يؤجل actions حتى عودة network.

الفروق الحاسمة

Service Worker لا DOM

Page JS يتعامل مع DOM ويتواصل عبر postMessage

HTTP Cache browser-controlled

Cache API developer-controlled

P11عرض طلابي · 40%WebSubPublisher، Hub، Subscriber بدلاً من polling

الفكرة في جملة

Subscriber يسجل callback عند Hub لموضوع Publisher؛ Hub يتحقق challenge ثم يدفع كل update عبر POST.

لماذا يهم؟

يستبدل pull المتكرر والمتأخر بـpush لحظي، ويجعل Hub نقطة fan-out مشتركة لمصادر وsubscribers كثيرين.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةwebsub

P11 · STUDY MAP

WebSub · Subscribe First, Push Later

الـHub هو الوسيط: يتحقق من callback أولاً، ثم يجلب التحديث ويوزّعه.

Publisherمصدر الـtopic/feedHubاشتراك + fan-outSubscriberيمتلك callback

ACT 01

Subscribe + verify

01
Publisher / feedSubscriber
Feed advertises the Hub URL
02
SubscriberHub
hub.mode=subscribe · hub.topic · hub.callback
03
HubSubscriber
GET ?hub.challenge=xxxxx
04
SubscriberHub
200 + exact challenge token

✓ Hub registers a verified subscription

ACT 02

Publish + push

01
PublisherTopic URL
Publishes new content
02
PublisherHub
hub.mode=publish · hub.url=<topic>
03
HubTopic URL
Fetches the latest content
04
HubAll Subscribers
POST content → callbacks

✓ One update, immediate fan-out

PollingGET · GET · GET · maybe nothingdelayed + repeated load

WebSubsubscribe once · POST on changeinstant + work only on updates

افتح التفاصيل الكاملة5 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

Publisher ينتج topic/feed ويعلن Hub؛ Hub يدير subscriptions وfetch/push؛ Subscriber يستقبل updates على callback.
الاشتراك يرسل hub.mode=subscribe وhub.topic وhub.callback.
Verification: Hub يرسل GET مع hub.challenge، والSubscriber يعيد نفس token ليثبت ملكية callback.
Publish: Publisher يخطر Hub بـhub.mode=publish وtopic URL؛ Hub يجلب content ثم POST لكل subscribers.
مناسب blogs وRSS/Atom وcontent updates؛ load يحدث عند update فقط لا كل interval.

الفروق الحاسمة

Polling: client يسأل مراراً

WebSub: Hub يدفع عند تغير topic

Publisher يخطر فقط

Hub يجلب ويوزع content

P12عرض طلابي · 40%OpenAPI & AsyncAPIMachine-readable contracts للـrequest/response والevents

الفكرة في جملة

OpenAPI يصف REST paths/operations؛ AsyncAPI يصف broker channels/messages/operations. هما متكاملان لأن system قد يبدأ HTTP request ثم يصدر event.

لماذا يهم؟

Design-first contract يتيح frontend/backend أوproducer/consumer العمل بالتوازي مع docs وvalidation وcode generation.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةapi-contracts

P12 · STUDY MAP

OpenAPI + AsyncAPI · One Hybrid Story

العقد يوثّق الاتصال ولا ينقل الرسالة؛ النظام الواحد قد يحتاج العقدين.

01Rider Appيرسل طلب حجز

OpenAPI contractPOST /ride→

02Backendيردّ ثم يصدر حدثاً

AsyncAPI contractRideRequested→

03Kafka topicride.requested

subscribeWebSocket→

04Driver Appsتتفاعل بلا polling

OpenAPIREQUEST ↔ RESPONSE

Core: paths + HTTP operations
Protocol: HTTP / HTTPS
Behavior: Caller waits
Best fit: CRUD APIs

AsyncAPIPUBLISH → SUBSCRIBE

Core: channels + messages + operations
Protocols: Kafka · MQTT · AMQP · WebSocket
Behavior: Consumers react
Best fit: Streaming · messaging

لا تخلط: OpenAPI وAsyncAPI مواصفات machine-readable؛ ليستا transport أوbroker.

افتح التفاصيل الكاملة5 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

OpenAPI fields: openapi، info، servers، paths، components، security؛ البروتوكول غالباً HTTP/HTTPS.
AsyncAPI fields: asyncapi، info، servers، channels، operations، messages؛ يدعم Kafka/MQTT/AMQP/WebSocket وغيرها.
OpenAPI core building block path + HTTP operation؛ AsyncAPI core building block channel + message + send/receive action.
Tooling ينتج interactive docs وSDKs/server stubs ويطبّق schema validation ويكشف contract drift.
Ride example: POST /ride موثق OpenAPI، ثم RideRequested على Kafka موثق AsyncAPI، ثم drivers تتفاعل.

الفروق الحاسمة

OpenAPI: paths + request/response

AsyncAPI: channels + messages/events

Synchronous caller ينتظر

Asynchronous consumers تتفاعل لاحقاً

P13عرض طلابي · 40%REST vs gRPCResource-oriented public APIs مقابل typed internal RPC

الفكرة في جملة

REST architectural style يتعامل مع resources عبر HTTP semantics؛ gRPC يستدعي typed service methods المعرفة في .proto عبر HTTP/2 وProtobuf.

لماذا يهم؟

لا يوجد فائز مطلق: openness وbrowser/cacheability ترجح REST، بينما performance وstrict contracts وstreaming ترجح gRPC داخل النظام.

الخريطة العامة

الفكرة التي يجب تمييزها

خريطة بصريةrest-grpc

P13 · STUDY MAP

REST, gRPC, or Kafka?

ابدأ بمن يستدعيك وبشكل الاتصال؛ لا يوجد فائز مطلق.

Who will call this?

PUBLIC / BROWSER / THIRD PARTYREST

Open · browser-native · cacheable · CRUD

INTERNAL · BOTH SIDES CONTROLLEDgRPC

Typed · codegen · streaming · hot paths

FAN-OUT · AUDIT · FIRE-AND-FORGETKafka / queue

Async event log · decoupled consumers

gRPC STREAMING

Four RPC modes

● → ●Unary1 request → 1 responseGetUser(id) → User

● → ● ● ●Server streaming1 request → many responsesSubscribePrices() → stream Quote

● ● ● → ●Client streamingmany requests → 1 responseUploadLogs(stream LogEntry) → Ack

● ● ⇄ ● ●Bidirectionalboth sides stream independentlyChat(stream Msg) ↔ stream Msg

Browsers · Mobile · Third partiesREST / JSON →API GatewaygRPC →Internal servicesOrderPlaced →Kafka → independent consumers

افتح التفاصيل الكاملة6 نقاط + الفروق والفخ الامتحاني

ما يجب أن تعرفه

REST constraints: client-server، stateless، cacheable، uniform interface، layered system، وcode-on-demand اختياري.
HTTP semantics: GET safe/idempotent، PUT/DELETE idempotent، POST عادةً ليس idempotent؛ استخدم status codes وresource URIs.
gRPC contract في proto3، protoc يولد client/server stubs، وProtobuf يرسل field tags وbinary types بلا أسماء JSON المتكررة.
أربعة RPC modes: Unary، Server streaming، Client streaming، Bidirectional.
gRPC يحتاج HTTP/2 وtooling مثل grpcurl/reflection؛ browser يحتاج gRPC-Web proxy.
Hybrid شائع: REST/JSON عند edge وgRPC بين internal services؛ Kafka للأحداث async وليس بديلاً مطابقاً لكليهما.

الفروق الحاسمة

REST: nouns/resources + HTTP verbs

gRPC: service methods/actions

OpenAPI optional contract

Proto mandatory schema-first contract

CONFUSION REPAIR

قارن على محور واحد، ثم قرّر.

لا تحفظ أسماء الأدوات منفصلة. اربط كل أداة باتجاه البيانات، نوع النقل، ودورها الوحيد داخل النظام.

PROTOCOL CHOOSER

اتجاه الاتصال والنقل والاستخدام

مقارنة بروتوكولات الويب حسب الاتجاه والنقل والميزة والاستخدام
التقنية	الاتجاه	النقل	الميزة الحاسمة	أفضل استخدام
HTTP/1.1	Request/response	TCP	Persistent + عدة connections	Web APIs التقليدية
HTTP/2	Request/response + streams	TCP	Multiplexing + HPACK	Modern web/gRPC transport
HTTP/3	Request/response + streams	QUIC/UDP	Independent streams + migration	Mobile/lossy networks
SSE	Server → Client	HTTP	Text + auto-reconnect	Feeds/logs/dashboards
WebSocket	Bidirectional	TCP بعد Upgrade	Text/binary + low overhead	IoT/games/collaboration
WebRTC DataChannel	Peer ↔ Peer	ICE/DTLS/SCTP	Direct encrypted binary	Edge/P2P transfer
gRPC	Typed RPC + 4 streaming modes	HTTP/2	Protobuf + codegen	Internal services
WebSub	Publisher → Hub → Subscriber	HTTP callbacks	Topic push + verification	Feed updates

التقنية
HTTP/1.1
الاتجاه
Request/response
النقل
TCP
الميزة الحاسمة
Persistent + عدة connections
أفضل استخدام
Web APIs التقليدية
التقنية
HTTP/2
الاتجاه
Request/response + streams
النقل
TCP
الميزة الحاسمة
Multiplexing + HPACK
أفضل استخدام
Modern web/gRPC transport
التقنية
HTTP/3
الاتجاه
Request/response + streams
النقل
QUIC/UDP
الميزة الحاسمة
Independent streams + migration
أفضل استخدام
Mobile/lossy networks
التقنية
SSE
الاتجاه
Server → Client
النقل
HTTP
الميزة الحاسمة
Text + auto-reconnect
أفضل استخدام
Feeds/logs/dashboards
التقنية
WebSocket
الاتجاه
Bidirectional
النقل
TCP بعد Upgrade
الميزة الحاسمة
Text/binary + low overhead
أفضل استخدام
IoT/games/collaboration
التقنية
WebRTC DataChannel
الاتجاه
Peer ↔ Peer
النقل
ICE/DTLS/SCTP
الميزة الحاسمة
Direct encrypted binary
أفضل استخدام
Edge/P2P transfer
التقنية
gRPC
الاتجاه
Typed RPC + 4 streaming modes
النقل
HTTP/2
الميزة الحاسمة
Protobuf + codegen
أفضل استخدام
Internal services
التقنية
WebSub
الاتجاه
Publisher → Hub → Subscriber
النقل
HTTP callbacks
الميزة الحاسمة
Topic push + verification
أفضل استخدام
Feed updates

ONE JOB PER TOOL

دور كل أداة وحدودها

مقارنة أدوات منظومة البيانات حسب الوظيفة والفكرة المميزة وما لا تفعله
الأداة	وظيفتها	الفكرة المميزة	ليست
NiFi	تحريك وربط وتحويل dataflows	FlowFile + visual processors	ليس durable event log
Kafka	Backbone للأحداث	Retention + offsets + fan-out	ليس ETL visual tool
Flink	Low-latency stateful streaming	Event Time + state + checkpoints	أعقد من batch بسيط
Spark	Unified batch/SQL/ML	Lazy DAG + executors + caching	ليس sub-ms serving
Hadoop	Distributed storage/batch foundation	HDFS + MapReduce + YARN	Disk-heavy latency
Hive	SQL/metadata فوق lake	Metastore + optimizer + ORC	ليس مخزن bytes بنفسه
Docker	Packaging على host	Image → Container	لا ينسق cluster وحده
Kubernetes	Cluster orchestration	Desired state + reconciliation	لا يبني image

الأداة
NiFi
وظيفتها
تحريك وربط وتحويل dataflows
الفكرة المميزة
FlowFile + visual processors
ليست
ليس durable event log
الأداة
Kafka
وظيفتها
Backbone للأحداث
الفكرة المميزة
Retention + offsets + fan-out
ليست
ليس ETL visual tool
الأداة
Flink
وظيفتها
Low-latency stateful streaming
الفكرة المميزة
Event Time + state + checkpoints
ليست
أعقد من batch بسيط
الأداة
Spark
وظيفتها
Unified batch/SQL/ML
الفكرة المميزة
Lazy DAG + executors + caching
ليست
ليس sub-ms serving
الأداة
Hadoop
وظيفتها
Distributed storage/batch foundation
الفكرة المميزة
HDFS + MapReduce + YARN
ليست
Disk-heavy latency
الأداة
Hive
وظيفتها
SQL/metadata فوق lake
الفكرة المميزة
Metastore + optimizer + ORC
ليست
ليس مخزن bytes بنفسه
الأداة
Docker
وظيفتها
Packaging على host
الفكرة المميزة
Image → Container
ليست
لا ينسق cluster وحده
الأداة
Kubernetes
وظيفتها
Cluster orchestration
الفكرة المميزة
Desired state + reconciliation
ليست
لا يبني image

ACTIVE RECALL

حدّد الحاجة قبل اختيار الأداة.

جاوب في ذهنك أولاً، ثم افتح البطاقة للتحقق.

Directionمن يرسل لمن؟

SSE: Server → Client · Feeds/logs/dashboards
WebSocket: Bidirectional · IoT/games/collaboration
WebRTC: Peer ↔ Peer · Edge/P2P transfer

Integrationطلب مباشر أم أحداث قابلة للإعادة؟

REST: Browser / public API · resource-oriented request/response
gRPC: Typed RPC + 4 streaming modes · Internal services
Kafka: Backbone للأحداث · Retention + offsets + fan-out

Processingما نوع المعالجة المطلوبة؟

Spark: Unified batch/SQL/ML · Lazy DAG + executors + caching
Flink: Low-latency stateful streaming · Event Time + state + checkpoints
Hadoop: Distributed storage/batch foundation · HDFS + MapReduce + YARN
Hive: SQL/metadata فوق lake · Metastore + optimizer + ORC

Operationsتغليف process أم إدارة cluster؟

Docker: Packaging على host · Image → Container
Kubernetes: Cluster orchestration · Desired state + reconciliation

ادرس بترتيب الامتحان، لا بترتيب الملفات.

مساران، ثم محاكاة واحدة.

كل جيل يعالج bottleneck مختلفاً: HTTP/1.1 يقلّل فتح الاتصالات، HTTP/2 يضاعف streams داخل TCP واحد، وHTTP/3 ينقل النقل إلى QUIC فوق UDP لتقليل أثر packet loss.

لماذا يهم؟

كيف يعمل المفهوم؟

عند فقدان packet، من يتوقّف؟

gRPC فرع فوق HTTP/2

ما يجب أن تعرفه

الفروق الحاسمة

الفرق الحاسم هو direction وconnection lifetime: SSE قناة push أحادية من server، بينما WebSocket قناة full-duplex دائمة للطرفين.

لماذا يهم؟

كيف يعمل المفهوم؟

كيف تستمر المحادثة؟

المنتِج أسرع بعشر مرات من المستهلِك

ما يجب أن تعرفه

الفروق الحاسمة

WebRTC ينقل البيانات مباشرة بين peers، لكن إنشاء الطريق يحتاج signaling خارجي وICE لاختيار Host أوSTUN أوTURN.

لماذا يهم؟

كيف يعمل المفهوم؟

Signaling ينشئ الطريق؛ DataChannel يحمل البيانات

لماذا لا تكبر شبكة mesh بسهولة؟

ما يجب أن تعرفه

الفروق الحاسمة

Wasm binary instruction format يشغّل كود Rust/C/C++ قرب native speed؛ JavaScript يبقى مسؤولاً عن DOM وI/O بينما Wasm يعالج CPU-bound work.

لماذا يهم؟

كيف يعمل المفهوم؟

ما يجب أن تعرفه

الفروق الحاسمة

الـSPA ترسل HTML shell وتبني DOM بعد XHR/fetch؛ headless browser يشغّل JavaScript كمتصفح حقيقي ثم يتيح navigation وextraction وnetwork interception.

لماذا يهم؟

كيف يعمل المفهوم؟

HTTP Client / View Source

Headless Browser / Rendered DOM

متى أصبحت الصفحة جاهزة؟

ما يجب أن تعرفه

الفروق الحاسمة

الـbrowser يمكن أن يكون Extract actor: يسجل الدخول، يختار report، ينتظر background job، ينزل الملف؛ ثم transform/load خارج الصفحة.

لماذا يهم؟

كيف يعمل المفهوم؟

حالة المصادقة

انتظار bounded، لا loop أبدي

ما يجب أن تعرفه

الفروق الحاسمة

OAuth يفوض access، OIDC يضيف authentication وID Token، وJWT format موقّع يمكن للـresource server التحقق منه دون الرجوع كل مرة إلى auth server.

لماذا يهم؟

كيف يعمل المفهوم؟

هل يوجد إنسان يملك البيانات ويوافق؟

أرسل كل token إلى المكان الصحيح

JWT: القراءة ليست ثقة

ما يجب أن تعرفه

الفروق الحاسمة

Kafka ليس queue تقليدية تحذف الرسالة بعد التسليم؛ إنه append-only distributed log، وكل consumer group يملك offsets مستقلة.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

الفروق الحاسمة

Hadoop يقسم data إلى blocks موزعة ويحرّك code إلى مكان data، ثم ينفذ Map → Shuffle/Sort → Reduce على commodity hardware.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

الفروق الحاسمة

Hive data warehouse/query engine يترجم SQL إلى distributed plan؛ لا يخزن data بنفسه بل يدير metadata ويقرأ files من HDFS أوobject storage.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

الفروق الحاسمة

Spark يبني DAG كسولاً من transformations ثم ينفذه عند action؛ caching وlineage يجعلان iterative analytics أسرع من disk-heavy MapReduce.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

الفروق الحاسمة

Flink يعالج كل event عند وصوله ويحتفظ distributed state؛ event time وwatermarks يصححان النتائج حتى مع late/out-of-order data.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

الفروق الحاسمة

NiFi يدير حركة data عبر graph مرئية من Processors وConnections؛ كل FlowFile يحمل content وattributes ويتتبع provenance.

لماذا يهم؟

الفكرة التي يجب تمييزها

ما يجب أن تعرفه

عند فقدان `packet`، من يتوقّف؟

`gRPC` فرع فوق `HTTP/2`

`Signaling` ينشئ الطريق؛ `DataChannel` يحمل البيانات

لماذا لا تكبر شبكة `mesh` بسهولة؟