GraphQL یا REST؟
بحث GraphQL در برابر REST معمولاً بهعنوان «قدیمی در برابر مدرن» مطرح میشود. این قاببندی، غلط و پرهزینه است.
GraphQL برای حل یک مسئلهٔ مشخص ساخته شد. اگر آن مسئله را دارید، ارزشمند است. اگر ندارید، پیچیدگیای خریدهاید که سودی نمیدهد.
مسئلهای که GraphQL حل میکند
فرض کنید صفحهٔ پروفایل کاربر باید نام، آخرین سفارشها، و امتیاز وفاداری را نشان دهد.
با REST، یا سه درخواست میزنید — که روی شبکهٔ کند سه برابر تأخیر است — یا یک نقطهٔ انتهایی میسازید که همه را با هم برمیگرداند.
و اگر اپ موبایل نسخهٔ کوچکتری از همان صفحه دارد که فقط نام و امتیاز میخواهد؟ یا نقطهٔ انتهایی دیگری، یا دادهٔ اضافه میفرستید.
دو مشکل نامدار:
دریافت کم — یک درخواست کافی نیست، باید چند بار بروید.
دریافت زیاد — دادهای میگیرید که لازم ندارید.
GraphQL این را حل میکند: مصرفکننده دقیقاً میگوید چه فیلدهایی میخواهد، در یک درخواست.
هزینههایی که میآورد
اینجا جایی است که مقایسهها معمولاً کوتاه میآیند.
کارایی پرسوجو، مسئولیت شما
در REST، هر نقطهٔ انتهایی را خودتان نوشتهاید و میدانید چه کوئریهایی میزند.
در GraphQL، مصرفکننده شکل پرسوجو را تعیین میکند — و میتواند درخواستی بفرستد که صدها کوئری تولید کند.
مشکل کلاسیکش این است: فهرست صد سفارش بخواهید، و برای هر سفارش نام مشتری. پیادهسازی ساده، صد و یک کوئری میزند.
راهحلهایش شناختهشدهاند — دستهکردن درخواستها — و باید عمداً پیاده شوند. این کار اضافهای است که در REST لازم نبود.
محدود کردن پیچیدگی
باید جلوی پرسوجوی مخرب را بگیرید: عمق تودرتویی، تعداد گره، هزینهٔ تخمینی. بدون این، یک درخواست میتواند سرور را بخواباند.
کش، سختتر
در REST، کش HTTP کار میکند: آدرس ثابت، پاسخ قابل کش. در GraphQL معمولاً همهچیز یک نقطهٔ انتهایی با POST است و کش استاندارد بیفایده میشود.
راهبردهای کش در راهبرد کش — و در GraphQL باید در لایهٔ اپلیکیشن پیاده شوند.
پایش و اشکالزدایی
در REST، لاگ میگوید کدام نقطهٔ انتهایی کند است. در GraphQL همهٔ درخواستها به یک آدرس میروند و باید در سطح فیلد پایش کنید تا بفهمید کجا کند است.
منحنی یادگیری و نیرو
در بازار ایران، توسعهدهندهای که GraphQL کار کرده باشد کمتر است. این معیار در انتخاب فناوری وزن بالایی دارد.
کِی GraphQL واقعاً ارزشش را دارد
چند مصرفکنندهٔ متفاوت با نیازهای متفاوت. وب، موبایل، پنل ادمین، شریک تجاری — هرکدام برش دیگری از همان داده میخواهند. این اصلیترین دلیل است.
دادههای عمیقاً بههممرتبط، که مصرفکننده باید چند سطح دنبال کند.
تیم فرانتاند مستقل که نمیخواهد برای هر تغییر کوچک منتظر بکاند بماند. این مزیت سازمانی است، نه فنی — و اغلب مهمترین دلیل واقعی.
اپ موبایل روی شبکهٔ ضعیف، جایی که کم کردن تعداد رفتوبرگشت واقعاً حس میشود.
کِی REST بهتر است
سرویس ساده با چند موجودیت.
عملیاتمحور بودن. «تأیید سفارش»، «لغو پرداخت» — اینها فعلاند نه پرسوجو، و در REST طبیعیتر بیان میشوند.
نیاز به کش HTTP.
آپلود و دانلود فایل.
مصرفکنندهٔ بیرونی متنوع. REST آشناتر است و مستندسازی و آزمودنش سادهتر — که در مستندسازی API گفتیم چقدر اهمیت دارد.
تیمی که تجربهٔ GraphQL ندارد و پروژه فوری است.
گزینهای که نادیده گرفته میشود
REST با پارامتر انتخاب فیلد.
نقطهٔ انتهایی معمولی که بپذیرد کدام فیلدها برگردند، و امکان گنجاندن موجودیتهای مرتبط را بدهد.
بخش زیادی از مسئلهٔ دریافت زیاد را با کسری از پیچیدگی حل میکند — و کش HTTP هم دستنخورده میماند.
برای اکثر پروژههایی که فکر میکنند به GraphQL نیاز دارند، این کافی است.
معماری ترکیبی
خیلی از سامانههای بالغ هر دو را دارند:
- GraphQL برای پرسوجوهای پیچیدهٔ خواندنی که مصرفکنندگان متنوع دارند.
- REST برای عملیات، آپلود فایل، و سرویسهای ساده.
این تناقض نیست. ابزار متناسب با کار.
جدول
| REST | GraphQL | |
|---|---|---|
| سادگی شروع | زیاد | متوسط |
| کش HTTP | طبیعی | نیاز به کار |
| انعطاف مصرفکننده | کم | زیاد |
| ریسک پرسوجوی گران | کم | زیاد |
| پایش | ساده | نیاز به کار |
| نیرو در بازار ایران | زیاد | کم |
| مناسب فایل | بله | نه |
توصیه
اگر مطمئن نیستید، REST. سادهتر است، نیرویش هست، و مسائل کمتری دارد.
سراغ GraphQL بروید وقتی درد واقعی دارید — یعنی وقتی میتوانید نام ببرید کدام صفحه چند درخواست میزند و چقدر دادهٔ اضافه میگیرد.
و اگر رفتید، از روز اول محدودیت پیچیدگی و دستهکردن کوئریها را پیاده کنید. اینها را نمیشود بعداً روی سامانهٔ زنده اضافه کرد بدون اینکه مصرفکنندگان بشکنند.
در هر دو حالت، بررسی دسترسی در سرور و بهازای رکورد انجام میشود — انتخاب پروتکل چیزی از آن الزام کم نمیکند.