در دهه گذشته، REST تبدیل به یک استاندارد پرطرفدار برای طراحی API شده است. REST دارای ویژگی های عالی ای مانند stateless بودن و دسترسی ساختارمند می باشد. با این وجود، REST نشان داد که در برابر نیازهای جدید و تغییر یافته کلاینت هایی که به آن API دسترسی دارند، انعطاف پذیری کافی را ندارد.
اما GraphQL به منظور کارامدی و انعطاف پذیری بالاتر طراحی شده است. GraphQL بسیاری از کاستی ها و ناکارامدی های REST را برطرف کرده است.
اگر در مورد GraphQL آشنایی لازم را ندارید، این مقاله را بخوانید.
به منظور نشان دادن تفاوت های اصلی بین REST و GraphQL یک سناریوی ساده را در نظر می گیریم. فرض کنید یک وبلاگ داریم و نیاز داریم تا عناوین پست های منتشر شده توسط یک کار معین را دریافت کنیم. در همان صفحه، می خواهیم نام آخرین 3 نفری که فرد را فالو کرده اند، ببینیم. این مسائل چگونه با هر کدام از روش های REST یا GraphQL حل می شوند؟
دریافت دیتا توسط GraphQL و REST
با REST معمولا این مساله با صدا زدن چند endpoint حل می شود. در این مثال، مثلا اندپوینت users/id را صدا می زنیم تا اطلاعات اولیه در مورد کاربر را دریافت کنیم. سپس باید اندپوینتی شبیه به users/<id>/posts را صدا بزنیم تا تمامی پست های کاربر را دریافت کنیم. در نهایت، اندپوینتی شبیه به users/<id>/followers را صدا می زنیم که لیستی از فالوورهای کاربر را برمیگرداند:
همانطور که در تصویر بالا مشاهده می کنید، برای سناریوی ما، سه بار صدا زدن api مورد نیاز است. اما در GraphQL براحتی می توانید یک کوئری به سرور GraphQL ارسال کنید که نیازهای دیتایتان را بطور کامل در بر بگیرد. سپس سرور پاسخ را به شکل json به شما بازخواهد گرداند:
یکی از اصلی ترین مشکلاتی که REST دارد، رخ دادن overfetching و underfetching در زمان صدا زدن اندپوینت ها می باشد. چرا که تنها راه برای کلاینت بمنظور دانلود دیتا، صدا زدن endpoint هایی است که ساختار دیتای ثابتی برمیگردانند. طراحی api ای که بتواند دقیقا نیازهای کلاینت را برگرداند، کار بسیار سختی است.
به گراف فکر کنید، نه به اندپوینت ها
اما overfetching بدین معنی است که یک کلاینت مجبور است اطلاعات بیشتر از نیاز اپ را دانلود کند. برای مثال یک صفحه را در تصور کنید که نیاز به نمایش لیستی از تنها نام کاربران دارد. در یک REST API، اپ معمولا اندپوینت users را صدا می زند و یک آرایه جیسون همراه با دیتای یوزرها بازمیگرداند. این پاسخ ممکن است دیتای اضافه ای برای هر کاربر را نیز بازگرداند. مثلا آدرس و نام خانوادگی آنها را در حالی که نیازی به آنها نیست.
مشکل دیگر underfetching است. این مشکل به معنای این است که یک endpoint اطلاعات مورد نیاز و کافی را ممکن است به شما بازنگرداند. در این حالت کلاینت مجبور است تا request های دیگری را هم بدهد تا تمام دیتای مورد نظرش را دریافت کند. مثلا فرض کنید یک کلاینت مجبور است در ابتدا لیستی از المنت ها را دریافت کند و سپس برای هر کدام از آیتم های لیست، request جداگانه ای بزند تا دیتاهای دیگر را در مورد آن دریافت کند.
حلقه های پرسرعت توسعه اپ در فرانت اند
یک الگوی متداول با REST، ساختار بخشی به اندپوینت ها بر اساس ویو هایی است که باید در اپ تان داشته باشید. این روش، مناسب است چرا که به کلاینت اجازه می دهد تمامی اطلاعات مورد نیاز برای یک ویو خاص را با صدا زدن اندپوینت مدنظر دریافت کند.
اصلی ترین نقص این رویکرد، این است که حلقه ساخت پرسرعت برای فرانت را غیر ممکن می کند. با هر تغییری که در UI حاصل می شود، این ریسک وجود دارد که اکنون دیتای کمتر یا بیشتری نیاز است. پس بک اند نیاز دارد تا اندپوینت مورد نظر را با توجه به UI جدید، تغییر دهد. این امر، بهره وری را کاهش میدهد و سرعت توسعه را پایین میاورد.
با GraphQL این مشکل مرتفع شده است. با تشکر از طبیعت منعطف GraphQL، تغییرات در سمت کلاینت می تواند بدون کار اضافی از سمت سرور انجام شود. چرا که کلاینت ها می توانند دیتایی را که نیاز دارند مشخص کنند و به توسعه دهنده بک اند نیاز نیست تا بر مبنای تغییرات دیزاین، تغییراتی روی کد های بک اند انجام دهد.
آمارهای مفید در سمت بک اند
گرف کیو ال این امکان را در اختیار شما می گذارد تا به آمار و بینشی مناسب از دیتاهای درخواست شده در بک اند دست یابید. چون هر کلاینت مشخص می کند که دقیقا به چه اطلاعاتی نیاز دارد و علاقمند هست، دستیابی به فهم چگونگی استفاده از دیتا امکان پذیر است. مثلا می توانید به کمک api های صدا زده شده، فیلد های بلااستفاده را شناسایی کنید.
با GraphQL، همچنین می توانید مانیتورینگ سطح پایین را برای request ها انجام دهید. GraphQL از مفهوم resolver function ها به منظور جمع آوری دیتای درخواست شده توسط کلاینت استفاده می کند.
منافع سیستم Type و Schema
در GraphQL از یک سیستم قدرتمند type به منظور تعریف قابلیت های api استفاده می شود. تمامی type های اعلان شده در یک API در یک schema توسط زبان GraphQL Schema Definition (SDL) تعریف می شود.این schema بعنوان یک قرارداد بین کلاینت و سرور بمنظور تعیین چگونگی دسترسی کلاینت به دیتا خدمت می کند.
بمحض اینکه schema تعریف شد، تیم هایی که روی بک اند یا فرانت اند کار می کنند می توانند کارشان را بدون برقراری ارتباط های بعدی بینشان انجام دهند چرا که هر دوی آنها ساختار تعریف شده دیتای ارسالی توسط سرور را می دانند.
تیم های فرانت اند براحتی می توانند اپ هایشان را با ساختارهای دیتای تستی (mock) تست کنند. بمحض اینکه سرور آماده شد، تغییر به production برای اپ های کلاینت بدون دردسر و براحتی انجام می شود.
