GraphQL برای طراحی API، استایلی جدید عرضه می کند که برای کاربران API، دسترسی واحد به سرویس ها و داده های backend را فراهم می کند.
علیرغم هدف کلی، GraphQL باعث ایجاد اختلاف و دودستگی در انجمن های API بین کسانی شده است که به برتری طراحی RESTful API اعتقاد دارند و کسانی که معتقدند GraphQL تنها به طور ساده به بازنویسی مسائل حل شده طراحی API می پردازد.
باید فهمید چرا عده ای نسبت به GraphQL انقدر حساس هستند.
ظهور GraphQL
پست مهندسی فیسبوک که طی آن open-source بودن GraphQL اعلام شد، جرقه ای برای شروع درگیری های احساسی بود. در این پست، Lee Byron ناامیدی خود را از نیاز به ایجاد چندین درخواست backend به موجب کنوانسیون های REST فیسبوک ابراز کرد.
اولین موج بلاگ پست های GraphQL راجع به برتری آن نسبت به REST است و در خصوص آشفتگی ناشی از چندین درخواست است که به خاطر عدم انعطاف پذیری REST ایجاد می شود.
تاکنون REST سبک معماری غالب برای web API ها بوده، بحث و مناظره ای در انجمن های API در خصوص آنچه که REST را تشکیل داده، شکل گرفته است.
رایج ترین شیوه پیاده سازی که متدهای HTTP را به منابع URL-defined متصل می کند، امکان پرس و جو و دستکاری ساده داده ها را می دهد.
اگرچه، این شیوه “pragmatic REST” نتوانست تمامی مجموعه محدودیت های توصیف شده در تز دکتری Roy Fielding، که REST اولین بار آنجا تعریف شد، به خصوص محدودیت hypermedia، را اجرا کند.
انجمن متخصصان API که REST را بهتر می شناسند، سریع به مسائل رویکرد “pragmatic” اشاره کردند. به خصوص، ایجاد پیوند قوی بین مصرف کنندگان و تأمین کنندگان، محدود کردن وسعت و حیطه وظایفی که توسط یک API call کامل می شود، و مانع شدن از تحول کلی API.
با وجود این هشدارها، اجرا کنندگان API، هنگامی که مصرف کنندگان با مسائل منتج شده سروکار دارند، REST API عملی و واقعی را کشف می کنند.
انجمن API بی قرار می شوند
هنگامی که GraphQL همراه با وعده رهاسازی مصرف کنندگان API از طریق پروتکل جدید مطرح شد، متخصصان REST API به دو دلیل برافروخته شدند. اول آنکه، آن ها احساس می کردند شما برای رفع ایرادات مسائل پیش آمده با REST API عملی به پروتکل جدید نیاز ندارید، شما تنها به REST صحیح نیاز دارید. دوم آنکه، آن ها باور دارند که پروتکل جدید مسائل خود را دارد. مدل مبتنی بر الگوی GraphQL پیوند قوی بین مصرف کنندگان و تأمین کنندگان را انسجام می بخشد.
درخواست های نامحدود می تواند منجر به حجم کاری غیرقابل پیش بینی Backend شود. امنیت یک مسئله بود. و وعدۀ “داده ها را از هر منبعی از طریق یک interface واحد بگیرید” بسیار شبیه رویکرد ESB بود که از توجه و طرفداری لازم به دلایلی برخوردار نبود.
از زمان انتشار GraphQL، بسیاری از شرکت ها تصمیم گرفته اند که از آن برای API شان استفاده کنند.
کارهای بزرگی به واسطه متخصصان API، مانند Phil Sturgeon، Zdenek Nemec و James Higginbotham انجام شده است که به تجزیه کردن حیطه و وسعت post-GrephQL API کمک می کند.
اگرچه، با وجود انتشار زیاد پست هایی نظیر “GraphQL فوق العاده است” و “REST بهترین است”، اختلافات و تعارضات دو کمپین ادامه دارد.
من معتقدم که دودستگی به دلیل اصرار و پافشاری احساسی ادامه یافته است و هیچ وقت درباره GraphQL در برابر REST نبود. همچنین باور دارم که بهترین راه کم کردن احساسات و بالا بردن منطق، یکی کردن درک و برداشت بین طرفداران GraphQL و متخصصان REST است. توصیه من به هر دو گروه به قرار زیر است:
به متخصصان REST:
به جای عجله در قضاوت، دانش خود را افزایش دهید. نام GraphQL گمراه کننده است. بیشتر از آنچه شما فکر کنید، سناریو API تحت پوشش و قابل پشتیبانی هستند.
بدانید GraphQL از کجا آمده. شهرت آن به موجب برنامه نویسان front-end ای است که به سمت استفاده از framework هایی تمایل دارند که پشتیبانی native GraphQL را در برمی گیرد و از framework هایی (مانند Ruby on Rails) که pragmatic REST را ترغیب و ترویج می کنند، فاصله می گیرند. با دانستن این موضوع، شهرت و محبوبیت قابل درک است.
به این موضوع فکر کنید که فراتر از پروتکل، چه چیزی پیش زمینه اتخاذ GraphQL است. آنچه که GraphQL را برای مشتریان برنامه نویس جذاب کرده، تجهیز و ابزار بی نقص آن است. انطباق پذیران مشهور مانند Facebook، Github و Netflix این اعتماد و اطمینان را ایجاد می کنند.
آن زمانی را به خاطر آورید که هنگام لزوم اجرای پروتکل API، همین طغیان را نسبت به SOAP داشتید.
به مدافعان و طرفداران GraphQL:
فضای گسترده تر API را بشناسید. REST را فراتر از شیوه های CRUD که با آن سروکار داشتید، بیاموزید. خصوصاً با نگرانی هایی که معماران باتجربه API درباره GraphQL دارند، آشنا شوید.
اطمینان حاصل کنید که می دانید کدام مزایا ناشی از پروتکل GraphQL است، کدام ناشی از topology (دروازه ای که داده ها را از چندین منبع جمع آوری می کند) و کدام حاصل از ابزار است. طبق گفته Phil Calcado، می توانید تعدادی از این مزایا را بدون استفاده از GraphQL کسب کنید.
به همه گیر بودن REST احترام بگذارید. این حقیقت که REST ممکن است در جاهایی استفاده شود که بدان منظور نبوده، شاهدی بر قابلیت استفاده و اثبات کاربردی بودن آن است. علاوه بر آن، بیشتر از 15 سال استفاده گسترده باعث ایجاد اکوسیستم عظیمی از ابزارها، پشتیبانی زبان، فرمت های خاص، رویکردهای امنیتی (مانند OAuth)، پیاده سازی منابع و دیگر دستاوردها شده است. حتی اگر دلیلی برای انتخاب REST وجود ندارد، می توان از آن برای کم کردن تلاش های مورد نیاز برای ساخت اکوسیستم GraphQL قوی استفاده کرد.
به هر دو گروه:
به یک پروتکل وابسته و متعهد نشوید. API هایی که به بهترین نحو ممکن طراحی شده اند بین رابط semantic و syntax شان تفکیک وجود دارد. از دید مصرف کنندگان، پشتیبانی از چندین پروتکل برای یک API واحد ایده آل است. قادر به اضافه کردن سریع پشتیبانی برای پروتکل های جدید هم حائز اهمیت است.
حقیقت این است که با ادامه رشد API ها، هر کسی درباره پروتکل ها، شیوه ها و الگوها به توافق نمی رسد. اما به جای گسیختن اصول قدیم، باید از همدیگر بیاموزیم و ببینیم می توانیم با هم تکامل یابیم.