JSON مقابل Protobuf لواجهات الموبايل: الحجم، التوافق، والتصحيح

لماذا تهم صيغة API لتطبيقات الموبايل

يمكن أن يبدو التطبيق البعيد بطيئًا حتى لو كان الخادم سريعًا. السبب المعتاد ليس وقت الخادم، بل كل ما يحيط به: كمون الشبكة الخلوية، الإشارة الضعيفة، إعادة المحاولة، ووقت استيقاظ راديو الشبكة في الهاتف. إذا كانت شاشة واحدة تطلق ثلاث مكالمات API، فستدفع ثمن رحلة العودة ثلاث مرات.

الصيغة تؤثر أيضًا فيما يحدث بعد وصول البايتات. التطبيق لا يزال يحتاج إلى تحليل الاستجابة، التحقق منها، وتحويلها إلى نماذج واجهة المستخدم. هذا العمل يستهلك CPU، وما يعنيه ذلك هو استهلاك بطارية. على الهواتف القديمة أو عندما يعمل التطبيق في الخلفية، تتكدس الكفاءات الصغيرة.

حجم الحمولة هو ببساطة عدد البايتات التي ترسلها عبر الشبكة في الطلب والاستجابة، بما في ذلك أسماء الحقول والرموز الهيكلية. الحزم الأصغر عادةً تعني تنزيلًا أسرع على الشبكات الضعيفة واستخدام بيانات أقل على الباقات المحدودة. يمكنها أيضًا تقليل استهلاك البطارية لأن الراديو يبقى نشطًا لفترة أقل والـ CPU يقوم بعمل أقل في التحليل.

اختيار الصيغة يغيّر أيضًا مدى أمان تطور API. إصدارات الموبايل تتقدم أبطأ من الويب: المستخدمون يتأخرون في التحديث، بعضهم لا يحدث أبدًا، ومراجعات المتاجر قد تؤخر الإصلاحات. إذا طرحت تغييرًا يكسر العملاء الأقدم، قد ينتهي بك الأمر بدعم إصدارات متعددة تحت ضغط.

التصحيح مهم كذلك. مع JSON، غالبًا يمكنك قراءة الحمولة في السجلات والعثور على المشكلة بسرعة. مع الصيغ الثنائية مثل Protobuf، عادة تحتاج المخطط والأدوات المناسبة لفكّ ما حدث.

عمليًا، يؤثر هذا القرار على زمن تحميل كل شاشة على الشبكات السيئة، استخدام البيانات والبطارية، مدى أمان إضافة حقول دون كسر التطبيقات القديمة، وسرعة فحص الأعطال.

JSON و Protobuf بلغة بسيطة

JSON و Protobuf هما طريقتان لحزم نفس المعلومات حتى يتفق التطبيق والخادم على معنى الرسالة. فكّر فيها كإرسال ملاحظة مكتوبة (JSON) أو رمز شريطي مضغوط (Protobuf).

في JSON، تُرسل البيانات كنص مع أسماء الحقول مرفقة في كل مرة. كائن مستخدم بسيط قد يبدو هكذا: {"id": 7, "name": "Sam"}. هو قابل للقراءة كما هو، ما يجعل فحصه في السجلات أو نسخه في تقرير خطأ أو اختباره بأدوات بسيطة سهلاً.

في Protobuf، تُرسل البيانات كبايتات ثنائية. بدل تكرار أسماء الحقول مثل "id" و"name" على السلك، يتفق الطرفان مسبقًا أن الحقل 1 يعني id والحقل 2 يعني name. الرسالة تصبح أصغر لأنها تتكوّن في الغالب من القيم بالإضافة إلى وسوم رقمية قصيرة.

نص مقابل ثنائي، بدون نظرية

المقايضة العملية بسيطة:

• JSON ذاتية الوصف: الرسالة تحمل أسماء الحقول.
• Protobuf مدفوعة بالمخطط: المعنى يأتي من ملف تعريف مشترك.
• JSON سهل القراءة والتعديل اليدوي.
• Protobuf مضغوط ومتسق، لكنه غير قابل للقراءة بدون أدوات.

