GraphQL در مقابل gRPC در مقابل REST: انتخاب مناسب API

استاندارد تبادل داده بین فرانت اند و بک اند همیشه کمی بحث برانگیز بوده است. با وجود فناوری‌های API مختلف برای اشتراک‌گذاری داده‌ها بین کلاینت‌ها و سرورها، و هر کدام مجموعه‌ای از قابلیت‌های منحصربه‌فرد خود را دارند، تلاش برای تصمیم‌گیری اینکه کدام یک به شما بهترین خدمات را می‌دهد، می‌تواند بسیار دلهره‌آور باشد. سه فناوری محبوب در حال حاضر برای ایجاد APIها GraphQL، gRPC و REST هستند. در این پست، نحوه عملکرد هر یک از جمله مزایا و معایب آنها را بررسی خواهیم کرد.

GraphQL

نمایش داده ها با  schemas

تعریف کوئری ها

جهش ها و اشتراک ها با  schemas

جوانب مثبت GraphQL

معایب GraphQL

REST

مزایا REST

معایب REST

gRPC

مزایا gRPC

معایب gRPC

مقایسه gRPC در مقابل REST در مقابل GraphQL

GraphQL

GraphlQL یک زبان پرس و جو داده است که به طور منحصر به فرد به مشتریان اجازه می دهد تا داده های خاصی را که نیاز دارند درخواست کنند. برخلاف روش‌های HTTP REST، گراف کیو ال – GraphlQL  از کوئری‌ها، mutations  و subscriptions  برای منبع‌یابی و دستکاری داده‌ها استفاده می‌کند. کوئری‌ها داده‌ها را از سرور درخواست می‌کنند در حالی که mutations  داده‌ها را به سرور ارسال می‌کنند و داده‌های دروازه‌شده توسط سرور را تغییر می‌دهند. subscriptions هنگام تغییر داده‌ها، معمولاً از طریق Websockets، به‌روزرسانی‌هارا به صورت live دریافت می‌کنند. در مجموع، GraphQL از زبان هایی مانند جاوا اسکریپت، جاوا، پایتون، روبی، PHP و غیره پشتیبانی می کند.

نمایش داده ها با schemas

با GraphQL، داده ها از طریق schemas.  نمایش داده می شوند. یک schemas. یک شی، فیلدهایی که شی شامل آن است و نوع داده ای که فیلدها می توانند نگه دارند را تعریف می کند. در اینجا یک  مثال از schemas: 

در اینجا User همان شی است و در داخل آن فیلدها یا خواصی را که شیء دارد از جمله انواع داده را مشخص می کنیم. این بدان معناست که در هر پرس و جوی که بر روی شی User عمل می کند، تنها فیلدهایی که می توانند ظاهر شوندname و age هستند. برای هر دوی این فیلدها، تنها نوع داده ای که می توان روی آن نوشت یا خواند، به ترتیب رشته ها و اعداد هستند.

در GraphQL، وقتی انواع فیلدها با علامت ! مانند آنچه در بالا داریم دنبال می‌شوند، به این معنی است که فیلدها غیر قابل تهی هستند. زمانی که شیء به روز می شود باید داده هایی برای آنها نوشته شود و فیلدها همیشه مقادیری را هنگام پرس و جو ارائه می دهند.

Defining queries, mutations, and subscriptions with schemas

همانطور که قبلا ذکر شد، به طور عمده سه عمل وجود دارد که می توان بر روی اشیاء داده انجام داد:queries ، mutations، و subscriptions . اینها همچنین می توانند با استفاده از زبان GraphQL’s schema تعریف شوند. با query schema ، می توانید با تعیین شی و فیلدهای زیر شی مورد نظر خود، داده ها را از سرور GraphQL خود درخواست کنید:

در بالا، ما لیستی از کاربران در پایگاه داده، به ویژه نام و سن آنها را درخواست می کنیم. به عنوان مثال، شی کاربر می تواند فیلدهای دیگری مانند جنسیت یا عنوان شغلی داشته باشد، اما فقط فیلدهایی که ما درخواست کرده ایم برای ما ارسال می شود. این مزیتی است که GraphQL نسبت به REST دارد. در REST، هنگامی که یک نقطه پایانی پرس و جو می شود، تمام داده های پشت آن نقطه پایانی برای شما ارسال می شود و به شما اجازه می دهد تا از طریق آرایه مرتب کنید و فیلدهای خاص مورد نیاز خود را انتخاب کنید.

GraphQL انعطاف پذیرتر است زیرا به شما امکان می دهد ساختار نتیجه خود را سفارشی کنید. این باعث صرفه جویی در مصرف حافظه و CPU می شود که برای فیلتر کردن داده ها صرف می شود. و از آنجا که پرس و جوهای GraphQL معمولاً داده های کمتری درخواست می کنند، معمولاً سریعتر از درخواست های REST پردازش می شوند.

با یک mutation schema، می توانید تغییراتی در داده های موجود ایجاد کنید یا داده های جدید را در پایگاه داده خود ارسال کنید. به عنوان مثال، اگر می خواهید یک کاربر جدید ایجاد کنید یا جزئیات یک کاربر موجود را به روز کنید، از mutation استفاده می کنید:

