سجل قرار البنية المعمارية: واجهة برمجية بين JSON وgRPC

الحالة

مقبول

السياق

نصمم واجهة برمجية (API) لخدمة جديدة سيستخدمها عدة عملاء. وقد نظرنا في خيارين لتنفيذ الواجهة: استخدام JSON عبر HTTP أو استخدام gRPC.

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

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

القرار

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

وإضافةً إلى ذلك، نعتقد أن دعم gRPC للبث ثنائي الاتجاه سيفيد التطبيقات الفورية التي قد نطورها في المستقبل.

العواقب

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

ومع ذلك، نعتقد أن فوائد استخدام gRPC تفوق هذه السلبيات المحتملة، ونثق بأن هذا القرار سيؤدي إلى واجهة برمجية أكثر كفاءة وقابلية للتوسع.