هذا المخطط المشترك هو العقد. مع Protobuf، تميل الفرق إلى التعامل مع المخطط كعقدة يتم إصدارها وإبقاؤها متزامنة بين الخادم والعميل. مع JSON، المخطط اختياري في الغالب. العديد من الفرق توثق واحدًا (مثل OpenAPI)، لكن API قد تُطرح تقنيًا بدون مخطط.

في العمل اليومي، يغيّر ذلك التعاون. Protobuf يدفعك نحو تغييرات رسمية في واجهة البرمجة (إضافة حقل، حجز أرقام الحقول القديمة، تجنب إعادة التسمية المكسورة). JSON يسمح بتغييرات أرخض في بعض الأحيان، لكن هذه المرونة قد تخلق مفاجآت إذا افترض العملاء أن الحقول موجودة دائمًا أو من نفس النوع دائمًا.

في العالم الواقعي، JSON شائع في REST العامة والتكاملات السريعة. Protobuf شائع في خدمات gRPC، حركة الخدمة إلى الخدمة الداخلية، وتطبيقات الموبايل الحساسة للأداء حيث تكون النطاق الترددي والكمون مهمين.

حجم الحمولة: ماذا يتغير فعلاً على السلك

الحجم الخام مهم، لكن التفاصيل أهم: أي بايتات تتكرر، أيها يُضغط جيدًا، وعدد مرات الإرسال.

لماذا JSON عادةً أكبر

JSON يحمل الكثير من النص المقروء. التكلفة الأكبر غالبًا هي الكلمات حول قيمك:

• أسماء الحقول تتكرر على كل كائن ("firstName", "createdAt", "status").
• الأرقام تُرسل كنص، لذا "123456" تستخدم مزيدًا من البايتات مقارنةً بعدد ثنائي مضغوط.
• التعشيق العميق يضيف أقواس، فاصلات، وعلامات اقتباس.
• الاستجابات المصقولة (pretty-printed) تضيف فراغات لا تفيد العميل.

إذا كانت الـ API تعيد قائمة من 200 عنصر وكل عنصر يكرر 10 أسماء حقول، تلك الأسماء المتكررة قد تهيمن على الحمولة.

لماذا Protobuf عادةً أصغر

Protobuf يستبدل أسماء الحقول بوسوم رقمية ويستخدم ترميزًا ثنائيًا مضغوطًا. الترميز المعبأ يمكنه تخزين الأعداد المتكررة بكفاءة (مثل العديد من المعرفات). وبما أن تنسيق السلك معرف نوعيًا، فالأعداد والقيم البوليانية عادةً تُشفر في بايتات أقل من نسخها النصية في JSON.

نموذج عقلي مفيد: JSON يدفع ضريبة لكل حقل (اسم المفتاح). Protobuf يدفع ضريبة أصغر لكل حقل (وسم).

الضغط يغيّر المقارنة

مع gzip أو brotli، غالبًا ما يتقلص JSON كثيرًا لأنه يحتوي سلاسل متكررة، وأسماء الحقول المتكررة تضغط جيدًا جدًا. Protobuf يضغط أيضًا، لكنه قد يملك تكرارات أقل الوضوح، فما تتحصل عليه من الفرق قد يكون أصغر.

عمليًا، Protobuf ما يزال غالبًا يفوز من حيث الحجم، لكن الفارق يتضاءل عادةً بعد تفعيل الضغط.

متى يهم الحجم أكثر

حجم الحمولة يهم عندما تكون الطلبات متكررة أو الشبكات غير مستقرة. تطبيق يردد التحديث كل 10 ثوانٍ أثناء التجوال قد يستهلك بيانات بسرعة، حتى لو كانت كل استجابة أكبر بقليل. كما أنه يهم للشاشات الشاتية (اقتراحات البحث، لوحات معلومات حية) وللمستخدمين على اتصال منخفض النطاق.

إذا كنت تنادي نقطة نهاية مرات قليلة فقط في كل جلسة، فإن الوفورات حقيقية لكنها نادرًا ما تكون دراماتيكية. إذا كانت تُنادى مئات المرات فالتغييرات الصغيرة تصبح ملحوظة بسرعة.

السرعة والبطارية: التحليل، المعالج والقيود الواقعية

على الموبايل، الشبكة هي نصف القصة فقط. كل استجابة يجب أن تُفكّك، تتحول إلى كائنات، وغالبًا تُكتب إلى قاعدة بيانات محلية. ذلك يكلف CPU، ووقت CPU يكلف البطارية.