با یک طرح subscription، می‌توانید در یک شی مشترک شوید و هر زمان که تغییراتی در آن شی ایجاد می‌شود، از سرورتان بخواهید کلاینت خود را در زمان واقعی به‌روزرسانی کند. به عنوان مثال، اگر می‌خواهید برنامه مشتری خود را در زمان واقعی هر زمان که یک کاربر موجود حذف یا تغییر می‌کند، یا کاربر جدیدی ایجاد می‌شود، به‌روزرسانی شود، می‌توانید در شیء کاربر و زمینه‌های مورد علاقه خود مشترک شوید:

با تعداد زیادی تولیدکننده کد شخص ثالث، نوشتن کد GraphQL برای یک پلتفرم و ایجاد خودکار آن برای پلتفرم دوم با استفاده از این ژنراتورها آسان است. می‌توانید در GraphQL Code Generator احتمالات را بررسی کنید. همانطور که می‌توانید داده‌های دقیقی را که می‌خواهید سرور با آن در فرانت‌اند پاسخ دهد تعریف کنید، می‌توانید فیلدهای جدیدی را به مدل داده در سمت سرور بدون نیاز به ایجاد یک API نسخه‌شده جدید اضافه کنید. این همچنین منجر به شکست کمتر کد فرانت اند می شود فقط به این دلیل که یک فیلد جدید به مدل اضافه کرده اید و فراموش کرده اید که کد فرانت اند را به روز کنید.

GraphQL همچنین از آپلود خارج از جعبه فایل پشتیبانی نمی کند و برای پیاده سازی این عملکرد به راه حلی نیاز دارد. پشتیبانی از GraphQL برای چارچوب‌های مختلف وب/برنامه در مقایسه با REST هنوز ضعیف است. اکوسیستم JS بیشترین پشتیبانی را دارد، اما چشم انداز در حال تغییر است و پشتیبانی روز به روز برای سایر زبان ها و چارچوب ها بهبود می یابد. و در نهایت، در مقایسه با REST، GraphQL منحنی یادگیری تندتری دارد.

REST

محبوب ترین و پرکاربردترین فرمت API در این لیست REST است که مخفف عبارت represational state transfer است.

APIهای REST از روش‌های HTTP مانند GET، POST، PUT و DELETE برای دسترسی و دستکاری داده‌ها در شناسه‌های منبع یکسان (URI) استفاده می‌کنند:

روش های GET داده ها را از یک سرور بازیابی می کنند

روش های POST داده ها را از کلاینت به سرور انتقال می دهند

روش های PUT داده ها را در سرور تغییر می دهند

روش های DELETE داده های موجود در سرور را پاک می کنند.

برای مثال، زمانی که در حال استفاده است، یک درخواست GET می‌تواند روی یک URI که معمولاً شبیه /api/users است انجام شود. یک عملیات REST معمولا داده ها را از سرور به مشتری برمی گرداند.

سپس داده‌های پاسخ REST می‌توانند در قالب‌هایی مانند JSON، CSV، XML، یا RSS بیایند و داده‌های پاسخ REST معمولاً به صورت کلید/مقدار ارائه می‌شوند:

مزایا REST

ذخیره سازی در REST آسان است زیرا با حذف نیاز مشتری و سرور شما به تعامل مداوم با یکدیگر، بهبود عملکرد و مقیاس پذیری، از HTTP استفاده می کند. بلوغ REST در دنیای فناوری یکی از بزرگترین مزایای آن است. برخلاف GraphQL و gRPC که می‌توانند راه‌حل‌های مهمی برای ایجاد API در نظر گرفته شوند، همه جا وجود دارد. با توجه به محبوبیت REST، بسیاری از توسعه دهندگان از قبل با آن آشنا هستند و کار کردن با آن را آسان می دانند. و بنابراین، اگر یک API تجاری برای بسیاری از توسعه دهندگان شخص ثالث ایجاد کنید تا آن را مصرف کنند، ممکن است REST بهترین گزینه برای شما باشد. نظارت و محدود کردن نرخ APIهای مبتنی بر REST در مقایسه با GraphQL آسانتر است زیرا هر منبع معمولاً در پشت یک نقطه پایانی منحصر به فرد قرار دارد. در نتیجه، منابع فردی را نیز می توان به راحتی در پشت یک دیوار پرداخت قفل کرد.

معایب REST

محموله های بزرگ؛ در جایی که می‌توانید فیلدهای خاصی را تحت یک منبع در GraphQL انتخاب کنید، REST از شما می‌خواهد که قبل از حلقه زدن از طریق آن برای دریافت داده‌های مورد نیاز، تمام داده‌های زیر منبع را درخواست کنید، که اغلب منجر به بارهای سنگین می‌شود. شما می توانید با ایجاد یک نقطه پایانی جدید یا افزودن فیلتر سمت سرور بر اساس آرگ های پرس و جو، با آن مقابله کنید، اما انجام این کار برای هر مورد امکان پذیر نیست. در حالی که با GraphQL می‌توانیم درخواست‌های منابع مختلف را دسته‌بندی کنیم و آنها را به نقطه پایانی یکسانی در graphql/ ارسال کنیم و یک بار در یک رفت و برگشت اجرا شوند، با REST، درخواست‌های مختلف باید به نقاط پایانی مختلف ارسال شوند و در نتیجه چندین رفت و برگشت انجام می‌شود.

