چرا مدیران فناوری اطلاعات باید GraphQL را در نظر بگیرند

بهره وری توسعه دهندگان را با یک سوپرگراف افزایش دهید تا به طور انعطاف پذیری خدمات متفاوت را ترکیب کنید و یک نمای پلت فرمی از میکروسرویس ها و منابع داده داخلی/خارجی ارائه دهید.

فناوری اطلاعات سازمانی مدت‌هاست که در میان انتخاب‌های زیرساختی متناقض بوده است و پیشرفت‌های اخیر مسلماً اوضاع را بدتر کرده است. برای مثال، Cloud قول داده بود که همه چیز را بهتر کند، اما ۱۰ سال سرمایه‌گذاری بومی ابری، با ایجاد انبوهی از ریزسرویس‌ها، APIها و دیگر «بهترین شیوه‌های بومی ابر»، اوضاع را پیچیده کرده است. برای کسانی که امیدوارند هوش مصنوعی بتواند همه اینها را به نحوی حل کند، خوب، من یک خبر بد برای شما دارم: هیچ فرد عاقل IT ChatGPT را به سیستم های CRM یا ERP متصل نمی کند، به دلیل عدم نظارت.

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

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

چیزی به نام جدید وجود ندارد

در فناوری اطلاعات سازمانی، عملاً هیچ کس تجمل ایجاد یک برنامه به اصطلاح “گرین فیلد” را ندارد. همانطور که جیمز گاورنر، تحلیلگر RedMonk می گوید، “در حالی که فناوری جدید وارد می شود، باید با و بر مهارت‌های موجود و پشته‌های فناوری موجود بسازید.» به همین دلیل است که Cobol با جاوا همزیستی با Rust دارد. یا اینکه چرا یک شرکت ممکن است در AWS “همه کار” باشد اما همچنان Azure زیادی را اجرا کند (به HP-UX، Windows NT و غیره و غیره اشاره نکنیم). تفریق بسیار کمی در فناوری اطلاعات سازمانی وجود دارد. تقریباً همیشه یک موضوع اضافه است.

GraphQL را وارد کنید.

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

وقتی یک ابرگراف را معرفی می‌کنیم، اوضاع بهتر می‌شود: یک شبکه یکپارچه یا لایه ترکیبی که به شرکت‌ها یک دید پلت فرمی از ریزسرویس‌ها، منابع داده داخلی و خارجی و غیره می‌دهد. در مصاحبه‌ای، DeBergalis این ابرگراف را به عنوان «یک لایه API قابل ترکیب توصیف می‌کند. که مانند یک سکو عمل می کند.» بچه‌های جالب فناوری اطلاعات مانند Netflix از استفاده کرده‌اند. این ابرگراف‌ها برای سال‌ها مزایای قابل‌توجهی را در این فرآیند آشکار می‌کنند. همانطور که وبلاگ فناوری نتفلیکس توضیح می دهد، این ابرگراف “بسیاری از چالش های سازگاری و سرعت توسعه را با حداقل معاوضه در ابعادی مانند مقیاس پذیری و عملکرد حل می کند.”

اما دیگر فقط بچه های باحال نیستند. براساس به Apollo GraphQL، حامی اصلی GraphQL، نیمی از Fortune 100 از GraphQL استفاده می کنند. همانطور که دبرگالیس در مصاحبه‌ای به آن می‌گوید، دلایل واضح است: «گراف نه تنها «کار درست» فنی برای توسعه اپلیکیشن است، بلکه یک استراتژی استراتژیک است که باید برای شرکت انجام شود» زیرا تا به حال، توسعه‌دهندگان مجبور بودند «دست‌نویسی گسترده را انجام دهند». از بی‌شماری backend-for-frontends یا APIهای تجربه.» جابه‌جایی به یک لایه API «ابرگراف» قابل ترکیب به توسعه‌دهندگان کمک می‌کند تا زیرساخت‌های سازمانی برای آنها کار کند، نه علیه آنها.

بله، حتی با زیرساخت‌های هوش مصنوعی مانند مدل‌های زبان بزرگ (LLM).

پیچیدگی کارها با هوش مصنوعی

همانطور که دبرگالیس اشاره می‌کند، پیشرفت‌های اخیر در هوش مصنوعی (genAI) باعث افزایش علاقه به فناوری‌های هوش مصنوعی در میان مهندسین نرم‌افزار و رهبران تجاری شده است. همه به این فکر می کنند که چگونه از هوش مصنوعی استفاده کنند، اما دقیقاً هیچ کس فکر نمی کند که اتصال مستقیم LLM ها به سیستم های سازمانی ایده خوبی باشد. ما راه‌های خوبی برای نصب نرده‌های محافظ نداریم تا اطمینان حاصل کنیم که LLM سهواً داده‌های سازمانی را افشا نمی‌کند. برای مثال، هنوز کسی مشکل تزریق سریع را حل نکرده است. تا زمانی که این کار را انجام ندهیم، شرکت ها به درستی در مورد اینکه چقدر به LLM ها اجازه می دهند به حساس ترین داده های خود دسترسی پیدا کنند، تردید دارند.

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

در اینجا هنوز چیزهای زیادی برای کشف کردن وجود دارد، اما ما به خوبی در حال انجام هستیم. خوشبختانه، توسعه‌دهندگان (و مدیران آرمانی پوش آن‌ها) نیازی به ریپ کردن و جایگزینی رویکرد API موجود خود برای یک ابرگراف مجهز به GraphQL ندارند. در واقع، DeBergalis و Apollo GraphQL از شرکت‌ها نمی‌خواهند که دهه‌ها سرمایه‌گذاری API خود را کنار بگذارند. دقیقا برعکس. آنها سعی می کنند این سرمایه گذاری ها را با ارزش تر کنند. دبرگالیس استدلال می کند: «در عمل، GraphQL به معنای لایه ای است که آن API ها را با ارزش تر می کند. “REST و GraphQL خیلی خوب با هم هماهنگ می شوند.”

بنابراین می‌توانم زیرساخت قدیمی HP-UX و مدل‌های Google Gemini یا Amazon Bedrock خود را داشته باشم که همه به روش‌های مفیدی به هم وصل شده باشند، با مدیریت همیشه بهبود یافته برای اطمینان از امنیت؟ به نظر می رسد همه پاسخ ها بله هستند.