JSON هو نص. تحليله يعني مسح سلاسل، التعامل مع الفراغات، تحويل الأرقام، ومطابقة أسماء الحقول. Protobuf ثنائي؛ فهو يتخطى معظم ذلك ويصل أسرع إلى القيم التي يحتاجها تطبيقك. في العديد من التطبيقات، هذا يعني CPU أقل لكل استجابة، خصوصًا مع الحمولات المتداخلة أو القوائم المليئة بأسماء حقول متكررة.

ماذا يعني "أسرع" على الهواتف

تحس بتكلفة التحليل أكثر أثناء التشغيل البارد وعلى الأجهزة منخفضة المواصفات. إذا فتح التطبيق وحمّل فورًا خلاصة كبيرة، فقد يظهر تأخير في التفاعل الأول أو شاشة فارغة أطول نتيجة لفكّ الاستجابات ببطء.

لا تفترض أن Protobuf يحل الأداء تلقائيًا. إذا كانت الاستجابات صغيرة، أو عنق الزجاجة هو الصور، أو مصافحة TLS، أو كتابة قاعدة البيانات، أو عرض الواجهة، فقد لا تغيّر الصيغة الكثير.

سعة الخادم مهمة أيضًا

الترميز وفك الترميز يحدثان أيضًا على الخادم. Protobuf يمكن أن يقلل CPU لكل طلب ويحسّن الإنتاجية، مما يساعد عندما يستمر الكثير من العملاء في المزامنة أو الاستقصاء. لكن إذا كان وقت الخادم تهيمن عليه استعلامات قاعدة البيانات أو منطق العمل، قد يكون الفرق ضئيلًا.

لقياس منصف، احتفظ بالاختبارات متحكمًا بها: استخدم نفس نموذج البيانات وعدد السجلات، طابق إعدادات الضغط (أو تعطيل الضغط لكليهما)، اختبر على شبكات موبايل واقعية (ليس فقط واي فاي سريع)، وقِس الزمن الشامل بالإضافة إلى CPU المستخدم في فكّ الاستجابات (ليس فقط زمن التنزيل). ضمّن جهازًا منخفض المواصفات واحدًا على الأقل.

قاعدة بسيطة: الصيغ الثنائية تؤتي ثمارها عندما ترسل الكثير من البيانات المهيكلة بشكل متكرر، ويمكنك إظهار أن وقت التحليل جزء ذو معنى من الكمون أو استهلاك البطارية.

التوافق الخلفي: كيف تطوّر API بأمان

التوافق الخلفي يعني أن إصدار التطبيق القديم يستمر بالعمل بعد نشر خادم جديد. على الموبايل هذا يهم أكثر من الويب لأن المستخدمين لا يحدثون فورًا. قد يكون لديك ثلاث أو أربع نسخ من التطبيق في العالم في نفس الوقت.

قاعدة عملية هي جعل تغييرات الخادم إضافية. الخادم يجب أن يقبل الطلبات القديمة ويرجع استجابات يفهمها العملاء القدامى.

مع JSON، التغيير الإضافي غالبًا يعني إضافة حقول اختيارية جديدة. العملاء القدامى يتجاهلون الحقول التي لا يستخدمونها، لذا هذا آمن في الغالب. الفخاخ الشائعة ليست حول JSON نفسه، بل حول الافتراضات المكسورة: تغيير نوع الحقل (نص إلى رقم)، إعادة تسمية حقل، تغيير المعنى دون تغيير الاسم، أو تحويل قيمة ثابتة إلى قيمة مفتوحة.

مع Protobuf، التوافق أكثر صرامة وأكثر موثوقية إذا اتبعت القواعد. أرقام الحقول هي العقدة، وليست أسماء الحقول. إذا أزلت حقلًا، لا تعيد استخدام رقمه. احجزه حتى لا يُعاد استخدامه لاحقًا. أيضًا تجنّب تغيير أنواع الحقول أو التبديل بين الحقول المتكررة وغير المتكررة لأن العملاء القدامى قد ينكسرون.

التغييرات الآمنة في كلتا الصيغتين تبدو كالتالي:

