مقایسه GraphQL و REST

این روزها GraphQL و REST دو مورد از محبوب‌ترین استاندارد‌ها در طراحی APIها هستند. REST برای مدتی طولانی یک استاندارد بوده است، در حالی که GraphQL بسیار نو و جدید است. تفاوت‌های اصلی میان این دو چیست؟ چرا اکثر توسعه‌دهندگان به سمت استفاده از GraphQL در حال حرکت هستند؟ دیزاین و یا طراحی APIها در سال ۲۰۲۰ به چه سمتی در حال حرکت است؟ بیایید در این مقاله نگاهی به این موضوع بیندازیم.

در دهه گذشته، RESTful API‌ها یکی از مفاهیم رایج توسعه وب بوده و این سبک خاص به عنوان یک معماری استاندارد برای توسعه برنامه‌های مدرن وب و APIها شناخته می‌شود.

اما دیگر این مورد در حال جایگزینی با مفاهیم جدیدی مانند GraphQL است، زیرا بخش عظیمی از توجهات را به خود جلب کرده است. مقایسه این دو، روش خوبی برای شناختن استاندارد‌های طراحی APIهای موجود در سال ۲۰۲۰ است، پس بیایید مستقیم سراغ آن برویم!

موارد و نکات اصلی در مقایسه GraphQL با REST

در حالی که GraphQL و REST را می‌توان به عنوان روش‌های مختلف برای برقراری ارتباط بین کلاینت و دیتابیس مقایسه کرد، به این نکته هم توجه داشته باشید که آن‌ها معادل‌های برابر هم نیستند.

REST به هیچ نرم‌افزار خاصی اشاره نمی‌کند. در ابتدا توسط Roy Fielding در سال ۲۰۰۰، به عنوان مجموعه‌ای از محدودیت‌ها برای ساخت سیستم‌های تحت وب تعریف شد که شامل ویژگی‌هایی مانند statelessبودن و یا معماری کلاینت-سرور و غیره می‌شد. هنگامی که یک برنامه مطابق با نیازمندی‌های و الزامات باشد، می‌توان آن را RESTful نامید. از طرف دیگر، GraphQL، که برای اولین بار در سال ۲۰۱۵ در اختیار عموم قرار گرفت، یک زبان به جهت جست‌وجو میان داده‌ها و دستکاری آن‌ها برای APIها، همانند ران‌تایم برای کوئری‌ها است.

ساخت برنامه‌ها به صورت RESTful به هنگام محبوب‌ترشدن وب، بیشتر شد. اما بیشترین رشد و میزان محبوبیت GraphQL را می‌توانید در نمودار زیر، که نشان‌دهنده رشد و کسب محبوبیت آن در بازه ۴ ساله ۲۰۱۶ تا ۲۰۲۰ است، مشاهده کنید.

چرا REST به یک استاندارد تبدیل شد؟ و چرا به زودی تنها استاندارد موجود باقی نخواهد ماند؟

بیایید این سوال را از Adam Polak، سرپرست نرم‌افزاری Node.js بپرسیم و پاسخش را مطالعه کنیم:

«قبل‌ها، وقتی که REST به یک استاندارد تبدیل شد، برای برنامه‌های وب، ما تنها مجبور بودیم که اتصال‌های به سمت سرور را مدیریت کنیم و یا حتی برنامه‌های پیچیده‌تر، نظیر اتصال‌های سرور به سرور و همچنین امروزه از کلاینت‌های متنوع و گوناگون نیز پشتیبانی می‌کنیم. برنامه‌های موبایلی مشهور‌تر شده‌اند و با این تفسیر، سرعت پاسخگویی و یا اندازه کوئری از اهمیت بیشتری برخوردار شده است.»

افزایش تعداد موارد سناریو‌ها تنها دلیل نبوده است. از آنجایی که تقاضا برای کارایی و عملکرد افزایش یافت، مسائل و مشکلات معمولی REST که بایستی از طریق افزایش یا کاهش اندازه دیتای دریافتی انجام شود (که به تجزیه و تحلیل داده آسیب وارد می‌کند) و یا نیاز به تنظیم‌کردن بک‌اند به جهت پیاده‌سازی چندین تغییر در سمت فرانت‌اند (یک مشکل بزرگ در تیم‌های بزرگ و چابکی که به صورت تعاملی کار می‌کنند)، می‌تواند یک مشکل و مزاحمت بزرگ باشد.

