Expedia Group کد منبع mockql-rs را منتشر کرد؛ ابزاری خط‌فرمانی نوشته‌شده با Rust که در زمان درخواست از مدل‌های زبان بزرگ (LLM) برای تولید پاسخ‌های موک در GraphQL استفاده می‌کند. این، سومین راهکار عمومی در شش ماه اخیر است که به مسئلهٔ تولید موک برای GraphQL می‌پردازد: پیش از این Airbnb دایرکتیو @generateMock را معرفی کرده و بنیاد GraphQL یک RFC پیشنهادی ارائه داده بود. هر سه راهکار خروجی‌ها و الزام‌های عملی متفاوتی دارند.

سه رویکرد و فرض مشترک

وجه مشترک همهٔ راهکارها این است که selection set خود نقش «الگوی ساختار» را ایفا می‌کند؛ مدل‌ها در خلق داده‌های جدید ضعیف اما در پر کردن یک ساختار از پیش‌معین‌شده عملکرد بهتری دارند. ساموئل وازکز از Expedia اشاره کرده که به‌جای نگهداری یک فایل JSON طولانی که با هر تغییر اسکیمای backend منسوخ می‌شود، می‌توان selection set را به مدل داد تا فقط محتوا را تولید کند.

عملکرد mockql-rs

mockql-rs به‌صورت یک فرایند مستقل بین کلاینت و سرور اجرا می‌شود. توسعه‌دهنده فیلدهایی را که resolver ندارند با @mock و یک hint اختیاری علامت‌گذاری می‌کند. سپس ابزار با استفاده از apollo-compiler عملیات را پارس و اعتبارسنجی می‌کند، فیلدهای واقعی را به upstream فوروارد می‌کند و فیلدهای حاشیه‌نویسی‌شده را با پرامپت به مدل می‌سپارد. در نهایت پاسخ واقعی و تولیدشده را ادغام می‌کند تا یک payload نهایی بازگرداند.

query TripDetails($id: ID!) {
  trip(id: $id) {
    property {
      name
      address
    }
    recommendations @mock(hint: "5 most popular nearby restaurants") {
      title
      description
      distance
    }
  }
}

در مثال Expedia، بخش property از بک‌اند پاسخ می‌گیرد و recommendations توسط مدل تولید می‌شوند؛ اما در payload هیچ متادیتایی وجود ندارد که نشان دهد کدام بخش تولیدشده و کدام زنده است. انتخاب اجرا به‌صورت CLI عمداً انجام شده تا هر تست‌رَنر، job در CI یا اسکریپت ساخت بتواند آن را بدون وابستگی به SDK اجرا کند.

نمونه خروجی mockql-rs با داده‌های تولیدشده و زنده

رویکرد Airbnb و RFC بنیاد GraphQL

Airbnb دایرکتیو @generateMock را در فرایند تولید کد (codegen) Niobe اجرا می‌کند و هم فایل‌های JSON موک و هم توابع تایپ‌شدهٔ دسترسی تولید می‌کند تا در اپ‌های دمو، تست‌های snapshot و تست‌های واحد استفاده شوند. ژنراتور Airbnb به‌طور عمدی تغییرات دستی مهندسان را بین اجراها حفظ می‌کند تا تکرارپذیری برقرار بماند.

RFC پیشنهادی بنیاد GraphQL دیدگاه متفاوتی ارائه می‌دهد: در این طرح @mock روی operation تعریف می‌شود نه روی فیلد و با آرگومان name بین پاسخ‌های نام‌دار سوئیچ می‌کند. موک‌ها باید در دایرکتوری __graphql_mocks__ کنار فایل منبع نگهداری شوند و یک کلید رزروشده __default__ وجود دارد. استفاده از LLM به‌عنوان یک استراتژی پیشنهادی ذکر شده، نه یک الزام اجرایی.

تناقض‌ها و پیامدهای عملی

  • مبهم‌بودن منبع داده: راهکار Expedia دادهٔ زنده و تولیدشده را در یک payload واحد بازمی‌گرداند بدون متادیتا برای تعیین منشا، که برای لاگ‌گذاری، آمارگیری و دیباگ مشکل‌ساز است.
  • تکرارپذیری در تست‌ها: خروجی‌های LLM در هر اجرا ممکن است متفاوت باشند؛ در حالی که رویکرد Airbnb و RFC روی تکرارپذیری و اعتبارسنجی موک‌ها تأکید دارند. تولید غیرقطعی می‌تواند اعتبار تست‌های snapshot را کاهش دهد و پایداری CI را به خطر اندازد.
  • دامنهٔ پیاده‌سازی و نگهداری: اجرای سادهٔ CLI پذیرش در pipelineها را تسهیل می‌کند، اما رویکرد codegen یا نگهداری فایل‌های موک در مخزن کنترل نسخه امکان بررسی دستی، مرور تغییرات و مدیریت آگاهانه‌تر را فراهم می‌سازد.

RFC همچنین پیش‌بینی کرده که عامل‌های کدنویس (coding agents) با یک Agent Skill بتوانند موک‌ها را مکالمه‌ای ویرایش یا اضافه کنند؛ سند پیشنهادی نمونهٔ فایل SKILL.md را برای یک فرایند قراردادی در repo ارائه می‌دهد.

معیارهای تصمیم‌گیری برای تیم‌ها

RFC در مرحلهٔ 0 و به‌عنوان یک طرح اولیه (strawman) مطرح است و پشتوانهٔ رسمی گسترده هنوز شکل نگرفته است؛ بنابراین مسیر استانداردسازی طولانی خواهد بود. تیم‌ها پیش از آزمایش این ابزارها باید اولویت‌های خود را مشخص کنند:

  • آیا تکرارپذیری و کنترل نسخه برای تست‌ها و CI اولویت دارد؟
  • آیا تولید زمینه‌ای و سریع با کمک مدل‌ها برای توسعهٔ سریع resolverها مهم‌تر است؟
  • چه مکانیزم‌هایی برای علامت‌گذاری منشا داده، اعتبارسنجی موک‌ها و تثبیت رفتار غیرقطعی مدل‌ها در pipeline نیاز است؟

پاسخ به این سوال‌ها تعیین خواهد کرد که آیا تولید موک‌ها با مدل را به‌صورت بخشی از فرایند توسعه می‌پذیرند یا رویکردهای سنتی‌تر را ترجیح می‌دهند.

منابع برای مطالعهٔ بیشتر

گام بعدی برای تیم‌ها مشخص‌کردن سیاست آزمایش، تصمیم‌گیری دربارهٔ نشانه‌گذاری منشا داده‌ها و تدوین راهکارهایی برای تضمین تکرارپذیری است. تا زمان نهایی‌شدن استانداردها، ترکیب راهکارها و ابزارها در پروژه‌ها مرسوم باقی خواهد ماند.