GraphQL چیست؟

توسعه‌دهندگان فرانتند که در جستجوی راهی برای کار با پایگاه‌های‌داده‌ی ‌‌بکند در سرور هستند، از GraphQL به دلیل قالب قدرتمند اما ساده‌اش برای بیان درخواست‌های پیچیده استفاده کرده‌اند. درحالیکه اغلب تصور می‌شود GraphQL کاملاً با پایگاه‌های‌داده‌ی گراف که برای ذخیره‌ی روابطی مثل شبکه‌های اجتماعی استفاده می‌شوند، مرتبط است اما این ارتباط بسیار بزرگتر شده است. نحو تقلیل‌یافته‌ سبب شده است که GraphQL به روشی محبوب برای واکشی تمام داده‌ها از جداول تبدیل شود.

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

وقتی پرس و جوها باید با ساختارهای داده‌‌ای کار کنند که چندلایه بوده و گاهی اوقات به هم پیوسته هستند، GraphQL نحوه‌ای که ما یک سؤال را فقط برای تولید پاسخ‌های درست می‌پرسیم ساده می‌کند.

مطلب پیشنهادی: دوره آموزش graphql در پایتون و جنگو

SQL و حرکت به سوی GraphQL

پایگا‌های داده‌ی سنتی بر اساس زبانی به نام SQL استوارند؛  SQLمخفف Structured Query Language و به معنای زبان پرس و جوی ساخت‌یافته است. درخواست‌های ساده خیلی راحت در SQL نوشته می‌شوند، اما مشکلات وقتی به وجود می‌آید که داده‌های جدولی ساختار بیش از حد دارند. رهیابی درخواست‌های پیچیده دشوار است و داده‌های برنامه‌ی شما مملو از فیلدهای تو در تو در بخش‌ها و زیربخش‌‌ها می‌شود. تلاش برای یافتن یک پرس و جوی خوب به منظور بازیابی زیرمجموعه‌ی مناسبی که دقیقاً جور باشد، مستلزم تفکر عمیق، آزمایش و تکرار است. توسعه‌دهندگان به جای کار روی برنامه، وقت خود را صرف سنجش زنجیره‌های پیچیده‌ی عملیات‌هایی می‌کنند که جداول را منطبق کرده و ادغام می‌کنند –و JOINS نامیده می‌شوند.  

GraphQL یک مکانیسم ساده‌ برای ارائه‌ی پرس و جوها به پایگاه داده است؛ و با یک نحو مدرن ساخته شده است، از این رو برای توسعه‌دهندگانی آشنا است که با مرورگرهای وب و پشته‌های سرور مانند Node.js کار می‌کنند که JavaScript را به کار می‌برند. این درخواست، تمام فیلدهای مورد نظر را فهرست کرده و محدودیت‌هایی برای مطابقت یا جستجو به فیلدهای خاص می‌افزاید. قالب این فهرست کم‌تراکم است، و بیانگر قالب محبوب ساختار داده‌‌ی JSON با فیلدهایی است که توسط براکت‌ کادربندی شده‌اند.

بسیاری از مدیران پایگاه داده از GraphQL استفاده می‌کنند چون باعث صرفه‌جویی در وقت توسعه‌دهندگان می‌شود و می‌تواند آنها را ترغیب به نوشتن پرس و جوهای دقیق‌تری کند که فقط داده‌های اساسی را بیابد و از این رو پهنای باند را ذخیره نماید.

GraphQL در اصل توسط فیس‌بوک برای یک پروژه‌ی داخلی ساخته شد و این شرکت به امید ایجاد یک استاندارد مشترک، اشتراک‌گذاری آن را آغاز کرد. این کار با موفقیت انجام شد و اکنون کاربران بسیاری برای درخواست‌هایی که کوچکترین شباهتی به وظایف اولیه ندارند، به آن تکیه می‌کنند.

اولین نسخه به سال 2012 برمی‌گردد، اما فیس‌بوک توضیحات و مشخصات زبان را تا سال 2015 منتشر نکرد. وقتی سایر شرکت‌ها استفاده از زبان پرس و جو را آغاز کردند، فیس‌بوک در سال 2018 یک بنیاد مجزا تأسیس کرد. سرویس‌گیرندگان خارجی با دسترسی API به مراکز داده‌ی فیس‌بوک باید از GraphQL برای جستجو استفاده کنند.

زبان پرس و جو نیز با آنچه که گاهی سبک Jamstack برنامه‌های Node.js در حال توسعه نامیده می‌شود، در یک ردیف قرار می‌گیرد. برخی از کتابخانه‌های بزرگ، مانند Gatsby، برای استخراج اطلاعات از پایگاه داده، از GraphQL به عنوان زبان میانجی خود استفاده می‌کنند. برنامه‌نویسانی که جذب این سبک توسعه می‌شوند به طور طبیعی این زبان را انتخاب می‌کنند.

مقاله پیشنهادی: سوالات حرفه‌ای مصاحبه پایتون

چرا GraphQL مفید است؟

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

در یک نمونه از دنیای سفرهای هوایی، ممکن است یک جدول زمانی با پروازها پر شود و هر پرواز با مسافران پر شود. هر مسافر نیز دارای ویژگی‌های فیزیکی خاص خود مانند قد یا وزن، و همچنین اولویت‌ها و نیازهای پزشکی است. یافتن فهرستی از تمام پروازها با مسافرانی که به صندلی چرخدار بسیار بزرگ نیاز دارند، در GraphQL تنها به چند کلمه نیاز دارد.

زبان پرس و جو از ساختارهای برنامه‌نویسی همچون متغیرها استفاده می‌کند. نتایج بیشتر شبیه کد JavaScript است، که استفاده از آن کمی راحت‌تر است.

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

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