چه چیزی GraphQL را جذاب می‌کند؟

GraphQL در رادار تکنولوژی وبسایت The Software House وجود دارد. از آن‌جایی که Adam در کلماتش این چنین می‌گوید:

«سه عامل اصلی در فروش و ارائه GraphQL وجود دارد که آن‌ها در The Software House، از نظر ما مهم هستند.

اولین آن‌ها قرارداد (GraphQL schema) میان فرانت‌اند و بک‌اند است. این موضوع این اعتماد به نفس را به ما می‌دهد که ما در حال ارسال مجموعه مناسبی از دیتا هستیم. همچنین اعتبارسنجی‌ای در اختیارمان قرار دارد، کاری که می‌توانیم از طریق REST نیز انجام دهیم اما کدنویسی بیشتری نیاز دارد.

دومین مورد، انعطاف‌پذیری است. کلاینت‌ها می‌توانند انتخاب کنند که کدام مجموعه از دیتا را دریافت کنند. این موضوع کنترل بیشتری بر روی سایز پاسخ یا response به ما می‌دهد.

آخرین مورد چیزی است که ما آن را بخیه‌زدن اسکیما و یا schema stitching می‌نامیم. GraphQL (مخصوصا Apollo) این اجازه را به ما می‌دهد که چندین اسکیما، از APIهای مختلف را به یکدیگر پیوند بزنیم و تمامی آن‌ها را تحت عنوان یک اسکیما GraphQL ارائه کنیم که باعث می‌شود آن را به یکی از بهترین ابزار‌ها برای ایجاد الگوی طراحی به اصطلاح Backend For Frontend تبدیل کند.»

حالا به سراغ REST برویم

به هر حال این بدان معنی نیست که REST به زودی کنار گذاشته می‌شود. هنوز هم در برخی موارد بهترین گزینه است:

استفاده از GraphQL شامل برخی از چالش‌هایی می‌شود که انجام بعضی عملیات‌ها را نسبت به REST سخت‌تر می‌کند. برای مثال، caching در APIهای براساس REST نسبت به APIهایی که براساس GraphQL هستند، بسیار آسان‌تر است (حتی با توجه به این که این روز‌ها از وجود dataloader برخوردار هستیم).

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

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

همه چیز در رابطه با مقایسه REST با GraphQL نیست! روند‌های طراحی API نیز مهم است!

بحث REST در مقابل GraphQL ممکن است گاهی اوقات روش‌ها و روند‌های هیجان‌انگیز دیگری را در دنیای طراحی APIها، که در سال ۲۰۲۰ مورد توجه قرار گرفته‌اند را تحت‌الشعاع قرار دهد. همانطور که Adam بیان می‌کند:

«با توجه به اینکه استفاده از معماری میکروسرویس‌ها روز به روز بیشتر می‌شود، الگوهایی نظیر Backend For Frontend و یا API Gateway برای APIهای مقیاس‌پذیر، مهم و حیاتی می‌شوند. به همین دلیل پروژه‌هایی نظیر Apollo Federation و یا Hasura، باید مواردی باشند که شما از آن‌ها باخبر هستید.»

بخش اعظم وب در رابطه با REST / GraphQL و اندکی در رابطه با WebSocket است. گاهی اوقات ممکن است شانس این را داشته باشیم که با JSON RPC کار کنیم، به هر حال این یک موقعیت مناسب است.

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

خلاصه

• هم GraphQL و هم REST، هر دو همچنان قابل استفاده هستند و جایگاه خود را در توسعه وب حفظ کرده‌اند، اما شرایطی وجود دارد که یکی نسبت به دیگری بهتر است.
• GraphQL در معماری‌های پیچیده‌ای که از تمام پتانسیل ارائه شده توسط جدیدترین دستگاه‌ها و تکنولوژی‌ها استفاده می‌شود، برتر است.
• REST در مواردی که بر ارتباط کلاینت با سرور و یا سروری با سرور دیگر تمرکز می‌کند، برتری دارد. قدرت آن هم در تعداد ابزارهای عالی موجود و سادگی آن نهفته است.
• با توجه به افزایش محبوبیت میکروسرویس‌ها، هم GraphQL و هم سایر الگو‌های طراحی API به طور فزاینده‌ای در حال محبوب‌شدن هستند و قطعا ارزش بررسی را دارند که این موارد به ویژه Backend For Frontend و WebSocket را شامل می‌شود.

منبع: https://tsh.io/blog/graphql-vs-rest