• أضف حقول اختيارية جديدة مع قيم افتراضية معقولة.
• أضف قيم enum واجعل العملاء يتعاملون مع القيم المجهولة.
• حافظ على ثبات الحقول الموجودة في النوع والمعنى.
• قم بإهمال الحقول أولًا، ثم أزلها بعد زوال العملاء القدامى.

هناك أسلوبان شائعان للنسخ: التطور الإضافي يحافظ على نقطة نهاية واحدة ويكبر المخطط مع الزمن، وهو مناسب عادةً للموبايل. نقاط النهاية المرقمة (v1، v2) مفيدة عند الحاجة تغييرات كاسرة، لكنها تضاعف عبء الاختبار والدعم.

مثال: يعرض تطبيقك قائمة طلبات. إذا أردت إضافة ETA للتوصيل، أضف delivery_eta كحقل اختياري. لا تُعيد استخدام status ليشمل الطوابع الزمنية. إذا احتجت نموذجًا جديدًا، فكّر في استجابة v2 بينما تستمر في تقديم v1 حتى تقل نسبة التطبيقات القديمة.

التصحيح والمراقبة: رؤية سبب الخطأ

عند حدوث عطل على اتصال موبايل، عادة لديك ثلاثة دلائل: خطأ العميل، سطر سجل الخادم، وتتبع الطلب. الصيغة تؤثر على سرعة تحويل تلك الأدلة إلى إجابة.

JSON أسهل للفحص لأنه قابل للقراءة البشرية. يمكنك نسخ جسم JSON من سجل أو اعتراض وكشفه مباشرة. هذا مهم عند التصحيح خلال إصدار، أو عندما يحتاج زميل غير خادم لتأكيد ما أرسله التطبيق.

Protobuf يمكن أن يكون قابلًا للتصحيح بنفس القدر، لكن فقط إذا خططت له. الحمولة ثنائية، لذا تحتاج إلى المخطط وخطوة فكّ لتُرى الحقول. العديد من الفرق تتعامل مع هذا بتسجيل ملخص مفكك وآمن للحقول الأساسية (ليس البايت الخام) إلى جانب بيانات الطلب.

جعل Protobuf قابلاً للتصحيح عمليًا

بعض العادات المفيدة:

• سجّل ملخصات مفككة (مثال: user_id، request_type، item_count)، لا الرسالة كاملة.
• احتفظ بملفات .proto مُرجعة عبر الإصدارات ومتاحة لمن يتعامل مع الحوادث.
• أدرج معرف الطلب ومعرف التتبع في كل استجابة وسطر سجل.
• استخدم أسماء enum واضحة وتجنّب إعادة استخدام الحقول لمعانٍ متعددة.
• تحقق من قواعد العمل مبكرًا وأرجع رموز خطأ قابلة للقراءة.

المراقبة تتعلق أيضًا بالتتبع دون كشف بيانات خاصة. مع أي صيغة، قرّر مبكرًا ما الآمن تسجيله، وما يجب حجبُه، وما لا يجب أن يغادر الجهاز. بيانات PII الشائعة مثل الإيميلات، أرقام الهواتف، الموقع الدقيق، وتفاصيل الدفع يجب تنقيحها قبل تخزين السجلات.

سيناريو بسيط: الدعم يبلغ أن المستخدم لا يمكنه إرسال نموذج على بيانات متقطعة. مع JSON قد ترى فورًا حقل "country" مفقودًا في الطلب الملتقط. مع Protobuf يمكنك التوصل لنفس النتيجة إذا كانت السجلات تُظهر لقطة مفككة مثل "country: unset" مع إصدار المخطط.

كيف تختار: عملية اتخاذ قرار خطوة بخطوة

الاختيار بين JSON و Protobuf نادرًا ما يكون قرارًا على مستوى الشركة دفعة واحدة. تحرز الفرق تقدمًا أفضل بقرار لكل مجال ميزة بناءً على الاستخدام الحقيقي.

عملية بسيطة من 5 خطوات

ابدأ بتجميع نقاط النهاية بطريقة يمكنك قياسها. حدّد المكالمات التي تحدث عند كل تحميل شاشة وتلك النادرة أو التي تعمل في الخلفية. قس ما ترسله اليوم (الحجم المتوسط وp95، وتكرار المكالمات لكل مستخدم نشط). ثم ضع في الحسبان واقع العميل: هواتف منخفضة المواصفات، شبكات متقطعة، سلوك عدم الاتصال، ومدى سرعة تحديث المستخدمين.

