Cloud توسعه را پیچیده می کند، اما GraphQL و supergraphs امیدوار کننده هستند

توسعه برنامه در فضای ابری یک آشفتگی پیچیده از قطعات متحرک بی‌شماری است. GraphQL و supergraphs می توانند زندگی را برای توسعه دهندگان بسیار آسان تر کنند.

ما در عصر طلایی محاسبات ابری زندگی می کنیم. برای مصرف کنندگان، این یک شگفتی است. برای توسعه دهندگان، این یک آشفتگی کامل و مطلق است.

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

برای GraphQL دعای شکرگزاری کنید.

GraphQL که توسط فیس بوک در سال ۲۰۱۵ منتشر شد، به عنوان یک زبان جستجوی انعطاف پذیر برای API ها عمل می کند. برخلاف SQL، که شما از آن برای پرس و جو از یک پایگاه داده رابطه ای استفاده می کنید، GraphQL به توسعه دهنده اجازه می دهد تا طیف گسترده ای از منابع داده را جستجو کند، جداسازی کلاینت (توسعه Front-end) از سرور (توسعه back-end). اما به همان اندازه که GraphQL جالب است، بدون ابرگراف ناقص است. همانطور که Apollo GraphQL CTO و یکی از بنیانگذاران Matt DeBergalis می نویسد، ابرگراف “یک شبکه یکپارچه از داده های یک شرکت، ریزسرویس ها، و قابلیت های دیجیتالی که به عنوان “لایه ترکیب” برای کل سازمان عمل می کند.”

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

ابرگرافها و افسانه های سبز

صبر کن، چی؟ مطمئناً یک استارت‌آپ یا یک توسعه‌دهنده انفرادی مجبور نیست با بدهی فنی به همان روشی برخورد کند که یک شرکت مستقر انجام می‌دهد و می‌تواند روی توسعه سبزه متمرکز شود؟ «بدهی فنی» می‌تواند یک اصطلاح پربار باشد، اما بیایید آن را همانطور که جیمز گاورنر، تحلیلگر RedMonk بیان کرد در مصاحبه اخیر:

چه یک توسعه‌دهنده فردی باشید [و] مهارت‌هایی را آموخته‌اید… و اکنون در تلاش هستید تا بر این مهارت برای یادگیری یک چارچوب جدید بسازید، یا اینکه یک شرکت کوچک هستید و زیرساخت‌های داده خاصی را ایجاد کرده‌اید. و سعی می کنید بفهمید چگونه می توانید تجزیه و تحلیل هایی را بر روی آن بسازید، یا اینکه آیا شما یک شرکت بزرگ هستید که در استخدام افراد با مشکل مواجه هستید و واقعاً می خواهید مهارت هایی را که قبلاً دارید، تقویت کنید، … ثابت این است که در حالی که فناوری جدید می آید در، باید با مهارت‌های موجود و پشته‌های فن‌آوری موجود همزیستی داشته باشد و بر اساس آن ایجاد شود.

اشمیت این را به سختی یاد گرفت.

اشمیت و دیبرگالیس Meteor را در اوایل دهه ۲۰۱۰ برای ارائه یک چارچوب جاوا اسکریپت سرتاسری تأسیس کردند. اشمیت گفت: «پلتفرم واقعاً جادویی برای ساخت برنامه‌های جدید». به نظر می رسید که توسعه دهندگان موافق بودند. در زمان خود، MeteorJS یکی از محبوب ترین پروژه ها در GitHub بود و جامعه سالم را به بیش از ۱۰۰ جلسه منظم جذب کرد. همانطور که اشمیت می گوید، مشکل این بود که Meteor از یک فرض بد شروع کرد. “زمانی که سعی کردیم Meteor را به شرکت وارد کنیم، Meteor برای توسعه Greenfield طراحی شده بود [اما] متوجه شدیم که هیچ چیز سبز در شرکت نیست.”

او ادامه می‌دهد: «ما در دنیایی زندگی می‌کنیم که در آن هر برنامه‌ای که می‌خواهید بسازید، از خدمات و منابع داده‌های مختلف زیادی استفاده می‌کند که از مکان‌های زیادی می‌آیند. این چیزی است که برنامه را با ارزش می کند. این همه چیزهای موجود در فضای ابری را به تجربه‌ای تبدیل می‌کند که می‌توانید داشته باشید.» مجدداً، چه یک توسعه‌دهنده انفرادی، چه یک استارت‌آپ کوچک یا یک غول فورچون ۵۰۰ باشید، به مجموعه وسیعی از خدمات خارج از فایروال خود وابسته هستید، و همه این خدمات توسعه را پیچیده می‌کنند.

