دردشة سريعة عن الـ Monolithic Architecture 💯
.
.
مش كل مشروع محتاج Architecture معقدة من البداية.
أحيانًا أبسط حل ممكن يكون هو الأنسب، وده بالضبط جوهر الـ Monolithic Architecture: تطبيق واحد، Codebase واحد، و عملية Deployment واحدة.
لكن بساطة الـ Monolith مش معناها إنه مناسب لكل الحالات، ومع نمو المشروع ممكن تظهر تحديات تخليك تفكر في Architecture مختلفة.
تعال نشوف مع بعض إيه مميزاته وعيوبه، وإمتى يكون اختيار مناسب فعلًا.
———
تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه:
- الـ UI (front-end).
- الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات).
- الـ database access (CRUD operations).
في الـ Monolithic Architecture… كل ده بيكون في codebase واحد، ويتعمله deploy كـ تطبيق واحد (single unit).
يعني لو عايز تعدل في جزء معين لازم تعمل Deploy للتطبيق كله تاني.
———
📌 مميزات الـ Monolithic Architecture
1- البساطة:
الكود كله في مكان واحد، سهل تفهم العلاقات بين الأجزاء المختلفة.
2- سهولة عملية الـ Development في البداية:
مثالي جدًا للـ MVP أو المشاريع الصغيرة.
3- أداء كويس:
مفيش network latency بين components (كلها في نفس العملية).
4- سهولة الـ Testing:
تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد.
———
📌 عيوب الـ Monolithic Architecture
1- صعوبة التوسّع (Scalability):
عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله.
2- الـ Codebase هيبقى ضخم ومعقد مع الوقت:
لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه.
3- ضعف المرونة في اختيار التكنولوجي:
مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack.
4- بطء في عملية الـ Deployment:
أي تعديل صغير لازم هتعمل Deploy التطبيق كله.
5- الـ Reliability ضعيفة:
لو جزء واحد وقع، ممكن يأثر على السيستم كله.
———
📌 إمتى تستخدم Monolithic Architecture؟
- لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة.
- لو عندك فريق صغير ومحتاج تقلل الـ overhead.
- لو لسه السيستم مش معقد ومش محتاج Scalability عالية.
———
الـ Monolithic: كل حاجة في تطبيق واحد.
الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل.
———
#software_development
.
.
مش كل مشروع محتاج Architecture معقدة من البداية.
أحيانًا أبسط حل ممكن يكون هو الأنسب، وده بالضبط جوهر الـ Monolithic Architecture: تطبيق واحد، Codebase واحد، و عملية Deployment واحدة.
لكن بساطة الـ Monolith مش معناها إنه مناسب لكل الحالات، ومع نمو المشروع ممكن تظهر تحديات تخليك تفكر في Architecture مختلفة.
تعال نشوف مع بعض إيه مميزاته وعيوبه، وإمتى يكون اختيار مناسب فعلًا.
———
تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه:
- الـ UI (front-end).
- الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات).
- الـ database access (CRUD operations).
في الـ Monolithic Architecture… كل ده بيكون في codebase واحد، ويتعمله deploy كـ تطبيق واحد (single unit).
يعني لو عايز تعدل في جزء معين لازم تعمل Deploy للتطبيق كله تاني.
———
📌 مميزات الـ Monolithic Architecture
1- البساطة:
الكود كله في مكان واحد، سهل تفهم العلاقات بين الأجزاء المختلفة.
2- سهولة عملية الـ Development في البداية:
مثالي جدًا للـ MVP أو المشاريع الصغيرة.
3- أداء كويس:
مفيش network latency بين components (كلها في نفس العملية).
4- سهولة الـ Testing:
تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد.
———
📌 عيوب الـ Monolithic Architecture
1- صعوبة التوسّع (Scalability):
عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله.
2- الـ Codebase هيبقى ضخم ومعقد مع الوقت:
لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه.
3- ضعف المرونة في اختيار التكنولوجي:
مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack.
4- بطء في عملية الـ Deployment:
أي تعديل صغير لازم هتعمل Deploy التطبيق كله.
5- الـ Reliability ضعيفة:
لو جزء واحد وقع، ممكن يأثر على السيستم كله.
———
📌 إمتى تستخدم Monolithic Architecture؟
- لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة.
- لو عندك فريق صغير ومحتاج تقلل الـ overhead.
- لو لسه السيستم مش معقد ومش محتاج Scalability عالية.
———
الـ Monolithic: كل حاجة في تطبيق واحد.
الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل.
———
#software_development
❤2
برنامج سفراء الذكاء الإصطناعي
.
.
البرنامج الأكبر لتأهيل غير المتخصصين لاستخدام تقنيات الذكاء الاصطناعي ونشر ثقافة الذكاء الاصطناعي في بيئات العمل.
———
تستهدف المبادرة تدريب غير المتخصصين في مجالات تكنولوجيا المعلومات، من العاملين في المؤسسات الحكومية والقطاع الخاص، وطلاب الجامعات، والمهتمين بفهم أساسيات الذكاء الاصطناعي وتطبيقاته العملية. ويُعد البرنامج التدريبي الذي تقدمه المبادرة من أوائل البرامج في المنطقة العربية التي تتيح لغير الخبراء فرصة تعلم مفاهيم مثل التعلم الآلي، والتعلم العميق، وتحليل البيانات، وتوظيف أدوات الذكاء الاصطناعي في تطوير العمل والخدمات.
———
📌️️ رابط الإنضمام:
https://nti.sci.eg/ai-ambassadors
.
.
البرنامج الأكبر لتأهيل غير المتخصصين لاستخدام تقنيات الذكاء الاصطناعي ونشر ثقافة الذكاء الاصطناعي في بيئات العمل.
———
تستهدف المبادرة تدريب غير المتخصصين في مجالات تكنولوجيا المعلومات، من العاملين في المؤسسات الحكومية والقطاع الخاص، وطلاب الجامعات، والمهتمين بفهم أساسيات الذكاء الاصطناعي وتطبيقاته العملية. ويُعد البرنامج التدريبي الذي تقدمه المبادرة من أوائل البرامج في المنطقة العربية التي تتيح لغير الخبراء فرصة تعلم مفاهيم مثل التعلم الآلي، والتعلم العميق، وتحليل البيانات، وتوظيف أدوات الذكاء الاصطناعي في تطوير العمل والخدمات.
———
📌️️ رابط الإنضمام:
https://nti.sci.eg/ai-ambassadors
❤2
مصطلحات مهمة في عالم الـ System Design 💯 (١٣)
.
.
إزاي نتعامل مع ملايين أو مليارات الـRecords؟ وإزاي نحتفظ بتاريخ كل تغيير حصل على الـData؟ وإيه اللي بيحصل لما الـApplication نفسه يتوزع على أكتر من Server؟
———
📌 Data Partitioning
تخيل عندك Database فيها مليارات الـUsers.
لو كل الـData موجودة في مكان واحد، مع الوقت الـDatabase ممكن تبقى كبيرة جدًا، والـQueries عليها تبقى تقيلة، وحتى الـScaling يبقى أصعب.
هنا بييجي Data Partitioning.
الفكرة ببساطة إننا نقسم الـData لأجزاء أصغر، بحيث يمكن إدارتها أو تخزينها بشكل منفصل.
مثلًا، ممكن نقسم الـUsers حسب الـCountry:
Egypt → Partition 1
Saudi Arabia → Partition 2
UAE → Partition 3
أو نقسم الـOrders حسب السنة:
2024 → Partition 1
2025 → Partition 2
2026 → Partition 3
المهم إن اختيار طريقة التقسيم يكون مبني على طريقة استخدام الـData والـQueries اللي بننفذها عليها.
لأن اختيار الـPartition Key بشكل غير مناسب ممكن يؤدي إلى توزيع غير متوازن للـData والـLoad، وظهور مشاكل زي Hot Partitions.
وده ممكن يساعدنا في توزيع الـLoad، وتحسين بعض الـQueries، وإدارة الـData على نطاق أكبر.
لكن فيه نقطة مهمة:
الـData Partitioning هو مفهوم عام لتقسيم الـData إلى أجزاء أصغر.
أما Sharding اللي تكلمنا عنه قبل كده، فهو شكل من أشكال الـPartitioning، وغالبًا بيستخدم لتوزيع الـData على أكثر من Shard، وغالبًا على Nodes أو Databases مختلفة.
طيب، إحنا قسمنا الـData واتخزنت بشكل أفضل.
لكن فيه سؤال مختلف:
هل لازم الـDatabase تحتفظ فقط بالـCurrent State للـData؟
ولا ممكن نخزن كل التغييرات اللي حصلت عليها من البداية؟
———
📌 Event Sourcing
في الـSystems العادية، غالبًا بنخزن الـCurrent State.
مثلًا عندنا Account رصيده:
Balance = $500
إحنا بنخزن إن الرصيد الحالي هو $500.
لكن في Event Sourcing، بنفكر بطريقة مختلفة.
بدل ما نخزن النتيجة النهائية فقط، بنخزن كل الـEvents اللي أدت للنتيجة دي.
مثلًا:
Deposit $1000
Withdraw $300
Withdraw $200
ومن الـEvents دي نقدر نعرف إن الـCurrent Balance هو $500.
الميزة هنا إننا مش بس عارفين الحالة الحالية، لكن عندنا تاريخ كامل للتغييرات اللي حصلت.
وده مفيد جدًا في أنظمة محتاجة Audit Trail أو محتاجة نعرف إزاي الـData وصلت للحالة الحالية.
لكن طبعًا فيه Trade-offs.
تخزين كل الـEvents ممكن يخلي الـData تكبر جدًا، وكمان قراءة الـCurrent State ممكن تحتاج إعادة بناء الحالة من عدد كبير من الـEvents، لذلك الأنظمة اللي بتستخدم Event Sourcing ممكن تستخدم حلول إضافية زي Snapshots لتقليل تكلفة إعادة بناء الـState.
طيب، لحد هنا بنتكلم عن تقسيم الـData وتخزين التغييرات.
لكن إيه اللي هيحصل لو النظام نفسه بقى متوزع على أكتر من Server؟
———
📌 Distributed Systems
تخيل إن عندك Application شغال على Server واحد.
كل حاجة موجودة في مكان واحد:
Client → Server → Database
الموضوع بسيط نسبيًا.
لكن لما الـApplication يكبر، ممكن نبدأ نوزع أجزاء النظام على Servers مختلفة.
كل Service ممكن تكون شغالة على أكتر من Server، وممكن الـServers تكون موجودة في أماكن مختلفة.
هنا بقى عندنا Distributed System.
ببساطة، هو System مكوّن من أكتر من Computer أو Node، بيتعاونوا مع بعض علشان يقدّموا وظيفة واحدة للمستخدم.
وده ممكن يساعدنا في تحقيق Scalability و Availability بشكل أفضل، حسب تصميم النظام، لأننا مش بالضرورة معتمدين على Server واحد فقط.
لكن في المقابل، النظام بيبقى أصعب بكتير.
في النظام البسيط، لو Function استدعت Function تانية، أنت عارف إنها هترجعلك نتيجة.
لكن في الـDistributed System، ممكن الـRequest يتبعت لـService تانية، والـNetwork يحصل فيه مشكلة، أو الـServer يقع، أو الـResponse يتأخر.
وفوق ده كله، ممكن يكون عندك أكتر من Server وكل واحد عنده نسخة مختلفة من الـData في نفس اللحظة.
وده بيخلينا نواجه مشاكل جديدة زي:
- Consistency
- Failures
- Network Partitions
- Latency
- الـCoordination بين الـNodes
وده بالضبط اللي بيخلي Distributed Systems مجال مختلف وأصعب من مجرد تشغيل Application على أكتر من Server.
———
💡 الخلاصة
• الـData Partitioning: تقسيم الـData لأجزاء أصغر علشان نقدر نديرها ونخزنها ونوزعها بشكل أفضل.
• الـEvent Sourcing: تخزين الـEvents اللي حصلت بدل الاعتماد على الـCurrent State فقط.
• الـDistributed Systems: نظام مكوّن من Nodes متعددة بتتعاون مع بعض لتقديم وظيفة واحدة.
———
#system_design
.
.
إزاي نتعامل مع ملايين أو مليارات الـRecords؟ وإزاي نحتفظ بتاريخ كل تغيير حصل على الـData؟ وإيه اللي بيحصل لما الـApplication نفسه يتوزع على أكتر من Server؟
———
📌 Data Partitioning
تخيل عندك Database فيها مليارات الـUsers.
لو كل الـData موجودة في مكان واحد، مع الوقت الـDatabase ممكن تبقى كبيرة جدًا، والـQueries عليها تبقى تقيلة، وحتى الـScaling يبقى أصعب.
هنا بييجي Data Partitioning.
الفكرة ببساطة إننا نقسم الـData لأجزاء أصغر، بحيث يمكن إدارتها أو تخزينها بشكل منفصل.
مثلًا، ممكن نقسم الـUsers حسب الـCountry:
Egypt → Partition 1
Saudi Arabia → Partition 2
UAE → Partition 3
أو نقسم الـOrders حسب السنة:
2024 → Partition 1
2025 → Partition 2
2026 → Partition 3
المهم إن اختيار طريقة التقسيم يكون مبني على طريقة استخدام الـData والـQueries اللي بننفذها عليها.
لأن اختيار الـPartition Key بشكل غير مناسب ممكن يؤدي إلى توزيع غير متوازن للـData والـLoad، وظهور مشاكل زي Hot Partitions.
وده ممكن يساعدنا في توزيع الـLoad، وتحسين بعض الـQueries، وإدارة الـData على نطاق أكبر.
لكن فيه نقطة مهمة:
الـData Partitioning هو مفهوم عام لتقسيم الـData إلى أجزاء أصغر.
أما Sharding اللي تكلمنا عنه قبل كده، فهو شكل من أشكال الـPartitioning، وغالبًا بيستخدم لتوزيع الـData على أكثر من Shard، وغالبًا على Nodes أو Databases مختلفة.
طيب، إحنا قسمنا الـData واتخزنت بشكل أفضل.
لكن فيه سؤال مختلف:
هل لازم الـDatabase تحتفظ فقط بالـCurrent State للـData؟
ولا ممكن نخزن كل التغييرات اللي حصلت عليها من البداية؟
———
📌 Event Sourcing
في الـSystems العادية، غالبًا بنخزن الـCurrent State.
مثلًا عندنا Account رصيده:
Balance = $500
إحنا بنخزن إن الرصيد الحالي هو $500.
لكن في Event Sourcing، بنفكر بطريقة مختلفة.
بدل ما نخزن النتيجة النهائية فقط، بنخزن كل الـEvents اللي أدت للنتيجة دي.
مثلًا:
Deposit $1000
Withdraw $300
Withdraw $200
ومن الـEvents دي نقدر نعرف إن الـCurrent Balance هو $500.
الميزة هنا إننا مش بس عارفين الحالة الحالية، لكن عندنا تاريخ كامل للتغييرات اللي حصلت.
وده مفيد جدًا في أنظمة محتاجة Audit Trail أو محتاجة نعرف إزاي الـData وصلت للحالة الحالية.
لكن طبعًا فيه Trade-offs.
تخزين كل الـEvents ممكن يخلي الـData تكبر جدًا، وكمان قراءة الـCurrent State ممكن تحتاج إعادة بناء الحالة من عدد كبير من الـEvents، لذلك الأنظمة اللي بتستخدم Event Sourcing ممكن تستخدم حلول إضافية زي Snapshots لتقليل تكلفة إعادة بناء الـState.
طيب، لحد هنا بنتكلم عن تقسيم الـData وتخزين التغييرات.
لكن إيه اللي هيحصل لو النظام نفسه بقى متوزع على أكتر من Server؟
———
📌 Distributed Systems
تخيل إن عندك Application شغال على Server واحد.
كل حاجة موجودة في مكان واحد:
Client → Server → Database
الموضوع بسيط نسبيًا.
لكن لما الـApplication يكبر، ممكن نبدأ نوزع أجزاء النظام على Servers مختلفة.
كل Service ممكن تكون شغالة على أكتر من Server، وممكن الـServers تكون موجودة في أماكن مختلفة.
هنا بقى عندنا Distributed System.
ببساطة، هو System مكوّن من أكتر من Computer أو Node، بيتعاونوا مع بعض علشان يقدّموا وظيفة واحدة للمستخدم.
وده ممكن يساعدنا في تحقيق Scalability و Availability بشكل أفضل، حسب تصميم النظام، لأننا مش بالضرورة معتمدين على Server واحد فقط.
لكن في المقابل، النظام بيبقى أصعب بكتير.
في النظام البسيط، لو Function استدعت Function تانية، أنت عارف إنها هترجعلك نتيجة.
لكن في الـDistributed System، ممكن الـRequest يتبعت لـService تانية، والـNetwork يحصل فيه مشكلة، أو الـServer يقع، أو الـResponse يتأخر.
وفوق ده كله، ممكن يكون عندك أكتر من Server وكل واحد عنده نسخة مختلفة من الـData في نفس اللحظة.
وده بيخلينا نواجه مشاكل جديدة زي:
- Consistency
- Failures
- Network Partitions
- Latency
- الـCoordination بين الـNodes
وده بالضبط اللي بيخلي Distributed Systems مجال مختلف وأصعب من مجرد تشغيل Application على أكتر من Server.
———
💡 الخلاصة
• الـData Partitioning: تقسيم الـData لأجزاء أصغر علشان نقدر نديرها ونخزنها ونوزعها بشكل أفضل.
• الـEvent Sourcing: تخزين الـEvents اللي حصلت بدل الاعتماد على الـCurrent State فقط.
• الـDistributed Systems: نظام مكوّن من Nodes متعددة بتتعاون مع بعض لتقديم وظيفة واحدة.
———
#system_design
❤7
دردشة سريعة عن الـ WebRTC ⚡️
.
.
إزاي مكالمة فيديو بين شخصين في بلدين مختلفين بتحصل في أجزاء من الثانية، بالصوت والصورة في نفس اللحظة، رغم تعقيدات الإنترنت؟
إزاي الـ browser يقدر يلتقط الصوت والفيديو، ينقلهم للطرف الآخر، ويحافظ على تجربة Real-Time بأقل قدر ممكن من الـ latency؟
هنا بييجي دور الـ WebRTC.
تقنية مكّنت تطبيقات الويب من التواصل المباشر لحظيًا بالصوت والفيديو والبيانات، وخلّت الـ browser نفسه قادر يبني تجارب Real-Time من غير الحاجة لبنية تقليدية معقدة لكل حالة استخدام.
تعال ندردش شوية عن الـ WebRTC ونتعرف على أهم المكونات والآليات اللي بتخلي الـ Real-Time Communication ممكنة...
———
الـ WebRTC (Web Real-Time Communication) هي مجموعة من المعايير والـ APIs مفتوحة المصدر بتسمح لمتصفحات الويب والتطبيقات إنها تعمل مشاركة الصوت والصورة والبيانات بشكل Real-Time، وغالبًا بشكل Peer-to-Peer، من غير ما تحتاج سيرفر وسيط لنقل الـ media والـ data في الحالات اللي يكون فيها الاتصال المباشر ممكن.
لكن في بعض الحالات، زي وجود NAT أو Firewall يمنع الاتصال المباشر، ممكن نحتاج TURN Server يعمل كـ Relay وينقل البيانات بين الطرفين.
يعني ببساطة: المتصفح بتاعك يقدر يكلم متصفح شخص تاني بشكل مباشر كأنهم في مكالمة تليفون، لكن عن طريق الإنترنت.
———
📌 إزاي الـ WebRTC بيشتغل؟
الموضوع فيه شوية تفاصيل تقنية مهمة:
1- الـ Signaling
- قبل ما يحصل أي اتصال، المتصفحين لازم يتبادلوا المعلومات المطلوبة لإنشاء الاتصال، زي الـ SDP Offer/Answer وICE Candidates.
- وده بيتم من خلال أي وسيلة اتصال زي WebSocket أو HTTP.
- الـ WebRTC نفسه مش بيحدد أو يوفر طريقة الـ Signaling، أنت اللي بتبني الـ Signaling Layer.
دور الـ Signaling ببساطة هو مساعدة الطرفين على اكتشاف بعضهم وتبادل معلومات الـ negotiation قبل إنشاء الاتصال الفعلي.
2- الـ NAT Traversal
علشان فيه راوترات وFirewalls وNAT، فالـ Peer-to-Peer connection مش دايمًا بيكون ممكن بشكل مباشر.
وهنا بييجي دور STUN وTURN:
- الـ STUN: بيساعد الـ browser في معرفة الـ public IP/port الظاهرين له من خارج شبكة الـ NAT، واكتشاف إمكانية إنشاء اتصال مباشر.
- الـ TURN: لو الاتصال المباشر فشل، بيعمل Relay للـ traffic بين الطرفين.
والـ ICE هو اللي بيجمع ويفاضل بين طرق الاتصال المختلفة ويحاول اختيار الـ candidate pair المناسب لإنشاء الاتصال.
3- الـ Media & Data Channels
الـ WebRTC بيوفر طريقتين أساسيتين للتواصل:
- الـ MediaStream: بيمثل الـ audio/video tracks اللي بيتم التقاطها وإضافتها للـ "RTCPeerConnection" علشان يتم إرسالها واستقبالها.
- الـ RTCDataChannel: لنقل أي نوع من الـ real-time data بين الطرفين، زي الشات، الـ game state، أو الملفات.
4- الـ Protocols
الـ WebRTC بيعتمد على مجموعة من البروتوكولات والآليات المهمة، منها:
- الـ SRTP: لتأمين ونقل الـ audio/video.
- الـ DTLS: لتأمين الـ transport، وبيُستخدم مع الـ Data Channels.
- الـ ICE: لاكتشاف واختيار أفضل مسار ممكن للاتصال بين الطرفين، باستخدام STUN وTURN عند الحاجة.
———
واحدة من أقوى مميزات WebRTC إنه Secure by Default:
- الـ WebRTC components بتستخدم التشفير، والـ Data Channels مؤمّنة باستخدام DTLS.
- الـ Media يتم نقله باستخدام SRTP، وبالتالي الاتصالات مش بتعتمد على إرسال الـ audio/video كـ plain text عبر الشبكة.
———
📌 أمثلة عملية بتستخدم WebRTC
- مكالمات فيديو وصوت (Zoom, Google Meet, WhatsApp, Messenger).
- الـ P2P File Sharing ونقل الملفات مباشرة بين المستخدمين.
- الـ Online Gaming لتبادل الـ game state والـ real-time data بين اللاعبين.
- الـ Screen Sharing وRemote Collaboration.
- الـ Remote Desktop Applications.
———
📌 مميزات WebRTC
✅ تواصل Real-Time بزمن استجابة منخفض، حسب جودة الشبكة وظروف الاتصال.
✅ مفتوح المصدر ومدعوم على نطاق واسع في المتصفحات الحديثة مثل Chrome وFirefox وSafari وEdge.
✅ مناسب لمجموعة كبيرة من التطبيقات اللي محتاجة Real-Time Communication، سواء Audio/Video أو Data Sharing.
———
#frontend
.
.
إزاي مكالمة فيديو بين شخصين في بلدين مختلفين بتحصل في أجزاء من الثانية، بالصوت والصورة في نفس اللحظة، رغم تعقيدات الإنترنت؟
إزاي الـ browser يقدر يلتقط الصوت والفيديو، ينقلهم للطرف الآخر، ويحافظ على تجربة Real-Time بأقل قدر ممكن من الـ latency؟
هنا بييجي دور الـ WebRTC.
تقنية مكّنت تطبيقات الويب من التواصل المباشر لحظيًا بالصوت والفيديو والبيانات، وخلّت الـ browser نفسه قادر يبني تجارب Real-Time من غير الحاجة لبنية تقليدية معقدة لكل حالة استخدام.
تعال ندردش شوية عن الـ WebRTC ونتعرف على أهم المكونات والآليات اللي بتخلي الـ Real-Time Communication ممكنة...
———
الـ WebRTC (Web Real-Time Communication) هي مجموعة من المعايير والـ APIs مفتوحة المصدر بتسمح لمتصفحات الويب والتطبيقات إنها تعمل مشاركة الصوت والصورة والبيانات بشكل Real-Time، وغالبًا بشكل Peer-to-Peer، من غير ما تحتاج سيرفر وسيط لنقل الـ media والـ data في الحالات اللي يكون فيها الاتصال المباشر ممكن.
لكن في بعض الحالات، زي وجود NAT أو Firewall يمنع الاتصال المباشر، ممكن نحتاج TURN Server يعمل كـ Relay وينقل البيانات بين الطرفين.
يعني ببساطة: المتصفح بتاعك يقدر يكلم متصفح شخص تاني بشكل مباشر كأنهم في مكالمة تليفون، لكن عن طريق الإنترنت.
———
📌 إزاي الـ WebRTC بيشتغل؟
الموضوع فيه شوية تفاصيل تقنية مهمة:
1- الـ Signaling
- قبل ما يحصل أي اتصال، المتصفحين لازم يتبادلوا المعلومات المطلوبة لإنشاء الاتصال، زي الـ SDP Offer/Answer وICE Candidates.
- وده بيتم من خلال أي وسيلة اتصال زي WebSocket أو HTTP.
- الـ WebRTC نفسه مش بيحدد أو يوفر طريقة الـ Signaling، أنت اللي بتبني الـ Signaling Layer.
دور الـ Signaling ببساطة هو مساعدة الطرفين على اكتشاف بعضهم وتبادل معلومات الـ negotiation قبل إنشاء الاتصال الفعلي.
2- الـ NAT Traversal
علشان فيه راوترات وFirewalls وNAT، فالـ Peer-to-Peer connection مش دايمًا بيكون ممكن بشكل مباشر.
وهنا بييجي دور STUN وTURN:
- الـ STUN: بيساعد الـ browser في معرفة الـ public IP/port الظاهرين له من خارج شبكة الـ NAT، واكتشاف إمكانية إنشاء اتصال مباشر.
- الـ TURN: لو الاتصال المباشر فشل، بيعمل Relay للـ traffic بين الطرفين.
والـ ICE هو اللي بيجمع ويفاضل بين طرق الاتصال المختلفة ويحاول اختيار الـ candidate pair المناسب لإنشاء الاتصال.
3- الـ Media & Data Channels
الـ WebRTC بيوفر طريقتين أساسيتين للتواصل:
- الـ MediaStream: بيمثل الـ audio/video tracks اللي بيتم التقاطها وإضافتها للـ "RTCPeerConnection" علشان يتم إرسالها واستقبالها.
- الـ RTCDataChannel: لنقل أي نوع من الـ real-time data بين الطرفين، زي الشات، الـ game state، أو الملفات.
4- الـ Protocols
الـ WebRTC بيعتمد على مجموعة من البروتوكولات والآليات المهمة، منها:
- الـ SRTP: لتأمين ونقل الـ audio/video.
- الـ DTLS: لتأمين الـ transport، وبيُستخدم مع الـ Data Channels.
- الـ ICE: لاكتشاف واختيار أفضل مسار ممكن للاتصال بين الطرفين، باستخدام STUN وTURN عند الحاجة.
———
واحدة من أقوى مميزات WebRTC إنه Secure by Default:
- الـ WebRTC components بتستخدم التشفير، والـ Data Channels مؤمّنة باستخدام DTLS.
- الـ Media يتم نقله باستخدام SRTP، وبالتالي الاتصالات مش بتعتمد على إرسال الـ audio/video كـ plain text عبر الشبكة.
———
📌 أمثلة عملية بتستخدم WebRTC
- مكالمات فيديو وصوت (Zoom, Google Meet, WhatsApp, Messenger).
- الـ P2P File Sharing ونقل الملفات مباشرة بين المستخدمين.
- الـ Online Gaming لتبادل الـ game state والـ real-time data بين اللاعبين.
- الـ Screen Sharing وRemote Collaboration.
- الـ Remote Desktop Applications.
———
📌 مميزات WebRTC
✅ تواصل Real-Time بزمن استجابة منخفض، حسب جودة الشبكة وظروف الاتصال.
✅ مفتوح المصدر ومدعوم على نطاق واسع في المتصفحات الحديثة مثل Chrome وFirefox وSafari وEdge.
✅ مناسب لمجموعة كبيرة من التطبيقات اللي محتاجة Real-Time Communication، سواء Audio/Video أو Data Sharing.
———
#frontend
❤3
دردشة سريعة عن الـ RFC 💯
.
.
لو عندك تغيير كبير في الـArchitecture، أو تحسين في الأداء، أو Refactoring، أو Feature جديدة، القرار مش بيبدأ بالتنفيذ وكتابة الكود علطول.
الموضوع بيبدأ بفهم المشكلة، مناقشة الحلول الممكنة، ومراجعة الـTrade-offs مع التيم.
وهنا بييجي دور الـRFC.
———
📌 يعني إيه RFC؟
الـRFC عبارة عن مستند مكتوب بيشرح فيه صاحب الفكرة كل حاجة عن الـFeature أو التغيير اللي عايز يعمله:
من الـContext، والـProblem اللي بيحاول يحلها، لحد الـProposed Solution، والـAlternatives، والـTrade-offs.
الهدف إنك تشارك طريقة تفكيرك مع التيم، علشان الكل يقدر يراجع الفكرة ويناقشها من وجهات نظر مختلفة قبل اتخاذ القرار.
———
📌 ليه مهم نكتب RFC؟
فيه 3 أسباب رئيسية بتخلي الـRFCs مهمة جدًا:
1- بتقلل القرارات الفردية غير المدروسة:
بدل ما يتاخد قرار تقني مهم بشكل فردي، الـRFC بتوفر مساحة منظمة لمراجعة الفكرة ومناقشة الـApproach قبل التنفيذ.
2- بتوثّق القرارات التقنية:
بعد 6 شهور لما حد يسأل:
“ليه اخترنا نستخدم Redis هنا؟”
تقدر ترجع للـRFC وتشوف الـReasoning والـTrade-offs اللي أدت للقرار، بدل ما تعتمد على الذاكرة.
3- بتحسّن التعاون بين الفرق:
الـFrontend و Backend و DevOps، وغيرهم يقدروا يفهموا التغيير المقترح، ويشاركوا بالـفيدباك قبل التنفيذ، خصوصًا لما القرار يكون له تأثير على أكتر من جزء في النظام.
———
📌 إزاي تكتب RFC محترم؟
الـStructure مش ثابت، وبيختلف من تيم للتاني، لكن فيه أقسام شائعة بتخلي الـRFC واضح ومنطقي.
📍 Title + Summary
ابدأ بعنوان بسيط وواضح يشرح هدف الـRFC.
مثلًا:
RFC: Introduce caching layer for product API
وبعدها اعمل Summary صغير بيشرح في جملة أو اتنين الفكرة العامة:
We propose adding a Redis-based caching layer to reduce response time for frequently accessed endpoints.
📍 Context / Background
احكي باختصار الـSituation الحالي وليه محتاجين التغيير.
مثلًا:
Currently, our product endpoints are hitting the database directly, leading to high latency during peak hours.
الفكرة إنك تدي القارئ صورة كاملة عن المشكلة قبل ما يدخل في الحل.
📍 Problem Statement
وضح المشكلة الأساسية اللي بتحاول تحلها، ويفضل تدعمها بالأرقام لو أمكن.
مثلًا:
Average response time increased from 300ms to 900ms under load.
ده بيخلي الـRFC مبني على Data، بدل ما يكون مجرد رأي أو افتراض.
📍 Proposed Solution
اشرح الـApproach اللي ناوي تستخدمه، ليه اخترته، وإزاي هيشتغل.
مثلًا:
We'll use Redis to cache product data for 5 minutes. The cache will be invalidated on product update events.
ممكن كمان تضيف Diagram بسيط أو Pseudo Code لو محتاج توضح Flow معين.
📍 Alternatives Considered
وضح الحلول البديلة اللي درستها وليه ما اخترتهاش.
مثلًا:
Considered using in-memory cache, but it doesn’t scale horizontally. Redis fits better for distributed systems.
ده بيوضح إن اختيار الحل كان مبني على مقارنة، مش قرار عشوائي.
📍 Trade-offs
قول بصراحة إيه المميزات اللي هتكسبها مقابل التكاليف أو التعقيدات اللي هتضيفها.
مثلًا:
Cache invalidation adds complexity and increases operational overhead.
———
📌 نصائح مهمة وأنت بتكتب RFC:
- خليك واضح وبسيط، بلاش مصطلحات تقيلة من غير داعي.
- استخدم Bullet Points علشان الناس تقرأ بسهولة.
- لو فيه Diagrams أو Code Snippets، ضيفهم علشان تسهّل الفهم.
- خليك مرن في النقاش... الهدف مش إن فكرتك تتنفذ، الهدف إن التيم يوصل لأفضل قرار ممكن.
———
مش مهم تكتب RFC مثالية من أول مرة، المهم إنك تبدأ، ومع الوقت هتتعلم إزاي توصل فكرتك بأوضح وأقوى طريقة ممكنة.
.
.
لو عندك تغيير كبير في الـArchitecture، أو تحسين في الأداء، أو Refactoring، أو Feature جديدة، القرار مش بيبدأ بالتنفيذ وكتابة الكود علطول.
الموضوع بيبدأ بفهم المشكلة، مناقشة الحلول الممكنة، ومراجعة الـTrade-offs مع التيم.
وهنا بييجي دور الـRFC.
———
📌 يعني إيه RFC؟
الـRFC عبارة عن مستند مكتوب بيشرح فيه صاحب الفكرة كل حاجة عن الـFeature أو التغيير اللي عايز يعمله:
من الـContext، والـProblem اللي بيحاول يحلها، لحد الـProposed Solution، والـAlternatives، والـTrade-offs.
الهدف إنك تشارك طريقة تفكيرك مع التيم، علشان الكل يقدر يراجع الفكرة ويناقشها من وجهات نظر مختلفة قبل اتخاذ القرار.
———
📌 ليه مهم نكتب RFC؟
فيه 3 أسباب رئيسية بتخلي الـRFCs مهمة جدًا:
1- بتقلل القرارات الفردية غير المدروسة:
بدل ما يتاخد قرار تقني مهم بشكل فردي، الـRFC بتوفر مساحة منظمة لمراجعة الفكرة ومناقشة الـApproach قبل التنفيذ.
2- بتوثّق القرارات التقنية:
بعد 6 شهور لما حد يسأل:
“ليه اخترنا نستخدم Redis هنا؟”
تقدر ترجع للـRFC وتشوف الـReasoning والـTrade-offs اللي أدت للقرار، بدل ما تعتمد على الذاكرة.
3- بتحسّن التعاون بين الفرق:
الـFrontend و Backend و DevOps، وغيرهم يقدروا يفهموا التغيير المقترح، ويشاركوا بالـفيدباك قبل التنفيذ، خصوصًا لما القرار يكون له تأثير على أكتر من جزء في النظام.
———
📌 إزاي تكتب RFC محترم؟
الـStructure مش ثابت، وبيختلف من تيم للتاني، لكن فيه أقسام شائعة بتخلي الـRFC واضح ومنطقي.
📍 Title + Summary
ابدأ بعنوان بسيط وواضح يشرح هدف الـRFC.
مثلًا:
RFC: Introduce caching layer for product API
وبعدها اعمل Summary صغير بيشرح في جملة أو اتنين الفكرة العامة:
We propose adding a Redis-based caching layer to reduce response time for frequently accessed endpoints.
📍 Context / Background
احكي باختصار الـSituation الحالي وليه محتاجين التغيير.
مثلًا:
Currently, our product endpoints are hitting the database directly, leading to high latency during peak hours.
الفكرة إنك تدي القارئ صورة كاملة عن المشكلة قبل ما يدخل في الحل.
📍 Problem Statement
وضح المشكلة الأساسية اللي بتحاول تحلها، ويفضل تدعمها بالأرقام لو أمكن.
مثلًا:
Average response time increased from 300ms to 900ms under load.
ده بيخلي الـRFC مبني على Data، بدل ما يكون مجرد رأي أو افتراض.
📍 Proposed Solution
اشرح الـApproach اللي ناوي تستخدمه، ليه اخترته، وإزاي هيشتغل.
مثلًا:
We'll use Redis to cache product data for 5 minutes. The cache will be invalidated on product update events.
ممكن كمان تضيف Diagram بسيط أو Pseudo Code لو محتاج توضح Flow معين.
📍 Alternatives Considered
وضح الحلول البديلة اللي درستها وليه ما اخترتهاش.
مثلًا:
Considered using in-memory cache, but it doesn’t scale horizontally. Redis fits better for distributed systems.
ده بيوضح إن اختيار الحل كان مبني على مقارنة، مش قرار عشوائي.
📍 Trade-offs
قول بصراحة إيه المميزات اللي هتكسبها مقابل التكاليف أو التعقيدات اللي هتضيفها.
مثلًا:
Cache invalidation adds complexity and increases operational overhead.
———
📌 نصائح مهمة وأنت بتكتب RFC:
- خليك واضح وبسيط، بلاش مصطلحات تقيلة من غير داعي.
- استخدم Bullet Points علشان الناس تقرأ بسهولة.
- لو فيه Diagrams أو Code Snippets، ضيفهم علشان تسهّل الفهم.
- خليك مرن في النقاش... الهدف مش إن فكرتك تتنفذ، الهدف إن التيم يوصل لأفضل قرار ممكن.
———
مش مهم تكتب RFC مثالية من أول مرة، المهم إنك تبدأ، ومع الوقت هتتعلم إزاي توصل فكرتك بأوضح وأقوى طريقة ممكنة.
❤4
دردشة سريعة عن أنواع السيرفرات 💯
.
.
أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور...
بس الحقيقة إن السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة.
الـ Server ببساطة هو جهاز (أو برنامج) بيستقبل Requests من أجهزة تانية اسمها Clients، وبيرد عليها بـ Responses.
زي ما الـ Browser بيبعت Request لموقع معين، والسيرفر بيرد عليه بالصفحة المطلوبة.
لكن السيرفرات مش كلها زي بعض… كل نوع له وظيفة مختلفة حسب الـ Use Case بتاعته.
———
📌 Web Server
ده من أشهر أنواع السيرفرات، وهو اللي بيستقبل HTTP Requests، وبيقدّم ملفات زي HTML, CSS, JavaScript، أو بيمرّر Requests للـ Application Server اللي ممكن يرجّع Responses بصيغة JSON للـ APIs.
أشهر الأمثلة:
- Apache
- Nginx
- Microsoft IIS
باختصار: الـ Web Server مسؤول عن استقبال طلبات HTTP والتعامل معاها، سواء بتقديم المحتوى مباشرة أو بتمرير الطلبات لخدمات تانية.
———
📌 Database Server
ده السيرفر المسؤول عن تخزين البيانات وإدارتها وإتاحتها للتطبيقات عند الحاجة.
سواء عندك Web App أو Mobile App، غالبًا هتحتاج Database تحفظ فيها البيانات وتسترجعها وقت الطلب.
أشهر الأمثلة:
- MySQL Server
- PostgreSQL
- MongoDB
- Microsoft SQL Server
الـ App بيبعت Query، والـ Database Server بينفّذها ويرجّع النتيجة حسب نوع قاعدة البيانات والعملية المطلوبة.
———
📌 File Server
دوره تخزين الملفات وتنظيمها ومشاركتها بين المستخدمين والأجهزة، مع إمكانية تحديد Access Control وPermissions علشان كل مستخدم يوصل للملفات المسموح له بيها فقط.
زي إنك ترفع صور أو ملفات PDF أو Videos وتسمح لمستخدمين معينين بالوصول ليها.
أمثلة:
- Windows File Server
- Samba
- خدمات تخزين ومشاركة الملفات زي Google Drive وDropbox، واللي بتعتمد على بنية تخزين وخدمات متعددة، مش مجرد File Server تقليدي.
———
📌 Mail Server
ده المسؤول عن إرسال واستقبال الإيميلات وتوجيهها بين أنظمة البريد الإلكتروني.
لو بعت إيميل من Gmail أو من دومين شركتك، فالعملية بتتم من خلال Mail Servers وبروتوكولات مختلفة.
أهم البروتوكولات:
- الـ SMTP: لإرسال الإيميلات ونقلها بين خوادم البريد.
- الـ IMAP: للوصول للإيميلات ومزامنتها مع السيرفر.
- الـ POP3: لاسترجاع الإيميلات من السيرفر.
أمثلة:
- Microsoft Exchange Server
- Postfix
- Exim
———
📌 Application Server
ده اللي بيشغّل الـ Business Logic الخاصة بالتطبيق، وبيعالج الطلبات وينفّذ العمليات المطلوبة، وممكن يتواصل مع Database أو خدمات خارجية.
لو عندك React Frontend وNode.js Backend، فالـ Backend ممكن يشتغل كـ Application Server، وينفّذ الـ Business Logic ويرجّع البيانات للـ Frontend.
أمثلة وتقنيات ممكن تُستخدم في بناء Application Servers:
- Node.js
- Java with Apache Tomcat
- Python with Django
- ASP.NET Core
ملحوظة: Express.js وDjango Frameworks بتساعدك تبني تطبيقات Backend، لكنها مش سيرفرات مستقلة بحد ذاتها.
———
📌 DNS Server
ده المسؤول عن التعامل مع استفسارات DNS، اللي بتساعد في تحويل أسماء الدومينات (زي google.com) إلى IP Addresses، علشان الأجهزة تقدر توصل للخدمات المطلوبة.
من أشهر الخدمات:
- Google Public DNS
- Cloudflare DNS
- OpenDNS
الخدمات دي بتعمل دور DNS Resolvers، يعني بتساعد جهازك في الوصول للـ IP المرتبط بالدومين عن طريق الاستعلام عن سجلات DNS.
وفيه كمان Authoritative DNS Servers، ودي المسؤولة عن تقديم سجلات الدومين الأصلية، زي سجلات الـ A وMX.
من غير DNS، كان هيبقى الوصول للمواقع أصعب بكتير، لأنك هتحتاج تعرف عناوين IP بدل أسماء الدومينات في الحالات اللي بتعتمد على DNS.
———
📌 Proxy Server
ده سيرفر وسيط بين الـ Client والوجهة اللي بيحاول يوصل ليها.
فيه نوعين أساسيين:
- الـ Forward Proxy: بيشتغل نيابةً عن الـ Clients، وممكن يُستخدم للتحكم في الوصول للإنترنت أو تطبيق سياسات الأمان.
- الـ Reverse Proxy: بيستقبل الطلبات نيابةً عن الـ Backend Servers، وممكن يوزّع الترافيك بينها، ويعمل Caching، وينفّذ بعض وظائف الحماية.
ومن أشهر استخداماته تحسين الأمان والأداء وإدارة حركة المرور.
———
#backend
[ بقية المنشور 👇🏻 ]
.
.
أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور...
بس الحقيقة إن السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة.
الـ Server ببساطة هو جهاز (أو برنامج) بيستقبل Requests من أجهزة تانية اسمها Clients، وبيرد عليها بـ Responses.
زي ما الـ Browser بيبعت Request لموقع معين، والسيرفر بيرد عليه بالصفحة المطلوبة.
لكن السيرفرات مش كلها زي بعض… كل نوع له وظيفة مختلفة حسب الـ Use Case بتاعته.
———
📌 Web Server
ده من أشهر أنواع السيرفرات، وهو اللي بيستقبل HTTP Requests، وبيقدّم ملفات زي HTML, CSS, JavaScript، أو بيمرّر Requests للـ Application Server اللي ممكن يرجّع Responses بصيغة JSON للـ APIs.
أشهر الأمثلة:
- Apache
- Nginx
- Microsoft IIS
باختصار: الـ Web Server مسؤول عن استقبال طلبات HTTP والتعامل معاها، سواء بتقديم المحتوى مباشرة أو بتمرير الطلبات لخدمات تانية.
———
📌 Database Server
ده السيرفر المسؤول عن تخزين البيانات وإدارتها وإتاحتها للتطبيقات عند الحاجة.
سواء عندك Web App أو Mobile App، غالبًا هتحتاج Database تحفظ فيها البيانات وتسترجعها وقت الطلب.
أشهر الأمثلة:
- MySQL Server
- PostgreSQL
- MongoDB
- Microsoft SQL Server
الـ App بيبعت Query، والـ Database Server بينفّذها ويرجّع النتيجة حسب نوع قاعدة البيانات والعملية المطلوبة.
———
📌 File Server
دوره تخزين الملفات وتنظيمها ومشاركتها بين المستخدمين والأجهزة، مع إمكانية تحديد Access Control وPermissions علشان كل مستخدم يوصل للملفات المسموح له بيها فقط.
زي إنك ترفع صور أو ملفات PDF أو Videos وتسمح لمستخدمين معينين بالوصول ليها.
أمثلة:
- Windows File Server
- Samba
- خدمات تخزين ومشاركة الملفات زي Google Drive وDropbox، واللي بتعتمد على بنية تخزين وخدمات متعددة، مش مجرد File Server تقليدي.
———
📌 Mail Server
ده المسؤول عن إرسال واستقبال الإيميلات وتوجيهها بين أنظمة البريد الإلكتروني.
لو بعت إيميل من Gmail أو من دومين شركتك، فالعملية بتتم من خلال Mail Servers وبروتوكولات مختلفة.
أهم البروتوكولات:
- الـ SMTP: لإرسال الإيميلات ونقلها بين خوادم البريد.
- الـ IMAP: للوصول للإيميلات ومزامنتها مع السيرفر.
- الـ POP3: لاسترجاع الإيميلات من السيرفر.
أمثلة:
- Microsoft Exchange Server
- Postfix
- Exim
———
📌 Application Server
ده اللي بيشغّل الـ Business Logic الخاصة بالتطبيق، وبيعالج الطلبات وينفّذ العمليات المطلوبة، وممكن يتواصل مع Database أو خدمات خارجية.
لو عندك React Frontend وNode.js Backend، فالـ Backend ممكن يشتغل كـ Application Server، وينفّذ الـ Business Logic ويرجّع البيانات للـ Frontend.
أمثلة وتقنيات ممكن تُستخدم في بناء Application Servers:
- Node.js
- Java with Apache Tomcat
- Python with Django
- ASP.NET Core
ملحوظة: Express.js وDjango Frameworks بتساعدك تبني تطبيقات Backend، لكنها مش سيرفرات مستقلة بحد ذاتها.
———
📌 DNS Server
ده المسؤول عن التعامل مع استفسارات DNS، اللي بتساعد في تحويل أسماء الدومينات (زي google.com) إلى IP Addresses، علشان الأجهزة تقدر توصل للخدمات المطلوبة.
من أشهر الخدمات:
- Google Public DNS
- Cloudflare DNS
- OpenDNS
الخدمات دي بتعمل دور DNS Resolvers، يعني بتساعد جهازك في الوصول للـ IP المرتبط بالدومين عن طريق الاستعلام عن سجلات DNS.
وفيه كمان Authoritative DNS Servers، ودي المسؤولة عن تقديم سجلات الدومين الأصلية، زي سجلات الـ A وMX.
من غير DNS، كان هيبقى الوصول للمواقع أصعب بكتير، لأنك هتحتاج تعرف عناوين IP بدل أسماء الدومينات في الحالات اللي بتعتمد على DNS.
———
📌 Proxy Server
ده سيرفر وسيط بين الـ Client والوجهة اللي بيحاول يوصل ليها.
فيه نوعين أساسيين:
- الـ Forward Proxy: بيشتغل نيابةً عن الـ Clients، وممكن يُستخدم للتحكم في الوصول للإنترنت أو تطبيق سياسات الأمان.
- الـ Reverse Proxy: بيستقبل الطلبات نيابةً عن الـ Backend Servers، وممكن يوزّع الترافيك بينها، ويعمل Caching، وينفّذ بعض وظائف الحماية.
ومن أشهر استخداماته تحسين الأمان والأداء وإدارة حركة المرور.
———
#backend
[ بقية المنشور 👇🏻 ]
❤2💯1
DevGuide
دردشة سريعة عن أنواع السيرفرات 💯 . . أغلبنا أول ما بيسمع كلمة Server بييجي في باله جهاز كبير في غرفة مكيفة، شغال 24 ساعة ومليان لمبات بتنور... بس الحقيقة إن السيرفر مش لازم يكون جهاز ضخم… ممكن يكون مجرد Software أو Virtual Machine بيقدّم خدمة معينة. الـ…
📌 FTP Server
ده سيرفر بيدعم بروتوكول FTP (File Transfer Protocol)، اللي بيُستخدم لنقل الملفات بين الأجهزة والسيرفرات.
ممكن تستخدمه لرفع أو تحميل ملفات، ولسه موجود في بعض الأنظمة والشركات، رغم إن بروتوكولات أحدث وأكثر أمانًا بقت شائعة.
أمثلة:
- vsftpd
- FileZilla Server
ملحوظة: FTP التقليدي مش بيشفّر البيانات، بما فيها بيانات تسجيل الدخول، علشان كده SFTP أو FTPS بيكونوا أنسب لما تحتاج نقل ملفات بشكل آمن.
———
📌 Virtual Servers & Cloud Servers
بدل ما تشتري أجهزة فعلية وتديرها بنفسك، تقدر تستخدم Virtual Machines أو تستأجر موارد حوسبة من Cloud Providers زي:
- AWS
- Microsoft Azure
- Google Cloud
الـ Virtual Server بيكون بيئة افتراضية بتشتغل على موارد جهاز فعلي، أما الـ Cloud Server فهو سيرفر متاح من خلال منصة سحابية، وغالبًا بيكون مبني على تقنيات الـ Virtualization.
الميزة إنك تقدر تزود أو تقلل الموارد حسب احتياجك، وفي بعض الأنظمة تقدر تفعّل Auto Scaling علشان الموارد تزيد أو تقل تلقائيًا حسب الترافيك.
لكن الـ Scaling مش دايمًا تلقائي أو سهل؛ ده بيعتمد على تصميم التطبيق وإعدادات البنية التحتية والتكلفة.
والأهم إن الأنواع دي مش بديلة للأنواع اللي فوق؛ لأن السيرفر السحابي نفسه ممكن يكون Web Server أو Database Server أو Application Server أو غيره.
———
#backend
ده سيرفر بيدعم بروتوكول FTP (File Transfer Protocol)، اللي بيُستخدم لنقل الملفات بين الأجهزة والسيرفرات.
ممكن تستخدمه لرفع أو تحميل ملفات، ولسه موجود في بعض الأنظمة والشركات، رغم إن بروتوكولات أحدث وأكثر أمانًا بقت شائعة.
أمثلة:
- vsftpd
- FileZilla Server
ملحوظة: FTP التقليدي مش بيشفّر البيانات، بما فيها بيانات تسجيل الدخول، علشان كده SFTP أو FTPS بيكونوا أنسب لما تحتاج نقل ملفات بشكل آمن.
———
📌 Virtual Servers & Cloud Servers
بدل ما تشتري أجهزة فعلية وتديرها بنفسك، تقدر تستخدم Virtual Machines أو تستأجر موارد حوسبة من Cloud Providers زي:
- AWS
- Microsoft Azure
- Google Cloud
الـ Virtual Server بيكون بيئة افتراضية بتشتغل على موارد جهاز فعلي، أما الـ Cloud Server فهو سيرفر متاح من خلال منصة سحابية، وغالبًا بيكون مبني على تقنيات الـ Virtualization.
الميزة إنك تقدر تزود أو تقلل الموارد حسب احتياجك، وفي بعض الأنظمة تقدر تفعّل Auto Scaling علشان الموارد تزيد أو تقل تلقائيًا حسب الترافيك.
لكن الـ Scaling مش دايمًا تلقائي أو سهل؛ ده بيعتمد على تصميم التطبيق وإعدادات البنية التحتية والتكلفة.
والأهم إن الأنواع دي مش بديلة للأنواع اللي فوق؛ لأن السيرفر السحابي نفسه ممكن يكون Web Server أو Database Server أو Application Server أو غيره.
———
#backend
❤2