دورة تطور السيرفرات

اليوم حنحكي عن قصة تطور رهيبة في عالم البرمجة، قصة السيرفرات وكيف رحنا من فكرة RPC (Remote Procedure Call) إلى API (Application Programming Interface). لو كنت مبرمج أو مجرد فضولي، الموضوع رح يبهرك، لأنه مليان أسرار وفهم عميق عن كيف الأنظمة تتواصل مع بعضها البعض! البداية بRPC , شو يعني RPC؟ تخيل إنك عندك برنامجين، واحد قاعد على جهازك وواحد ثاني قاعد على سيرفر بعيد. لو بدك تخليهم "يحكوا مع بعض"، كيف رح تسويها؟ هون إجت فكرة Remote Procedure Call (RPC)، واللي فكرتها كالتالي: بدك تتخيل كأنه البرنامج اللي على جهازك بيطلب function من البرنامج اللي على السيرفر. بيكون في الكود عندك حاجة اسمها stub هاد الزلمة بيروح بيحول طلبك للغة وسيطة زي xml او json عشان يقدر يتواصل مع السيرفر وهادي العملية اسمها marshaling طبعا هذا الطلب يروح عبر الشبكة وبيصل السبرفر وعنا في السيرفر في عنا زلمة بيستقبلو اسمها اسمو skeleton هاد زي مندوب عن الفنكشن هناك وبيروح بعمل unmarchling وبيروح بينفذ الفنكشن وبعدين لما يرجعلك النتيجة وبتصير عنا عمليات ال marching و unmarchling بالعكس. وين المشكلة؟ عنا اعتماد مباشر جدا لازم البرنامجين يعرفوا كل شيء عن بعض، حتى أسماء الدوال وباراميتراتها وكمان عنا Coupling إذا تغير شيء بسيط في السيرفر (مثلاً اسم الفنكشن) الكود عندك حيتكسر، غير هيك لو كان جهازك يستخدم لغة برمجة مختلفة عن السيرفر، الموضوع صار معقد. وين طوّرنا بعدين؟ لما صار واضح إن RPC فيها مشاكل كبيرة، المبرمجين فكروا في حلول أفضل، وهنا دخلنا لعصر جديد: ال SOAP الهيكل الصلب! في أوائل الـ2000، ظهرت فكرة SOAP (Simple Object Access Protocol). تخيل إن RPC صارت "أذكى شوي"، بحيث: بدل ما تقول "استدعيلي فنكشن"، صار الطلب عبارة عن رسالة (Message) مكتوبة بلغة XML. السيرفر يستقبل الرسالة، يقرأها، ينفذ الطلب، ويرجعلك الرد كمان برسالة XML. هان حلينا شوية من المشاكل زي صار في توحيد للمعايير: XML لغة مفهومة عند الجميع وصار أسهل نتعامل مع سيرفرات مكتوبة بلغات برمجة مختلفة. المشكلة؟ الرسائل كانت ضخمة جدًا (XML ثقيل!)وغير هيك التعامل مع SOAP كان معقد. ال REST API البساطة دايما بتفوز ! بما انو xml تقبل بدنا حاجة اخف وابسط هنا ولد REST API (Representational State Transfer)، واللي عمل نقلة نوعية: كل شيء صار عبارة عن Resources كيف يعني؟ تخيل إن عندك موقع بيع كتب. كل كتاب هو مورد، وكل مورد له رابط URL. لو بدك تجيب بيانات كتاب معين: GET /books/1 لو بدك تضيف كتاب جديد: POST /books مع البيانات في الطلب. لو بدك تحدث كتاب: PUT /books/1 لو بدك تحذفه: DELETE /books/1 ال REST استغل بروتوكول HTTP اللي كلنا بنستخدمه في التصفح، وعمل منه أساس للتواصل بين الأنظمة. ليش REST فجر الدنيا؟ بسيط، خفيف، ويفهمه كل المبرمجين، الروابط (URLs) واضحة ومفهومة، مرن أي لغة برمجة ممكن تتعامل معه بسهولة. ال JSON هوا الوريث الخفيف للـ XML ال XML كان ثقيل ومعقد فكروا في صيغة أخف، وهنا ظهر JSON (JavaScript Object Notation). صارت البيانات المكتوبة في الرسائل أخف وأسهل للقراءة، حتى انهم طوروا منه GraphQL اللي صار تقدر تعمل query على JSON. هلقيت ال xml بياخد بيانات اكتر تعقيد من json بس json اسرع بس لل 2 بيوفروش ال Streaming فال 2 بيبعتو text ف جوجل تسكت؟ راحت طورت grc لحاجة اسمها grpc وصارت تستخدم فيه Protocol Buffers وهاد تقريبا نفس مفهوم ال rpc بس بدل ما stub بيحول الداتا ل xml او json فخلوها تتحول ل protobuf واللي هيا عبارة عن binary data وطبعا بيدعم الـ Streaming (إرسال واستقبال البيانات في نفس الوقت) وغير هيك بيوفر ضغط بيانات عالي، وهذا يحسن الأداء خاصة إذا كنت تنقل كميات ضخمة من البيانات لانو بستخدم بروتوكول HTTP/2 فبتوفر انواع كتير من الكونكشنز الUnary: طلب واحد واستجابة واحدة (زي REST). الServer Streaming: السيرفر يرسل بيانات بشكل متدفق (stream) للعميل. والClient Streaming: العميل يرسل بيانات متدفقة للسيرفر. والBidirectional Streaming: العميل والسيرفر يتبادلون البيانات بشكل متزامن (مثالي للألعاب أو الأنظمة الفورية مثل الدردشة). طيب كيف بشتغل؟؟ فكرته انو بتكتب انت ال service اللي بدك اياها وبتحدد ال api في ملف .proto وبعد هيك هيا بتولدلك الكود الخاص ب الكلينت والسيرفر فانت بتضطرش تعمل كودين وبعدها بتقدر تعمل call ويرجعلك النتيجة. هيا م منتشرة زي json لسبب انها معقدة في تجهز اعداداتها وغير هيك بتستخدم HTTP/2 ومش كل السيرفرات بدعموه. هيا مستخدمة اكتر اشي في الالعاب عشان بتوفر ال real time وكمان بتلاقيه في distribution systems وبانظمة المحاسبة الكبيرة . بصراحة انا متحمس اشوف حد اشتغل بهاد النوع صراحة اعرف كيف تجربته ؟؟ فالرحلة من RPC إلى API ل gRPC؟ 1. الRPC: بداية التواصل، لكن بسيط ومعتمد جدًا. 2. الSOAP: حل أولي للمعايير، لكنه ثقيل ومعقد. 3. الREST: نقلة نوعية للبساطة والمرونة باستخدام HTTP. 4. ال gRPC: الوريث الحصري من جوجل ل rpc باستخدام protobuf و HTTP/2 التطور في البرمجة دايما بيروح باتجاه البساطة، المرونة، وقابلية التوسع، لكن هاد كلو تحت مظلة مفهوم trade off، كيف يعني؟ صحيح كانت ال xml معقدة بس كنت بتقدر تبتعت فيها حاجات اكبر واكتر تعقيد من json وكمان ال json صحيح انها ابسط بس مكنتش قادر تبعت حاجة ضخمة وبتقدرش اصلا تبعت obj ويتعامل معاه ك obj كنت لازم تعمل عملية formating ل model معين لكن في porto مكانش بيلزم نعمل modeling بس معقد جدا بالتعامل فأنت حسب طبيعة المشروع هيا اللي بتحكمك. بصراحة نفسي اعرف ازا حد تعامل مع rpc او grpc قبل هيك؟ مرة سمعت انو تطبيق شركة جوال مبني على rpc بس بعرفش ازا صح ولا لاء!!

فكرك التطوير الجاي وين حيكون؟؟