در واقع، این کاملاً درست نیست. همانطور که اشمیت اشاره می کند، بینش کلیدی او و دبرگالیس این بود که این شرکت به راه بهتری برای اتصال فریم ورک های فرانت اند قدرتمند فزاینده (مانند MeteorJS یا React) به سرویس های پشتیبان قدرتمندتر اما پیچیده نیاز دارد. او به یاد می‌آورد: «با دیدن چقدر سخت بود که Meteor را وارد این شرکت کنیم، ما شروع به ساخت سیستم داده Meteor 2 کردیم که آپولو نام داشت و بر اساس همه درس‌های آموخته شده از [کمک به] شرکت‌ها بود… ساخت فناوری Meteor. کار در محیط های پیچیده سازمانی ناهمگن. آنها به یک زبان پرس و جو برای ابرگراف آپولو خود نیاز داشتند و GraphQL را انتخاب کردند.

همه اینها عالی است. اما چرا باید شما اهمیت دهید؟

Supercharging GraphQL

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

اما رسیدن به آن آینده ممکن است مشکل باشد.

حتی GraphQL، با تمام پتانسیل‌هایش، توسط بسیاری از توسعه‌دهندگان برای پیوند دادن سرویس‌های فردی استفاده شده است. چیزی که آپولو در تلاش است فرود بیاورد، همانطور که بود، یک نمودار از نمودارها است. استفاده از نمودارها برای گردآوری یک زیرساخت به طور فزاینده اتمیزه شده خوب است، اما افزودن یک متا گراف یا یک ابرگراف، پتانسیل بهبود چشمگیر زندگی توسعه دهندگان را دارد. چرا؟ اشمیت می‌گوید: «این ساده‌ترین راه برای استفاده از منابع داده‌ای متفاوت بدون نیاز به «ایجاد این ارتباطات عمیق، مستقیم و شکننده به یک پایگاه داده Oracle خاص یا یک میکروسرویس خاص، یا ایجاد یک نقطه پایانی کاملاً جدید REST است که کسی باید آن را حفظ کند». .

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

اشمیت می‌گوید: «رویکرد ابرگراف «نیازی به تغییر آبشار توقف در جهان ندارد». این به سازمان ها کمک می کند تا سیستم های قدیمی خود را به سیستم های جدیدتر خود متصل کنند. در مورد Walmart، به این معنی بود که یک توسعه‌دهنده جلویی می‌تواند بگوید: «بررسی‌های یک محصول را به من نشان بده» و آن‌ها این نظرات را هر کجا که بودند، از جمله مین فریم خود، پیدا می‌کردند. اگر بعداً آنها آن مین‌فریم را به معماری مبتنی بر میکروسرویس‌ها تغییر دهند، نیازی به تغییر در قسمت جلویی وجود نخواهد داشت.

انتخاب مشترک ابر

یک چیز جالب از همه اینها به دست می آید: ابرها لزوماً اوضاع را بهتر نمی کنند. به عنوان مثال، AWS AppSync را ارائه می دهد، یک راه عالی برای توسعه دهندگان برنامه تا داده ها را از DynamoDB بکشد و آن را در برنامه تلفن همراه خود قرار دهد. اما اگر می‌خواهید داده‌ها را از DynamoDB بیرون بکشید، برخی از عملکردهای بدون سرور Azure را پرتاب کنید، برخی از داده‌ها را در رایانه اصلی خود فراخوانی کنید، به علاوه به داده‌های یک یا دو سرویس Google Cloud دسترسی پیدا کنید، چه؟ کل وعده GraphQL و یک ابرگراف آپولو است که محیط های ناهمگن را رام کند و این ناهمگنی جدید شامل ابرهای مختلف است. برای هر ابر خاصی ارائه مسیریابی مرکزی مورد نیاز دشوار خواهد بود.

ما برای کمک به توسعه‌دهندگان به یک لایه توضیحی، انتزاعی یا ابرگراف نیاز داریم تا آشفتگی‌هایی را که IT سازمانی است رام کنند. برای مدتی خودمان را فریب دادیم که فکر می‌کردیم ابر مشکل را حل می‌کند. این کار را نکرد. این فقط فناوری اطلاعات سازمانی را گسترش داد و پیچیده تر کرد. افکار و دعاهایی که یک سوپرگراف می تواند کمک کند. فقط ممکن است.