رکورد تصمیم معماری: API با JSON یا gRPC

وضعیت

پذیرفته‌شده

زمینه

در حال طراحی API برای یک سرویس جدید هستیم که چندین کلاینت از آن استفاده خواهند کرد. دو گزینه را برای پیاده‌سازی API بررسی کرده‌ایم: استفاده از JSON روی HTTP یا استفاده از gRPC.

JSON روی HTTP رویکردی پرکاربرد برای ساخت API است و بسیاری از زبان‌های برنامه‌نویسی و چارچوب‌ها از آن پشتیبانی می‌کنند. این رویکرد ساده، سبک و قابل‌فهم است و آن را برای بسیاری از پروژه‌ها انتخاب خوبی می‌کند. با این حال، می‌تواند از گزینه‌های دیگر کم‌کارایی‌تر باشد، به‌ویژه هنگام کار با حجم زیاد داده.

gRPC، در مقابل، فناوری جدیدتری است که راه کارآمدتری برای ساخت API ارائه می‌دهد. برای انتقال داده از سریال‌سازی دودویی استفاده می‌کند که می‌تواند سریع‌تر و فشرده‌تر از استفاده از JSON باشد. gRPC همچنین از استریم دوطرفه پشتیبانی می‌کند و آن را برای برنامه‌های بی‌درنگ انتخاب خوبی می‌سازد.

تصمیم

پس از بررسی مزایا و معایب هر دو گزینه، تصمیم گرفته‌ایم برای API خود از gRPC استفاده کنیم. هرچند JSON روی HTTP گزینهٔ ساده‌تری است، باور داریم gRPC راه‌حلی کارآمدتر و مقیاس‌پذیرتر برای سرویس ما فراهم می‌کند. همچنین پیش‌بینی می‌کنیم API ما حجم زیادی داده را پردازش کند و سریال‌سازی دودویی gRPC برای این مورد استفاده کارآمدتر خواهد بود.

علاوه بر این، باور داریم پشتیبانی gRPC از استریم دوطرفه برای برنامه‌های بی‌درنگی که ممکن است در آینده توسعه دهیم مفید خواهد بود.

پیامدها

با انتخاب gRPC، برای ساخت API خود باید مجموعه‌ای متفاوت از ابزارها و کتابخانه‌ها را در مقایسه با استفاده از JSON روی HTTP به کار ببریم. این ممکن است زمان و تلاش بیشتری برای یادگیری و پیاده‌سازی این فناوری‌ها بطلبد. افزون بر این، کلاینت‌هایی که می‌خواهند از API ما استفاده کنند باید از کتابخانه‌های سازگار با gRPC استفاده کنند که ممکن است به اندازهٔ کتابخانه‌های JSON روی HTTP به‌طور گسترده پشتیبانی نشوند.

با این حال، باور داریم مزایای استفاده از gRPC بر این معایب بالقوه می‌چربد و مطمئنیم این تصمیم به API کارآمدتر و مقیاس‌پذیرتر منجر خواهد شد.