🚀 مقدمه‌ای بر GraphQL (بخش اول)

🚀 مقدمه‌ای بر GraphQL (بخش اول)

1.اصلا GraphQL چیه؟

به زبان ساده، GraphQL مکانیزمیه تا بتونیم با یک استاندارد مشخص، کوئری‌مون رو به «یک» API ارسال کنیم و داده‌ها رو دریافت. یعنی بابت هر داده‌ای که نیاز داریم دریافت کنیم سراغ یک REST API جداگانه نریم. بلکه فارغ از اینکه داده‌هامون یک جا هستن یا از منابع مختلفی تأمین می‌شن، صرفا می‌گیم «چی می‌خوایم با چه شرایطی» (مثلا تمام دانش‌آموزهای ۱۰ تا ۱۵ ساله که معدل بین ۱۷ تا ۱۹ داشتن) و بعد این کوئری رو ارسال می‌کنیم و پاسخمون رو می‌گیریم. و این عملا یک لایه‌ی واسط روی داده‌ها (متمرکز یا حتی توزیع‌شده + یک منبع داده یا چند منبع داده) به ما می‌ده که می‌تونه نیازهای توسعه‌دهنده‌های خودمون یا مشتریانمون رو برآورده کنه.

اینکه کاربر صرفا می‌گه چی‌ می‌خوام رو اصطلاحا "declarative data fetching" می‌گیم.

پیدایشش هم به سال ۲۰۱۲ برمی‌گرده که Lee Byron, Nick Schrock و Dan Schafer برای حل گرفتن دیتا برای اپلیکیشن‌های موبایل، توی فیس‌بوک دست به خلق GraphQL زدند، و بعدتر در سال ۲۰۱۵ به‌صورت کدباز عرضه‌اش کردند. به صورت سنتی مشکلات زیر در رابطه با REST API وجود داشت که منجر به پیدایش GraphQL شد، مثل:

- مشکل Over-fetching (دریافت داده‌هایی بیش از دیتای مورد نیاز، مثلا: ما ۳ تا فیلد رو نیاز داریم ولی API ما ۱۰ تا فیلد رو برمی‌گردونه، که این توی مقیاس بزرگ می‌تونه منجر به هدررفت منابع پردازشی و ارتباطی بشه)

- مشکل Under-fetching (دریافت داده‌هایی کمتر از اونچه نیاز داریم که منجر به درخواست‌های متعدد برای تکمیل داده‌های مورد نیاز است، مثلا: چند API رو صدا کنیم و داده‌های همه رو با هم ترکیب کنیم تا اونچه نیاز داریم رو از دلشون در بیاریم)

- انعطاف‌‌پذیری کم endpointها نسبت به نیازهای سمت front

✨ حالا چه مشکلاتی رو قراره برطرف کنه؟

- واکشی به‌اندازه و دقیق داده‌ها (هر دیتایی با هر شرط و فیلتری و هر ساختاری رو بتونیم واکشی کنیم)

- انعطاف پذیری API از منظر طراحی (پشتیبانی از طیف وسیعی از امکانات)

- یک endpoint برای چندین منبع داده (در مقابل شرایطی که برای هر سرویس یا منبع داده، یک گروه REST API ارائه می‌کنیم)

- ساختار strong typing

✨ مناسب برای…

- نرم‌افزارهای پیچیده و داده‌محور (دیتامدل‌های پیچیده، منابع داده متعدد «با تعریف استاندارد!! نه دلخواه مدیرعامل شرکت که حتی نرم‌افزار دفترتلفن رو توی لینکدینش پیچیده‌ترین نرم‌افزار جهان معرفی می‌کنه 😂😉)

- معماری میکروسرویس (خصوصا توی سازمان‌های بزرگ با دامین‌های کاری متعدد)

- نرم‌افزارهای موبایل و فرانت‌اند با نیازهای داده‌ایِ پویا (دست فرانت‌اند دولوپر رو باز می‌گذاره تا هر چی خواست سریع توسعه بده)

✨ محدودیت‌هاش:

- افزایش پیچیدگی برای APIهای ساده (دقت کنیم کجا مناسبه برای استفاده از GraphQL)

- سربار پرادزشی بالقوه برای کوئری‌های پیچیده (نمیشه روی همه کوئری‌ها، همه حالت‌ها ایندکس گذاشت، کاربر می‌تونه یه کوئری بفرسته که باعث کُندی سیستم بشه!)

- راه‌اندازی اولیه نسبتا سنگین و زمان‌بری داره

- منحنی یادگیری برای تیم‌هایی که REST بلد هستن و دیدگاه REST API Design دارن کمی زمان‌بر و نیاز به تغییر دیدگاه داره

✨ چالش‌های بالقوه:

- مدیریت عمق و پیچیدگی کوئری‌ها نیاز به تحقیق و دقت زیادی داره

- مکانیسم caching پیچیده‌تر از REST است (گاهی خیلی پیچیده‌تر)

- مستعد مصرف منابع پردازشی زیاد

- ملاحظات امنیتی (پیچیدگی کوئری‌ها، محدودیت نرخ درخواست، امنیت در سطح داده و خصوصا لایه‌های دوم به بعد..)

===================

🌱🙏 یک درخواست: تلاش من برای ارائه مطالبیه که بتونه مفیدتر باشه، لذا فیدبک شما می‌تونه به من برای انتخاب «موضوع» و «عمق پرداختن به موضوع» خیلی کمک کنه. لذا یک قرارداد رو با هم بگذاریم، اگر دوست داشتید یک موضوع رو عمیق‌تر بررسی کنیم، لطفا با ری‌اکشن و ایموجی 🤓 به من بگید بگید لطفا، و اگر تعداد این ایموجی بالا رفت من متوجه خواهم شد که موضوع مورد علاقه بوده و باید با مثال و کد و توضیح بیشتر ادامه‌اش بدم.

===================