GraphQL ایجاد تغییرات در طرح پایگاه داده را بسیار آسان می کند. از آنجایی که پرس‌و‌جوها فقط شامل درخواست فیلدهای خاص هستند، فیلدهای جدید را می‌توان از یک منبع حذف کرد بدون اینکه تغییراتی ایجاد کند و از شما بخواهد برنامه خود را نسخه کنید. gRPC همچنین دارای ویژگی‌های backward compatibility   است که به‌روزرسانی ساختار داده شما را بدون شکستن کد مشتری آسان می‌کند. REST با این انعطاف پذیری همراه نیست.

gRPC

gRPC یک چارچوب فراخوانی رویه ای از راه دور منبع باز (RPC) با کارایی بالا است که توسط گوگل ایجاد شده است. در gRPC، بافرهای پروتکل  protocol buffers درخواست های API را به سرور ارسال می کنند. این درخواست‌ها و پاسخ‌های API پیام‌های بافر پروتکل هستند و هر کدام باید نوع خاص خود را با استفاده از زبان بافر پروتکل تعریف کنند. سرویس‌ها برای جفت کردن درخواست‌های API با پاسخ‌های متناظرشان تعریف می‌شوند و کامپایلر بافرهای پروتکل، مصنوعات کد سرور و کلاینت را برای سرویس API شما تولید می‌کند:

در بلوک کد بالا، پیام UserRequest درخواست، پیام UserResponse پاسخ، و GetUser نقطه پایانی API است.

gRPC از میزبانی از زبان‌ها پشتیبانی می‌کند و برنامه کلاینت شما می‌تواند به هر یک از این زبان‌ها نوشته شود، زیرا کد کلاینت برای هر یک از این زبان‌ها را می‌توان با کمک ابزار protoc  تولید کرد. از امروز، gRPC از زبان‌های زیر پشتیبانی می‌کند: C#، C++، Dart، Go، Java، Kotlin، Node، Objective-C، PHP، Python و Ruby.

مزایا gRPC

بافرهای پروتکل، که gRPC از جعبه خارج می‌شود، از انواع داده‌های بیشتری نسبت به JSON پشتیبانی می‌کند و به لطف فرمت باینری بهینه‌شده آن، بسیار سریع‌تر است. gRPC از پخش جریانی full-duplex خارج از جعبه پشتیبانی می کند که آن را برای ویژگی هایی مانند تماس های ویدیویی و صوتی مناسب می کند. از طرف دیگر با REST، پرس و جوها یک به یک بررسی می شوند. gRPC تعادل بار را انجام می دهد تا درخواست های مشتری به طور مساوی در بین سرورها توزیع شود تا از بارگذاری بیش از حد یک سرور خاص جلوگیری شود. این کار عملکرد کلی برنامه شما را بهبود می بخشد.

ویژگی load balancing و همچنین این واقعیت که gRPC به طور پیش فرض از HTTP2 استفاده می کند، تاخیر در gRPC را بسیار کمتر از API های REST می کند. gRPC به گونه‌ای طراحی شده است که سازگار با گذشته باشد، بنابراین افزودن فیلدها/روش‌های جدید به سرویس gRPC معمولاً مشتریان موجود را از بین نمی‌برد. این باعث می‌شود وقتی سرویس را تغییر می‌دهید، مجبور نباشید همه مشتریان موجود را به‌روزرسانی کنید. در نهایت، gRPC داده‌ها را در قالب باینری (بافرهای پروتکل) سریال‌سازی می‌کند، که بسیار سریع‌تر از JSON REST است و به gRPC مزیت عملکرد بیشتری می‌دهد.

معایب gRPC

بافرهای پروتکل، فرمت رسمی داده های gRPC، در حال حاضر تنها تعداد انگشت شماری از زبان ها را پشتیبانی می کند. از زبان هایی مانند R و Swift پشتیبانی نمی کند. JSON، که REST از آن استفاده می کند، تقریباً توسط همه زبان ها پشتیبانی می شود. gRPC با پشتیبانی از مرورگر خارج از جعبه همراه نیست، اگرچه راه‌حل‌هایی برای آن وجود دارد. شما باید از gRPC-Web استفاده کنید که پسوند gRPC برای وب است و بر اساس HTTP 1.1 است. همه ویژگی های gRPC را ارائه نمی دهد، اما اگر می خواهید از gRPC در مرورگر استفاده کنید، مورد خوبی است.

gRPC vs. REST vs. GraphQL comparison

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

منبع: https://blog.logrocket.com/graphql-vs-grpc-vs-rest-choosing-right-api/