افراد باقیمانده چطور با GraphQL برخورد می‌کنند؟

پایگاه‌های داده‌ی سنتی به زبان SQL صحبت می‌کنند، اما با افزودن لایه‌های نرم‌افزاری اضافی که GraphQL را به عبارات سنتی SQL تبدیل می‌کنند، از GraphQL استفاده می‌کنند. نتایج در JSON معمولاً توسط روال‌های بومی JSON قالب‌بندی می‌شوند که مدتی است بخشی از پایگاه‌های داده‌ی اصلی شده‌اند.

استارتاپی به نام Hasura، یک بسته‌ی منبع باز را توزیع می‌کند که GraphQL را برای پایگاه‌های‌داده PostgreSQL ترجمه می‌کند. این برنامه کاملاً یکپارچه است و با بسیاری از ویژگی‌های خاص PostgreSQL مانند پشتیبانی از GIS و کدگذاری جغرافیایی کار می‌کند. همچنین، این شرکت یک API ابری کاملاً مدیریت‌شده را برای کسانی اجرا می‌کند که می‌خواهند به جای یک محصول نرم‌افزاری، برای خدمات هزینه کنند.

Hasura نیز روی ادغام رابط کاربری خود با SQL Server مایکروسافت کار می‌کند. انتظار می‌رود این پروژه‌ی مشترک بین Hasura و Microsoft در اوایل سال 2021 انجام شود.

ابزارهای دیگر نیز همین نوع اتصال را ارائه می‌دهند. به عنوان مثال JoinMonster با تمام پایگاه‌های داده‌ی اصلی SQL از Oracle گرفته تا SQLite و همچنین چندین نسخه از MySQL کار می‌کند. JoinMonster با Node.js ادغام می‌شود و از طرح‌واره‌های پایگاه داده برای برنامه‌ریزی مجموعه‌ای از پرس و جوهای SQL متداول استفاده می‌کند که حجم داده‌ی مناسبی را واکشی خواهد کرد.

دسترسی به Oracle نیز با افزودن تجزیه‌کننده‌های‌23 GraphQL خارجی که PL/SQL تولید کرده تا داده‌ها را پیدا کند، در حال گسترش است. پایگاه داده Oracle اکنون از یک ویژگی استاندارد برای قالب‌بندی پاسخ‌ها در JSON برخوردار است.

تازه‌واردها

DGraph خود را "تنها پایگاه‌داده بومی GraphQL با یک بکند گراف" می‌نامد. DGraph یک ابزار منبع باز است که برای مقیاس‌بندی افقی حین تهیه‌ی کنترل تراکنش کامل برای جلوگیری از تناقضات طراحی شده است. این کد تحت ترکیبی از مجوز Apache و مجوز DGraph community منتشر شده است.

FaunaDB، یک پایگاه داده‌ی NoSQL است، که ابتدا از زبان پرس و جوی سبک رابطه‌ای خود به نام FQL استفاده می‌کرد. توسعه‌دهندگان آن نیز برای کسانی که از این استاندارد پیروی می‌کنند یک GraphQL API اضافه کردند.

Apollo نیز یک سرور GraphQL ارائه می‌دهد که می‌تواند داده‌ها را به صورت محلی ذخیره کند و با سایر سرویس‌ها نیز کار می‌کند تا تمام داده‌ها را برای پاسخ گردآوری کند. Apollo می‌تواند به عنوان یک گذرگاه به سوی دسته‌ا‌ی از سرورهای وابسته عمل کند، بنابراین رابط کاربری را برای توسعه‌دهندگان فرانتند ساده می‌کند. معماری این ابزار آنچه توسعه‌دهندگانش "تفكیك دغدغه‌ها" می‌نامند را تقویت می‌كند كه كار از طریق آن به سرویس‌ها و مخازن داده‌ی مجزا تقسیم می‌شود. همچنین، منجر به یک منبع داده‌ی انعطاف‌پذیرتر می‌شود، چون شکست در یک مورد ممکن است بر دیگری تأثیری نداشته باشد.

Amazon Web Services (AWS) نیز از GraphQL برای تعداد زیادی API استفاده می‌کند. به عنوان مثال، فریمورک Amplify برای مدیریت کار واکشی داده به شدت بر زبان تکیه می‌کند. سایر برنامه‌ها نیز می‌توانند GraphQL API را به یک منبع داده‌ی AWS اضافه کنند، مانند DynamoDB که از سرویس AppSync استفاده می‌کند.

آیا کاری هست که GraphQL نتواند انجام دهد؟

اگر طرح‌واره‌‌های پایگاه داده ساده باشند و پرس و جو تمام اطلاعات را از یک جدول بیرون بکشد، در پیچیدگی یک پرس و جوی SQL یا GraphQL تفاوت زیادی وجود ندارد. قالب پاسخ متداول برگرفته از پایگاه‌های داده SQL نیز گاهی کارآمدتر از JSON است. در این موارد، انتخاب یکی نسبت به دیگری مزیت آشکاری ندارد. توسعه‌دهندگان مدرن ممکن است نحو GraphQL را ترجیح دهند، اما این موضوع بسیار سلیقه‌ای است.

GraphQL زمانی نمود پیدا می‌کند که طرح‌واره شامل جداول هنجار‌شده‌ی بسیار زیاد باشد و پرس و جوها در چندین جدول گسترده شوند. درک انتخاب فیلدها و درج مقادیر پالایش ساده‌تر می‌شود چون نیاز نیست توسعه‌دهنده JOIN‌ها را مد نظر قرار دهد.

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