من هناك اختر لكل مجموعة: احتفظ بـ JSON حيث تهم قابلية القراءة اليدوية والتصحيح السريع، واستخدم Protobuf حيث يكون الحجم وسرعة التحليل مُثبتين كمقيدات. أخيرًا شغّل تجربة صغيرة: حول منطقة عالية الحركة، وزعها لشريحة محدودة، وقارن النتائج قبل تعميمها.

بعد القياس، النمط عادة واضح: عدد قليل من نقاط النهاية يدفع معظم استخدام البيانات ووقت الانتظار. تلك أفضل المرشحين للصيغ الثنائية.

ما الذي تبحث عنه في تجربتك التجريبية

عرّف النجاح قبل البناء. المقاييس المفيدة تشمل زمن الوسيط وp95، بايتات المنقولة لكل جلسة، الجلسات الخالية من الانهيارات، ووقت CPU المستغرق في فكّ الاستجابات (خاصة على الأجهزة القديمة).

إذا كان لديك نقطة نهاية خلاصة تُنادى 30 مرة يوميًا وتعيد قوائم كبيرة مع حقول متكررة، يستطيع Protobuf أن يؤتي ثماره. إذا كانت أكبر مشكلتك "لا نستطيع معرفة سبب الخطأ" أثناء الدعم، فالحفاظ على JSON لتلك المنطقة قد يوفر وقتًا أكثر مما يكلفه.

أخطاء شائعة ترتكبها الفرق

غالبًا ما تتجادل الفرق حول الصيغ قبل أن تمتلك أرقامًا. هذا قد يؤدي إلى تبديل يضيف عملًا لكن نادرًا ما يغير الكمون أو استهلاك البطارية أو تكلفة البيانات بشكل ملموس.

نمط شائع هو استبدال JSON بـ Protobuf لأن "الثنائي أصغر"، ثم يكتشف الفريق أن المشكلة الحقيقية كانت صورًا كبيرة، نقاط نهاية مرهقة، أو تخزين مؤقت ضعيف. قِس أولًا على أجهزة حقيقية وشبكات حقيقية، لا فقط واي فاي المكتب السريع.

أخطاء تظهر كثيرًا تشمل: التغيير في الصيغة دون خط أساس، كسر العملاء أثناء تعديلات مخطط "صغيرة" (إعادة التسمية، تغيّر النوع، أو إعادة استخدام معرف حقل في Protobuf)، استخدام الثنائي في كل مكان حتى حيث لا يهم، وتجاهل تجربة المطور عند تصحيح الإنتاج. مشكلة متكررة أخرى هي إعداد الضغط والتخزين المؤقت بشكل خاطئ ثم لوم صيغة التسلسل.

هذا كيف يبدو في الواقع: فريق ينقل نقطة نهاية الخلاصة إلى Protobuf ويحتفل بتقليل 30% في الحمولة في البيئة التجريبية. في الإنتاج، التطبيق لا يزال بطيئًا لأن الخلاصة تطلب خمس طلبات منفصلة، لا توجد أي واحدة مخزنة مؤقتًا، والخادم يضيف حقولًا إضافية "للاحتياط". الصيغة لم تكن المشكلة الرئيسية.

سيناريو توضيحي: تطبيق موبايل بتحديثات متكررة

تخيّل تطبيقًا به ميزة شبيهة بالدردشة: يرى المستخدمون قائمة محادثات، مؤشرات الكتابة، إيصالات التسليم، وتحديثات الملف الشخصي العرضية. الرسائل تصل كتحديثات صغيرة ومتكررة، والعديد من المستخدمين على شبكات متقطعة حيث يكون إعادة الاتصال شائعًا.

استجابة JSON نموذجية لـ "جلب آخر التحديثات" تبدأ صغيرة، ثم تكبر مع الزمن. في البداية قد تعيد نص الرسالة، المرسل، والطابع الزمني. بعد بعض الإصدارات قد تضيف ردود فعل، حالات القراءة لكل جهاز، علامات الاعتدال، وكائنات مستخدم أغنى. JSON يسهل طرح ذلك، لكن الحمولة قد تنتفخ لأن أسماء الحقول تتكرر على كل عنصر والفرق يضيف كتل اختيارية "للاحتياط".

