مزایای توسعه GraphQL به سبک کدمحور چیست؟

مزایای توسعه GraphQL به سبک کدمحور (Benefits of Idiomatic Code-First GraphQL Development)

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

مروری بر GraphQL

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

دو رویکرد اصلی توسعه GraphQL

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

در مقابل، رویکرد کدمحور شامل تعریف API از طریق کد است. به جای نوشتن اسکیمای جداگانه، کد به‌طور طبیعی اسکیمای مورد نیاز را تولید می‌کند. اسکیمای تولید شده مستقیماً از ساختارهای کد مانند کلاس‌ها، توابع و انوتیشن‌ها استخراج می‌شود و کد خود به منبع حقیقت شکل و رفتار API تبدیل می‌شود.

مزایای رویکرد کدمحور نمونه‌ای

برای مثال، یک پرس‌وجوی ساده “Hello World” را در نظر بگیرید. در رویکرد اسکیمای‌محور، ابتدا فایل SDL ایجاد می‌شود و سپس تابع resolver در کد پیاده‌سازی می‌شود. این روش ممکن است منجر به خطاهای ظریف شود، مانند فراموش کردن اضافه کردن آرگومان مورد انتظار SDL.

در رویکرد کدمحور، تابعی در زبان برنامه‌نویسی انتخاب شده نوشته می‌شود که مستقیماً به یک فیلد GraphQL نگاشت می‌شود. تغییر در امضای تابع به‌طور خودکار اسکیمای متناظر را به‌روزرسانی می‌کند و ریسک ناسازگاری بین اسکیمای تعریف شده و resolver کاهش می‌یابد.

تفاوت رویکردها

هر دو رویکرد در نهایت منجر به تولید اسکیمای GraphQL می‌شوند. تفاوت اصلی در نحوه نویسندگی اسکیمای GraphQL است: در اسکیمای‌محور ابتدا اسکیمای دستی نوشته می‌شود و سپس منطق پیاده‌سازی می‌شود؛ در کدمحور ابتدا منطق نوشته می‌شود و اسکیمای متناظر توسط فریم‌ورک تولید می‌گردد.

ابزارهای کدمحور

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

ویژگی‌های اسکیمای GraphQL

اسکیمای GraphQL به شدت typed است. نوع‌ها، فیلدها، آرگومان‌ها، interfaceها، unionها و enumها همگی در اسکیمای تعریف شده ظاهر می‌شوند. برخی فیلدها غیرقابل-null هستند و با علامت تعجب مشخص می‌شوند. GraphQL از پلی‌مورفیسم و مستندسازی خودکار نیز پشتیبانی می‌کند. همچنین directives می‌توانند برای تغییر رفتار یا ارائه متادیتا استفاده شوند.

در رویکرد کدمحور، ویژگی‌ها باید به‌طور طبیعی با idiomهای زبان بیان شوند. برای مثال، با استفاده از Kotlin و کتابخانه GraphQL Kotlin، کلاس‌ها و توابع ساده تعریف می‌شوند و کتابخانه از reflection و annotation برای تولید اسکیمای متناظر استفاده می‌کند.

مثال کاربردی

تابعی که یک پرس‌وجو ایجاد می‌کند و آرگومان اختیاری “name” دریافت می‌کند و رشته‌ای برمی‌گرداند، به‌طور خودکار به فیلد GraphQL نگاشت می‌شود. اگر آرگومان حذف شود، از اسکیمای تولیدی نیز حذف می‌شود و تغییر نوع خروجی نیز اسکیمای متناظر را به‌روز می‌کند.

پیچیدگی‌های بیشتر

در مثال‌های پیچیده‌تر مانند API Star Wars، شخصیت‌ها می‌توانند به‌صورت interface پیاده‌سازی شوند و انواع فرعی مانند “Human” یا “Droid” آن‌ها را پیاده‌سازی کنند. فیلدهای هزینه‌بر می‌توانند به توابع تبدیل شوند تا به‌صورت lazy دریافت شوند و از ویژگی‌های زبان مانند coroutines برای بهینه‌سازی عملکرد استفاده شود.

مزایای تجربه توسعه‌دهنده

کد مورد استفاده قابل فهم است و اسکیمای GraphQL از همان کد استخراج می‌شود. نیازی به نگهداری فایل SDL جداگانه نیست، ریسک drift کاهش می‌یابد و خطاهای زمان اجرا کمتر می‌شوند. تست توابع resolver به‌صورت مستقیم انجام می‌شود و نیازی به راه‌اندازی سرور کامل GraphQL نیست.

ایمنی نوع و بررسی زمان کامپایل

در زبان‌های دارای type system مانند Kotlin یا TypeScript، اسکیمای GraphQL به‌عنوان توسعه طبیعی سیستم نوع زبان عمل می‌کند و بسیاری از خطاها در زمان کامپایل شناسایی می‌شوند. تغییر نوع فیلد باعث می‌شود که کد مصرف‌کننده نیز اصلاح شود و از بروز خطا جلوگیری شود.

مستندسازی خودکار

با استفاده از انوتیشن‌ها می‌توان توضیحات، directives و متادیتا را در کد نگهداری کرد و این اطلاعات در اسکیمای تولیدی نمایش داده می‌شوند. دیگر نیازی به مستندسازی جداگانه یا فایل‌های SDL نیست و همیشه مستندات به‌روز باقی می‌مانند.

انعطاف‌پذیری و یکپارچگی اسکیمای تولیدی

توسعه کدمحور همچنان از انعطاف‌پذیری GraphQL بهره می‌برد، امکان معرفی directives سفارشی، یکپارچگی با Apollo Federation و ارائه اسکیمای کامل برای introspection کلاینت‌ها فراهم است. اسکیمای تولیدی در زمان build، منبع حقیقت یکپارچه را ارائه می‌دهد و فرایند مقیاس‌پذیری آسان‌تر می‌شود.

نتیجه‌گیری

توسعه GraphQL به سبک کدمحور نمونه‌ای مزایای متعددی دارد:

• بهبود تجربه توسعه‌دهنده: نوشتن کد طبیعی و تولید اسکیمای خودکار

• منبع حقیقت واحد: کد تعریف کننده اسکیمای نهایی

• ایمنی نوع و بررسی زمان کامپایل

• تست ساده‌تر resolverها

• مستندسازی کامل و به‌روز

• اسکیمای کامل و سازگار

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