در دل GraphQL چه می‌گذرد؟

تاریخچه
اولین بار در سال 2012 میلادی، Facebook برای حل و رفع کردن نقص‌های برنامه‌های موبایلی خود از GraphQL کمک گرفت. کم کم آوازه‌ و شهرت آن در بین تمامی برنامه‌نویسان دنیا پیچید و همه خواستار دریافت GraphQL شدند. این قضیه تا جایی پیش رفت که در نهایت در سال 2015 نسخه open source آن به بازار ارائه شد و در اختیار برنامه‌نویسان قرار گرفت. از GraphQL، امروزه به عنوان یک معماری جدید برای API استفاده می‌شود.
و اما مهمترین سوال این مقاله:

دقیقا GraphQL چیست؟
این GraphQL، یک زبان query نویسی برای API است که به عنوان یک معماری برای API‌ها در نظر گرفته می‌شود. ارتباط میان فرانت‌اند و بک‌اند از طریق GraphQL انجام می‌شود. در واقع GraphQL، یکی از معماری‌های پیاده‌سازی Web API است.

حالا خود Web API چیه؟
دقیقا Web API همان API در بستر وب است. (بین یک سرور و اپلیکیشن یا دو سرور با هم) که اطلاعات از طریق پروتکل http بین آن‌ها رد و بدل می‌شود.
به صورت کلی ما 4 معماری پیاده‌سازی Web API داریم. REST،GraphQL، SOAP،RPC
دو معماری REST و GraphQL روش‌های قدرتمندی هستند که توانستند برنامه‌نویسان را بیشتر به سمت خود جذب کنند. از آنجایی که آینده برای هر دو این معماری‌ها امیدوارکننده است،
مهندسان Full Stack مخصوصا Backend کارها همواره در دو راهی انتخاب بین REST و GraphQL مردد هستند. در این مقاله قصد داریم تا بیشتر با ساختار و روند کاری و مزایا و معایب GraphQL آشنا شویم.

GraphQL چطور کار می‌کند؟
خب برای درک بهتر بذارید تصویری بریم جلو!

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

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

• این API توسعه داده شده با GraphQL انعطاف پذیری بالاتری خواهد داشت.
• استفاده از معماری GraphQL، از واکشی اضافی جلوگیری می‌کند. (یعنی چون نوع داده از قبل مشخص است، دیگر لازم نیست چندین درخواست ارسال شود).
• ساختار strongly typed (برای تمامی اشیا یک نوع داده‌ای وجود دارد و نمی‌شود یک شی را بدون مشخص کردن نوع داده‌ تعریف کرد).
  شاید بهتر باشد کمی بیشتر از بقیه موارد این ساختار را بشکافیم و توضیح دهیم. در واقع استفاده کردن از این ساختار مزایایی دارد که بسیار کاربردی یا به قول معروف دندان‌گیر است. از جمله این مزایا می‌توان به موارد زیر اشاره کرد.
  * قابل پیش‌بینی بودن کد * اعمال شرایط یکسان برای client و server * استقلال تیم‌های توسعه و پیشبرد همزمان آن‌ها * دیباگ سریع خطاها
• عدم وابستگی به ورژن API
  یکی دیگر از خوبی‌های GraphQL، عدم وابستگی آن به نوع و ورژن API است. یعنی API توسعه داده شده با GraphQL، بدون تغییر نسخه‌ و ورژن خاصی می‌تواند توسعه پیدا کند و این عالیه! چون این عدم وابستگی به ورژن باعث می‌شود چندین نفر بتوانند همزمان روی یک پروژه کار کنند.

معایب
خب از آنجایی که هیچ گلی بی‌خار نیست! باید معایب این معماری محبوب را هم بازگو کرد. تا در نهایت شما با یک حساب سرانگشتی محاسبه کنید و ببینید کدام نوع معماری برای شما مناسب است.

• در نهایت از آنجایی که در معماری GraphQL باید در سمت سرور نیز پکیج داشته باشیم، پیاده سازی GraphQL نسبت به سایر معماری‌های API کمی پیچیده‌تر است. در بالا گفتیم که کاربر باید نوع داده را مشخص کند و این کار باید به شکل دستی انجام شود! کاری که ریسک بالا بردن خطا را طبیعتا بالا می‌برد و ممکن است امنیت داده‌ها را به خطر بیندازد!
• در GraphQL برای درخواست دادن از queryها استفاده می‌شود و شما باید نحوه‌ی کار کردن با آن‌ها یاد داشته باشید. در غیر این صورت امکان دارد ساختار داده (Schema) مورد حملات Dos قرار بگیرد و این واقعا خطرناک است!
  یکی از تفاوت‌های مهم میان GraphQL و REST این است که GraphQL بر خلاف معماری رقیبش از cache پشتیبانی نمی‌کند! (که البته نگران نباشید چون برای این هم راه‌حلی وجود دارد. کمک گرفتن از relay)!

در نهایت

به صورت خلاصه GraphQL شرح کامل و قابل فهمی از همه‌ی داده‌ها و اطلاعات API را در اختیار ما قرار داده است و به مشتریان این قدرت را می‌دهد که دقیقاً آنچه را که نیاز دارند را درخواست کنند( مشخص کردن نوع داده توسط کاربر)، تکامل APIها را در طول زمان آسان‌تر می‌کند( وابسته به نوع ورژن نیست) و ابزارهای توسعه دهنده قدرتمند را فعال می‌کند.
به انتهای این مقاله رسیدیم و دوست داریم پس از خواندن این مطلب نظر شما را به عنوان یک توسعه‌دهنده بدانیم! شما بین این 4 دسته از انواع معماری API کدام را انتخاب می‌کنید و چرا؟
به رسم همیشگی، نظراتتان را می‌بینیم، می‌خوانیم و حتما پاسخ می‌دهیم.