انتخاب فناوری هایی که در استک فناوری پروژه بعدی شما گنجانده می شوند، می تواند دشوار باشد. در بسیاری از موارد، و به خصوص زمانی که صحبت از انتخاب بین GraphQL و RESTful API ها می شود، همه چیز در مورد انتخاب بهترین معماری طراحی API بعدی است. چهار راه قابل توجه برای ساخت API وجود دارد: SOAP، GRPC، REST و GraphQL. ما اغلب هر زمان که بخواهیم API بسازیم ذهن خود را به REST و GraphQL محدود می کنیم. این به این دلیل است که REST روش‌های سنتی ساخت API با SOAP و GRPC را تغییر داد. GraphQL به طور گسترده ای به عنوان REST بهتر برچسب گذاری می شود زیرا نشان دهنده راه بهتری برای ساخت API است. بسیاری از توسعه دهندگان بر این باورند که GraphQL جایگزین REST خواهد شد. بسیاری دیگر قبلاً کشف کرده‌اند که GraphQL به حل برخی از چالش‌های رایجی که توسعه‌دهندگان هنگام ساخت APIهای REST با آنها روبرو هستند، کمک می‌کند. این دو روش ساخت API کاملاً متفاوت هستند. در عمل، این فناوری ها با ارسال درخواست HTTP و دریافت نتیجه کار می کنند. هر دوی آنها مزایا و معایب خود را دارند و در این مقاله، به طور گسترده درباره این دو فناوری بزرگ که روش توسعه و مقیاس‌بندی APIهای ما را تغییر داده‌اند، بحث خواهیم کرد. با این حال، قبل از اینکه به جزئیات بپردازیم، ابتدا معنای GraphQL و API های RESTful را بررسی می کنیم.
GraphQL چیست؟
GraphQL یک زبان کوئری API و همچنین یک زمان اجرا برای پاسخ دادن به آن کوئری ها با داده های موجود است. همچنین به ابزارهای قدرتمندی برای رسیدگی به پیچیده ترین کوئری ها مجهز شده است.
ویژگی مرکزی GraphQL توانایی آن برای درخواست و دریافت تنها داده های خاص درخواست شده است، نه بیشتر. این باعث می‌شود مقیاس APIها همراه با برنامه شما بسیار ساده‌تر شود.
هیجان انگیزترین بخش GraphQL توانایی آن در ارائه تمام داده ها در یک نقطه پایانی است. کلاینت‌ها از دستگاه‌های مختلف درخواست می‌کنند و GraphQL درخواست‌های آنها را رسیدگی می‌کند و فقط داده‌های درخواستی آنها را برمی‌گرداند. این به طور منظم مشکل واکشی بیش از حد و کم واکشی را در API های RESTful حل می کند.
GraphQL توسط فیس بوک با هدف اصلی حل تجربه توسعه دهندگان برنامه تلفن همراه خود در حین کار با API های REST ایجاد شده است. از زمانی که اولین نسخه متن باز خود در سال 2015 منتشر شد، GraphQL به دلیل پذیرش این فناوری توسط بازیگران بزرگ در تجارت فناوری، رشد فوق العاده ای را تجربه کرد.
شرکت هایی که از GraphQL استفاده می کنند
در زیر لیستی از برخی از شرکت‌ها و برنامه‌هایی که از GraphQL به طور فعال در سرورهای خود استفاده می‌کنند، آمده است.
فیس بوک
فیس بوک GraphQL را ایجاد کرد و از سال 2012 از آن در تولید برای تقویت برنامه های تلفن همراه خود استفاده کرد. این شرکت شبکه اجتماعی چند میلیارد دلاری مشخصات GraphQL را در سال 2015 منبع باز کرد و آن را در بسیاری از محیط ها و برای تیم هایی با اندازه های مختلف در دسترس قرار داد. .
GitHub
GitHub همچنین استفاده از GraphQL را با ارائه GraphQL API برای ایجاد یکپارچه‌سازی، بازیابی داده‌ها و خودکارسازی گردش‌های کاری شما با استفاده از GitHub GraphQL API اعلام می‌کند. GitHub GraphQL API کوئری های دقیق و انعطاف پذیرتری را نسبت به GitHub REST API ارائه می دهد.
پینترست
Pinterest همچنین یکی از اولین پذیرندگان GraphQL است. این غول اشتراک‌گذاری عکس به طور عمومی در مورد اکتشاف اولیه GraphQL و نحوه استفاده از فناوری GraphQL که شرکت میلیارد دلاری آنها را نیرو می‌دهد، بحث کرده است.
بسیاری از شرکت های میلیارد دلاری دیگر مانند Intuit، Shopify، Coursera و Airbnb برنامه های خود را با GraphQL تامین می کنند. و این ترجیح گسترده نسبت به REST تنها در حال رشد است. برای آشنایی با نحوه پیاده سازی GraphQL در لاراول این مقاله را بررسی کنید، و برای نحوه واکشی داده ها در React با GraphQL نیز این مقاله را بررسی کنید.
RESTful API چیست؟
REST مخفف "Representational State Transfer" است که یک سبک معماری نرم افزاری برای سیستم های ابررسانه ای توزیع شده است. اصول و محدودیت هایی را برای تبادل منابع بین سرور و کلاینت ها تعریف می کند.
اگر این اصول در یک API رعایت شود، برنامه آن API به عنوان "RESTful" نامیده می شود. WordPress REST API نمونه بارز این است. برای آشنایی با نحوه پیاده سازی RESTful API در لاراول این مقاله را بررسی کنید.
در زیر برخی از اصول و محدودیت‌هایی که یک API باید رعایت کند تا به عنوان Restful API شناخته شود، آمده است:
Client-Server Decouple: کلاینت ها (Frontend) و سرور (Backend) کاملاً مجزا هستند و فقط می توانند از طریق نقاط پایانی با هم ارتباط برقرار کنند.
رابط یکنواخت: داده هایی که در رابط مشاهده می شود در همه دستگاه ها یکسان است.
عدم تابعیت: سرور به خاطر نمی آورد که آیا درخواست فعلی برای اولین بار انجام می شود یا خیر. هر بار که درخواستی ارائه می شود، باید تمام اطلاعات لازم برای پردازش آن را از ابتدا شامل شود.
قابلیت ذخیره سازی در حافظه پنهان: ذخیره سازی در حافظه پنهان و سشن مجاز است، اما آنها باید به گونه ای پیکربندی شوند که به کاربران نهایی اجازه دهند از ذخیره سازی داده ها انصراف دهند.
معماری سیستم لایه ای: APIها باید طوری طراحی شوند که نه کلاینت و نه سرور نتوانند به طور مستقیم ارتباط برقرار کنند یا از طریق یک واسطه.
GraphQL در مقابل REST: تفاوت چیست؟
تفاوت اصلی در نحوه ارتباط آنها با سرور است. GraphQL یک فناوری جدیدتر است که از یک نقطه پایانی برای پاسخ دادن به کوئری ها استفاده می کند، در حالی که REST از مجموعه ای از نقاط پایانی استفاده می کند که به درخواست های HTTP خاص پاسخ می دهند. GraphQL به طور کلی کارآمدتر و انعطاف پذیرتر از REST در نظر گرفته می شود.
مزایای GraphQL
در زیر چند مزیت استفاده از GraphQL آورده شده است که نشان می دهد چرا برای ساخت اپلیکیشن میلیارد دلاری بعدی کافی است.
واکشی داده از طریق یک نقطه پایانی API واحد
مزیت اصلی GraphQL توانایی آن برای دسترسی به هر یا همه نقاط داده از طریق یک نقطه پایانی API است.
یکی از رایج ترین مشکلات مربوط به API های RESTful داشتن نقاط پایانی بیش از حد برای دسترسی به اطلاعات است. در GraphQL، شما فقط یک نقطه پایانی دارید، بنابراین نیازی به ارسال چندین درخواست برای بازیابی اطلاعات مختلف در مورد یک شی ندارید.
نمودار زیر نمونه واضحی از بازیابی منابع با استفاده از RESTful API و GraphQL را نشان می دهد. می بینید که تنها یک نقطه پایانی برای دسترسی به منبع در سرور GraphQL وجود دارد، در حالی که چندین نقطه پایانی API برای دسترسی به منابع مختلف در RESTful API مورد نیاز است.
بدون واکشی بیش از حد یا کم واکشی
مشکل بیش از حد یا کمتر واکشی یک مشکل شناخته شده با API های RESTful است. این زمانی است که کلاینت ها با ضربه زدن به نقاط پایانی که ساختارهای داده ثابت را برمی‌گردانند، داده‌ها را دانلود می‌کنند، یا در غیر این صورت بیشتر یا کمتر از آنچه انتظار داشتند بازیابی می‌کنند.
واکشی بیش از حد منجر به دریافت، یا "واکشی"، درخواست بیشتر از آنچه برای یک درخواست معین نیاز است، می شود. تصور کنید که همه کاربران را در یک جدول به قصد نمایش نام کاربری آنها در صفحه اصلی خود آورده اید. در آن صورت، واکشی بیش از حد، تمام داده‌های هر کاربر، از جمله (و نه تنها) نام را برمی‌گرداند.
کم واکشی نسبتاً نادر است، اما زمانی اتفاق می افتد که نقطه پایانی خاص نتواند تمام اطلاعات درخواستی را ارائه دهد. کلاینت باید درخواست های بیشتری برای دسترسی به اطلاعات دیگر در صورت نیاز ارائه دهد.
GraphQL به طور موثر مشکل واکشی بیش از حد یا کم واکشی را با گرفتن منبع دقیقی که کلاینت درخواست کرده است بدون هیچ جزئیات اضافی حل می کند.
مدیریت بهتر سیستم های پیچیده و میکروسرویس ها
GraphQL می تواند پیچیدگی سیستم های چندگانه یکپارچه را متحد و پنهان کند.
به عنوان مثال، فرض کنید که می خواهیم از یک برنامه بک اند یکپارچه (monolithic) به یک معماری میکروسرویس مهاجرت کنیم. GraphQL API به مدیریت ارتباط بین میکروسرویس های مختلف با ادغام آنها در یک طرح GraphQL کمک می کند.
هنگامی که این اسکیما ها تعریف می شوند، هر دو قسمت فرانت اند و بک اند می توانند به طور جداگانه بدون هیچ تغییر دیگری با هم ارتباط برقرار کنند، زیرا فرانت اند می داند که داده های موجود در اسکیما همیشه در سراسر سیستم همگام هستند.
سریع و ایمن
مشکل واکشی بیش از حد می‌تواند منجر به مصرف پهنای باند بالاتر برای کلاینت‌ها شود که ممکن است به مرور زمان باعث تاخیر در برنامه شما شود. استفاده از الگوهای طراحی RESTful API برای مرتب کردن اطلاعات مورد نیاز از یک بار عظیم زمان‌برتر است.
به دلیل توانایی GraphQL برای جلوگیری از واکشی بیش از حد و زیر واکشی، سرور شکل ایمن، خوانا و قابل پیش بینی را برمی گرداند که درخواست ها و پاسخ های API شما را سریعتر می کند.
مزایای REST
با وجود محبوبیت روزافزون REST ،GraphQL هنوز یکی از محبوب ترین استانداردهای API است. بیایید نگاهی به چرایی آن بیندازیم.
منحنی یادگیری: API های RESTful ساده ترین برای یادگیری و درک هستند. این مزیت اصلی آن نسبت به سایر APIها است.
سریال سازی: REST با رویکرد و قالب های انعطاف پذیر برای سریال سازی داده ها در JSON ارائه می شود.
ذخیره سازی: REST API می تواند بار بالایی را با کمک سرور پراکسی HTTP و کش مدیریت کند.
درخواست پیچیده: API های REST یک نقطه پایانی جداگانه برای درخواست های مختلف دارند و این کمک می کند تا درخواست پیچیده نسبت به سایر API ها قابل مدیریت تر شود.
تمیز و ساده: API های REST ظریف، ساده و تمیز هستند. کاوش آنها ساده است.
رویه‌های استاندارد HTTP: رست از فراخوان‌های رویه HTTP استاندارد برای بازیابی داده‌ها و درخواست‌ها استفاده می‌کند.
کلاینت/سرور: این بدان معناست که منطق تجاری آن از ارائه جدا شده است. بنابراین می‌توانید یکی را بدون تأثیرگذاری بر دیگری تغییر دهید.
REST بدون حالت است: همه پیام‌هایی که بین کلاینت و سرور رد و بدل می‌شوند، تمام زمینه‌های لازم برای دانستن اینکه با پیام چه باید کرد را دارند.
معایب GraphQL
اکنون که در مورد جوانب مثبت GraphQL در مقابل REST صحبت کردیم، اجازه دهید برخی از معایب GraphQL را بررسی کنیم:
منحنی یادگیری دشوار: یادگیری GraphQL به آسانی REST نیست. چالش برانگیزترین بخش ساخت GraphQL API طراحی اسکیما است. این امر زمان و دانش دامنه زیادی را می طلبد.
آپلود فایل: GraphQL ویژگی بارگذاری فایل بومی ندارد. این را می توان با استفاده از رمزگذاری Base64 کار کرد، اما هزینه رمزگذاری و رمزگشایی از این طریق می تواند زمان بر و گران باشد.
ذخیره سازی وب: ذخیره سازی به کاهش ترافیک مکرر به سرور کمک می کند که با نگه داشتن اطلاعاتی که اغلب در دسترس هستند در نزدیکی سرور، سرعت درخواست ها و فرآیند پاسخگویی را افزایش می دهد. GraphQL از روش‌های کش HTTP پشتیبانی نمی‌کند یا به آنها تکیه نمی‌کند، در عوض به مکانیسم‌های ذخیره‌سازی کلاینت‌های Apollo یا Relay بستگی دارد.
نامناسب برای برنامه های کوچک: GraphQL ممکن است بهترین معماری API برای ساخت یک برنامه کوچک نباشد. اگر برنامه شما به جستارهای منعطف تری ارائه شده توسط GraphQL نیاز ندارد، REST راه حلی است.
مشکل پیچیده کوئری: توانایی GraphQL برای دادن دقیقا همان چیزی که به کلاینت می خواهد می تواند منجر به مشکلات انتشار کوئری شود. اگر یک کلاینت کوئری های تو در تو را بیش از حد ارسال کند، می تواند منجر به ارسال کوئری های اشتباه شود که می تواند برای سرور بسیار وقت گیر باشد. برای پاسخگویی به چنین درخواست‌هایی بهتر است از REST با نقاط پایانی سفارشی استفاده کنید.
معایب REST
اکنون، بیایید توجه خود را به برخی از اشکالات REST معطوف کنیم:
چند سفر رفت و برگشت: بزرگترین مشکل با REST API ماهیت نقاط پایانی متعدد است. این بدان معناست که برای اینکه کلاینت تمام منابع را برای یک برنامه کامل دریافت کند، باید رفت و آمدهای بیشماری را برای دریافت داده انجام دهد.
واکشی بیش از حد و کم واکشی: مشکل واکشی بیش از حد و کم واکشی یک اشکال بزرگ در RESTful APIS است. می تواند به دلیل واکشی بارهای ناخواسته بزرگ باعث تاخیر در پاسخ ها شود.
سلسله مراتب: از آنجایی که API های REST بر اساس منابع مرجع URI ساخته شده اند، برای منابعی که به طور طبیعی سازماندهی نشده اند یا در یک سلسله مراتب ساده به آنها دسترسی ندارند، مناسب نیستند.
چرا به جای REST از GraphQL استفاده کنیم؟
در ادامه، در مورد اینکه چرا ممکن است بخواهید GraphQL را برای توسعه API آینده خود به جای RESTful API در نظر بگیرید، بحث خواهیم کرد.
اسکیما قوی تایپ شده
GraphQL از یک سیستم نوع قوی برای تعریف قابلیت های API استفاده می کند. در GraphQL، زبان تعریف اسکیما (SDL) برای تعریف پارامترهای پیرامون نحوه دسترسی کلاینت به داده های سرور استفاده می شود. همه APIهایی که در معرض کلاینت قرار می گیرند در SDL نوشته می شوند و مشکل ناسازگاری داده ها را که در API های RESTful مشاهده می شود حل می کند.
بدون واکشی بیش از حد یا کم واکشی
مسئله واکشی بیش از حد یا کمتر از حد معمول یک مشکل شناخته شده در مورد API های RESTful است که در آن کلاینت ها اطلاعاتی بیشتر یا کمتر از آنچه درخواست کرده اند، دریافت می کنند. GraphQL این مشکل را با فراهم کردن رسانه ای برای کلاینت برای مشخص کردن اطلاعات مورد نیاز و سپس بازگرداندن دقیقا، و فقط آن اطلاعات خاص حل می کند.
چندین نقطه پایانی
یکی از بزرگترین مشکلات API های RESTful داشتن نقاط پایانی بیش از حد برای دسترسی به اطلاعات است.
فرض کنید می خواهید از طریق شماره شناسه کاربر خاصی به آن دسترسی داشته باشید. یک نقطه پایانی مانند users/1/ برای شما نمایش داده می شود. اما اگر می‌خواهید به عکس‌های آن کاربر دسترسی داشته باشید، باید درخواستی را به نقطه پایانی دیگری مانند users/1/photos/ ارسال کنید.
در GraphQL، شما یک نقطه پایانی دارید و برای بازیابی اطلاعات مختلف در مورد کاربر، نیازی به ارسال چندین درخواست ندارید.
خلاصه GraphQL در مقال REST
در نهایت، ما قصد داریم تفاوت عمده بین GraphQL و API های RESTful را بررسی کنیم. پس از آن، برخی از ویژگی‌های یک طراحی API خوب را مورد بحث قرار می‌دهیم و نحوه مدیریت هر فناوری با آنها را مقایسه می‌کنیم.
کارایی
شکی نیست که GraphQL سریعتر از API های RESTful عمل می کند زیرا توانایی آن در ارائه یک نقطه پایانی واحد برای دسترسی به همه منابع شماست. API های RESTful از چندین نقطه پایانی استفاده می کنند که می تواند منجر به تأخیر شبکه شود.
پیچیدگی کوئری
از آنجایی که نقاط پایانی به چندین نقطه پایانی جدا نمی شوند، کوئری های GraphQL می توانند در طول زمان پیچیده تر شوند. از سوی دیگر، نقاط پایانی RESTful API از هم جدا شده اند، که API های RESTful را به کوئری های ساده محدود می کند.
محبوبیت و حمایت جامعه
GraphQL یک الگوی معماری API و زبان کوئری در حال رشد است. اگرچه هنوز جوان است، اما میزان پذیرش و منابع آن به سرعت در حال رشد است، و منابع در حال حاضر برای کسانی که علاقه مند به یادگیری آن هستند، فراوان است.
از سوی دیگر، REST در حال حاضر از پشتیبانی گسترده جامعه برخوردار است و همچنان توسط شرکت‌هایی از انواع مختلف از آنهایی که میکروسرویس‌های کوچک می‌سازند تا برنامه‌های اجتماعی پیچیده و فراتر از آن، مورد استفاده قرار می‌گیرد.
در حال حاضر، مسابقه محبوبیت بین GraphQL در مقابل REST یک قرعه کشی است. هر دو فناوری همچنان به طور گسترده مورد استفاده قرار می گیرند و به خوبی توسط جامعه توسعه پشتیبانی می شوند.
منحنی یادگیری
منحنی یادگیری برای GraphQL شیب دار است. این نیاز به دانش خوب دامنه توسعه API و مهندسی نرم افزار عمومی دارد. یک مبتدی کاملاً برای درک GraphQL به اندازه کافی برای ساخت یک برنامه پیچیده زمان سختی خواهد داشت.
برعکس، REST برای شروع بسیار آسان است و به دانش کمتری از دامنه خارج از دروازه نیاز دارد. RESTful API به خوبی با اکثر زبان های برنامه نویسی اصلی و فریمورک های محبوب ادغام شده است که یادگیری آن را بسیار آسان می کند.
شباهت های GraphQL و REST چیست؟
هر دو GraphQL و REST سبک‌های معماری API محبوبی هستند که امکان تبادل داده بین سرویس‌ها یا برنامه‌های مختلف را در مدل کلاینت-سرور فراهم می‌کنند.
API ها دسترسی به داده ها و عملیات داده مانند زیر را تسهیل می کنند:
یک کلاینت یک درخواست API را به یک نقطه پایانی یا چندین نقطه پایانی در یک سرور ارسال می کند
سرور پاسخی می دهد که حاوی داده، وضعیت داده یا کدهای خطا است
REST و GraphQL به شما این امکان را می دهند که از طریق API داده ها را در یک برنامه، سرویس یا ماژول جداگانه ایجاد، اصلاح، به روز رسانی و حذف کنید. API های توسعه یافته با REST با نام RESTful API یا REST API شناخته می شوند. آنهایی که با GraphQL توسعه یافته اند به سادگی GraphQL API هستند.
تیم های Frontend و Backend از این معماری های API برای ایجاد برنامه های ماژولار و در دسترس استفاده می کنند. استفاده از معماری API به حفظ امنیت، ماژولار و مقیاس پذیر سیستم ها کمک می کند. همچنین باعث می شود سیستم ها کارایی بیشتری داشته باشند و ادغام آنها با سیستم های دیگر آسان تر شود.
در ادامه، برخی از شباهت های دیگر بین GraphQL و REST را مورد بحث قرار می دهیم.
معماری
هر دو REST و GraphQL چندین اصل معماری مشترک API را پیاده سازی می کنند. برای مثال، اصولی که آنها به اشتراک می گذارند در اینجا آمده است:
هر دو بدون حالت هستند، بنابراین سرور تاریخچه پاسخ را بین درخواست‌ها ذخیره نمی‌کند
هر دو از یک مدل کلاینت-سرور استفاده می کنند، بنابراین درخواست های یک کلاینت منجر به پاسخ از یک سرور می شود
هر دو مبتنی بر HTTP هستند، زیرا HTTP پروتکل ارتباطی اساسی است
طراحی مبتنی بر منابع
REST و GraphQL هر دو مبادله داده های خود را حول منابع طراحی می کنند. یک منبع به هر داده یا شی ای اشاره دارد که کلاینت می تواند از طریق API به آن دسترسی داشته باشد و آن را دستکاری کند. هر منبع دارای شناسه منحصر به فرد خود (URI) و مجموعه ای از عملیات (روش های HTTP) است که کلاینت می تواند روی آن انجام دهد.
به عنوان مثال، یک API رسانه اجتماعی را در نظر بگیرید که در آن کاربران پست ها را ایجاد و مدیریت می کنند. در یک API مبتنی بر منبع، یک پست یک منبع خواهد بود. این شناسه منحصر به فرد خود را دارد، به عنوان مثال، posts/1234/. و دارای مجموعه ای از عملیات، مانند GET برای بازیابی پست در REST یا کوئری برای بازیابی پست در GraphQL.
تبادل اطلاعات
هر دو REST و GraphQL از فرمت های داده مشابه پشتیبانی می کنند.
JSON محبوب ترین فرمت تبادل داده است که همه زبان ها، پلتفرم ها و سیستم ها آن را درک می کنند. سرور داده های JSON را به کلاینت برمی گرداند. فرمت های داده دیگری در دسترس هستند اما کمتر مورد استفاده قرار می گیرند، از جمله XML و HTML.
به طور مشابه، REST و GraphQL هر دو از کش پشتیبانی می کنند. بنابراین، کلاینت‌ها و سرورها می‌توانند داده‌هایی را که اغلب به آنها دسترسی دارند، ذخیره کنند تا سرعت ارتباط را افزایش دهند.
بی طرفی زبان و پایگاه داده
هر دو API GraphQL و REST با هر ساختار پایگاه داده و هر زبان برنامه نویسی، چه سمت کلاینت و چه سمت سرور، کار می کنند. این باعث می شود که آنها با هر برنامه ای بسیار سازگار باشند.
GraphQL تلاش می کند بر چه محدودیت های REST غلبه کند؟
GraphQL در سال 2012 به عنوان پاسخی به نیاز به سرعت در بسترهای رسانه های اجتماعی در حال ظهور ظهور کرد. توسعه‌دهندگان دریافتند که معماری‌های API موجود، مانند REST، برای تولید فیدهای خبری کارآمد بسیار طولانی و ساختار یافته هستند.
در ادامه، برخی از چالش‌های پیش روی آنها را مورد بحث قرار می‌دهیم.
تبادل داده با ساختار ثابت
REST API به درخواست های کلاینت نیاز دارد که از یک ساختار ثابت برای دریافت یک منبع پیروی کنند. استفاده از این ساختار سفت و سخت آسان است، اما همیشه کارآمدترین وسیله برای تبادل دقیقاً داده‌های مورد نیاز نیست.
بیش از حد واکشی و کم گرفتن
API های REST همیشه یک مجموعه داده کامل را برمی گرداند. به عنوان مثال، از یک شی شخص در REST API، نام، تاریخ تولد، آدرس و شماره تلفن شخص را دریافت خواهید کرد. حتی اگر فقط به شماره تلفن نیاز داشته باشید، همه این داده ها را دریافت خواهید کرد.
به طور مشابه، اگر می‌خواهید شماره تلفن و آخرین خرید شخصی را بدانید، به چندین درخواست REST API نیاز دارید. URL /person شماره تلفن را برمی گرداند و URL /purchase سابقه خرید را برمی گرداند.
توسعه دهندگان رسانه های اجتماعی مجبور بودند کدهای زیادی را فقط برای پردازش درخواست های API بنویسند که بر عملکرد و تجربه کاربر تأثیر می گذاشت.
GraphQL به عنوان یک راه حل مبتنی بر کوئری ظاهر شد. کوئری ها می توانند داده های دقیق را تنها در یک درخواست API و تبادل پاسخ برگردانند.
زمان استفاده از GraphQL در مقابل REST
می توانید از API های GraphQL و REST به جای یکدیگر استفاده کنید. با این حال، برخی از موارد استفاده وجود دارد که یکی یا دیگری مناسب تر است.
برای مثال، اگر این ملاحظات را داشته باشید، GraphQL احتمالاً انتخاب بهتری است:
شما پهنای باند محدودی دارید و می خواهید تعداد درخواست ها و پاسخ ها را به حداقل برسانید
شما چندین منبع داده دارید و می خواهید آنها را در یک نقطه پایانی ترکیب کنید
شما درخواست های کلاینت دارید که به طور قابل توجهی متفاوت است و انتظار پاسخ های بسیار متفاوتی دارید
از سوی دیگر، اگر این ملاحظات را داشته باشید، REST احتمالاً انتخاب بهتری است:
شما برنامه های کوچکتری با داده های پیچیده کمتر دارید
شما داده ها و عملیات هایی دارید که همه کلاینت ها به طور مشابه از آنها استفاده می کنند
شما هیچ الزامی برای کوئری داده های پیچیده ندارید
همچنین می‌توان یک اپلیکیشن واحد با هر دو API GraphQL و REST برای بخش‌های مختلف عملکرد ساخت.
نحوه استفاده از GraphQL و REST روی یک API یکسان
ارتقاء یک API RESTful به یک API GraphQL بدون انجام بازنویسی کامل امکان پذیر است.
در اینجا یک طرح کلی از روند است:
مدل داده RESTful API را درک کنید. برای انجام این کار، شکل داده ها را در هر منبع URL بررسی کنید.
اسکیمای GraphQL را از مدل داده بنویسید.
تعیین کنید که سرویس گیرندگان کدام عملیات را روی داده ها انجام می دهند و آنها را در اسکیما قرار دهید.
برای هر فیلد در طرح، یک تابع حل‌کننده در کد سمت سرور بسازید.
یک سرور GraphQL با حل کننده ها و اسکیما ایجاد کنید.
پس از این، کلاینت ها می توانند با استفاده از GraphQL یا REST با API شما ارتباط برقرار کنند.
نتیجه
GraphQL یک فناوری جدید است که الگوهای معماری RESTful API را دنبال می کند، همانطور که REST برای حل مشکلات الگوهای SOAP API معرفی شد.
GraphQL پاسخ‌های سریعتر، یک نقطه پایانی API واحد برای تمام کوئری های شما و یک طرح دقیق برای دسترسی به داده‌ها ارائه می‌دهد. این دلایل همان چیزی است که باعث شد شرکت‌های چند میلیارد دلاری حتی در مراحل اولیه به GraphQL روی بیاورند. با این حال، علی‌رغم محدودیت‌هایش، REST پیش‌ساز GraphQL همچنان به حضور قدرتمند خود در صحنه ادامه می‌دهد.
در این راهنما، ما همه چیزهایی را که باید در مورد GraphQL و API های RESTful بدانید، از جمله مزایا و معایب هر فناوری را بررسی کرده ایم تا به شما کمک کنیم با اطمینان تصمیم بگیرید کدام یک را ترجیح می دهید. همچنین درباره مشکلات شناخته شده با API های RESTful، مانند واکشی بیش از حد، کم واکشی و چندین نقطه پایانی، و اینکه چگونه GraphQL تلاش می کند این مشکلات را حل کند و عملکرد برنامه شما را افزایش دهد، بحث کرده ایم.
اکنون بینش کافی برای انتخاب مناسب بودن GraphQL در مقابل REST برای پروژه بعدی شما دارید.