{
  "messages": [
    {
      "id": "m_1842",
      "text": "On my way",
      "sentAt": "2026-01-29T10:12:03Z",
      "sender": {"id": "u_7", "name": "Maya"},
      "reactions": [{"emoji": "👍", "count": 3}],
      "readBy": ["u_2", "u_5"]
    }
  ],
  "typing": ["u_7"]
}

مع Protobuf، نفس البيانات غالبًا ما تكون أصغر على السلك لأن الحقول تُرمز كوسوم رقمية وأنواع مضغوطة، وليس كسلاسل متكررة. هذا يساعد عندما تكون التحديثات متكررة والمستخدمون على باقات محدودة. المقايضة هي التنسيق: تحتاج مخططًا، توليد كود، وقواعد أكثر صرامة للتغييرات. التصحيح ينتقل من "قراءته في سجل" إلى "فكّه بالمخطط الصحيح".

نتيجة شائعة هي نهج مُقسّم. الفرق غالبًا تحتفظ بهذه النقاط في JSON لأن الناس يفحصونها كثيرًا والحمولات متواضعة: تسجيل الدخول، الإعدادات، أعلام المزايا، والعديد من شاشات الإدارة. Protobuf يتألق غالبًا لحركة المرور العالية مثل مزامنة الرسائل، التحديثات التدريجية، وجود الكتابة ومؤشرات الكتابة، والقوائم الكبيرة المتكررة، ودفعات التحليلات.

لإبقاء النشر آمنًا لإصدارات التطبيقات القديمة، لا تقلب كل شيء دفعة واحدة. شغّل الصيغتين بالتوازي (مثلاً عبر هيدر يطلب Protobuf)، اجعل الإعدادات الافتراضية معقولة، وحافظ على قواعد التوافق صارمة. في Protobuf، لا تُعيد استخدام أرقام الحقول أبدًا. في JSON، اجعل الحقول الجديدة اختيارية وتجنب تغيّر النوع بصمت.

قائمة فحص سريعة وخطوات لاحقة

اتخذ هذا القرار بناءً على حركة المرور وواقع الإصدارات، لا على الذوق. خيار الصيغة يستحق العناء فقط عندما يقلل ألم المستخدم (شاشات بطيئة، نفاد الوقت، استنزاف البطارية) أو ألم الفريق (تغييرات مكسورة، صعوبة التصحيح).

فحص سريع:

• هل أي استجابات عادةً أكبر من بضع مئات من الكيلوبايت، أو تُنادى عشرات المرات في الجلسة (خلاصات، دردشة، تتبع، مزامنة)؟
• هل تظل نسخ التطبيقات القديمة نشطة لأشهر؟
• هل يمكنك فرض انضباط المخطط في كل مرة يتغير فيها API؟
• هل يحتاج الدعم وQA لنسخ ولصق وفحص الحمولات لإعادة إنتاج المشاكل؟

قاعدة إبهام: إذا كانت الحمولات صغيرة وغالبًا ما يحتاج الناس لقراءتها، JSON عادةً يفوز مبدئيًا. إذا كانت لديك حمولات ثقيلة ومتكررة (أو شبكات غير موثوقة) ويمكنك الحفاظ على مخططات صارمة، Protobuf قد يؤتي ثماره.

خطة خطوات مقترحة ومنصفة:

1. اختر نقطة نهاية مشغولة واحدة (خلاصة رئيسية أو مزامنة).
2. نفّذها بـ JSON و Protobuf مع نفس الحقول والسلوك.
3. قسّ الحجم على السلك، زمن التحليل على هاتف متوسط المواصفات، معدلات الخطأ، ووقت التصحيح.
4. اكتب سياسة توافق حول كيفية إضافة وإهمال الحقول وكيفية تعامل العملاء مع الحقول المجهولة.

إذا أردت بناء نموذج أولي بسرعة، AppMaster (appmaster.io) يمكنه توليد واجهات خلفية وتطبيقات من نموذج بيانات معرف، ما يجعل تشغيل تجربة متوازية والتكرار على تغييرات المخطط أسهل دون كتابة كميات كبيرة من الشيفرة يدويًا.