مدیریت GraphQL در مقیاس – DevOps.com

[ad_1]

GraphQL، زبان پرس و جو که توسط فیس بوک اختراع شده است، به عنوان وسیله ای برای دسترسی آسان به داده ها به صورت برنامه نویسی، توجه زیادی را به خود جلب کرده است. GraphQL سرویس‌های داخلی را با طرحی یکپارچه برای داده‌ها ساختار می‌دهد و به مهندسان محصول این امکان را می‌دهد تا به راحتی آنچه را که از بسیاری از ریزسرویس‌ها می‌خواهند برای پر کردن رابط‌های کاربری (UI) که ایجاد می‌کنند، بگیرند. با متحد کردن داده های شرکت در یک نمودار واحد، GraphQL مزایای SQL را با دسترسی فراگیر به API ترکیب می کند.

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

همانطور که استفاده از GraphQL در سازمان‌های بزرگ رشد می‌کند، تیم‌های توسعه باید بر این موانع غلبه کنند – به‌ویژه اگر شرکت‌ها قصد تولید APIهای عمومی و استفاده مجدد از همان نمودار واحد را در سراسر شرکت داشته باشند. من اخیراً با DeBergalis برای به روز رسانی در مورد مدیریت GraphQL در مقیاس ملاقات کردم. به گفته DeBargalis، ما هنوز در روزهای اولیه انقلاب گراف هستیم. و بلوغ GraphQL در آینده به معماری اعلانی مبتنی بر قوانین، بهبود کارایی و سازگاری برای اجرای تکرار چابک طرحواره‌های گراف نیاز دارد.

وضعیت پذیرش GraphQL

بنابراین، چه چیزی باعث افزایش GraphQL می شود؟ خوب، دبارگالیس به سه عامل اصلی کمک کرد:

  1. بسیاری از میکروسرویس ها. در سال های اخیر، انفجاری از میکروسرویس ها رخ داده است. این خدمات ماژولار می تواند چالش برانگیز باشد و اغلب به طور متناقض در سراسر یک اکوسیستم نرم افزاری در معرض دید قرار می گیرند.
  2. ظهور پلتفرم های همه کانال. مهندسان محصول اکنون باید همان داده‌ها را در دستگاه‌های متفاوت، چه در مرورگر و چه در صفحه Peleton، انتقال دهند.
  3. کاربران انتظار یک تجربه سنگین و غنی از داده را دارند. انتظارات در حد یک اوج تمام دوران. اکنون انتظار می رود که یک فروشگاه تجارت الکترونیک، برای مثال، شامل توصیه های محصول، جستجوی کلمه کلیدی تکمیل خودکار، قیمت گذاری بر اساس جغرافیا و بسیاری از ویژگی های پیشرفته دیگر باشد.

دبارگالیس توضیح داد که دستکاری همه این عوامل یک “گلوگاه پیچیدگی” ایجاد می کند.

GraphQL به چنین پیچیدگی پاسخ می دهد و به یکپارچه سازی backend کمک می کند تا توسعه دهندگان محصول بتوانند دقیقاً آنچه را که برنامه های مشتری نیاز دارند واکشی کنند. دیبرگالیس افزود، پذیرش GraphQL بسیار سریع، به ویژه در میان تیم های مهندسی محصول، آغاز شد. GaphQL به خوبی با زبان ها و چارچوب های آشنا مانند جاوا اسکریپت، React و Relay بازی می کند. همچنین کمی متفاوت از روندهای قبلی است، زیرا تقاضا بیشتر توسط افراد پایگاه داده هدایت می شود. او گفت: «افراد پرس و جو واقعاً این اتهام را هدایت می کنند.

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

با توجه به سبک های معماری برای API ها، 94٪ هنوز از REST و 31٪ از GraphQL استفاده می کنند. گزارش وضعیت API 2021 از پستچی اگرچه این درصد ممکن است در حال حاضر کم به نظر برسد، پذیرش GraphQL به طور پیوسته در میان شرکت های بزرگ، مانند پی پال، نتفلیکس، Shopify، GitHub و Airbnb.

سه مشکل در مقیاس بندی GraphQL

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

دبارگالیس گفت: «به دلیل تأثیر شبکه، یک نمودار با انتشار بیشتر در آن جالب تر می شود. آنچه ما دریافتیم این است که GraphQL در مقیاس بسیار جالب و ارزشمند است. بنابراین، برخی از پیامدهای اجتناب ناپذیر GraphQL در مقیاس چیست؟ دبارگالیس سه موضوع اصلی معماری را بیان می کند.

کارایی

نقاط ضعف عملکرد یکی از معایبی است که توسعه دهندگان اغلب هنگام در نظر گرفتن GraphQL به آن اشاره می کنند. GraphQL فاقد ویژگی های کش داخلی است، و پرس و جو بار می تواند تاخیرهای اضافی را ایجاد کند. DeBargalis گفت که کاهش مسائل سطح پایین تر در مورد توان عملیاتی و قابلیت اطمینان احتمالاً نیازمند ابزارهای اضافی از سوی جامعه است. تا حدودی به همین دلیل است که تیم آپولو شروع به پذیرش Rust در کرده است تلاش های جدید برای ایجاد زیرساخت برای مسیریابی GraphQL بسیار کارآمد.

تغییر پذیری

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

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

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

دبارگالیس همچنین توضیح داد که چگونه مشاهده پذیری برای به دست آوردن تصویر واضحی از محیط های نمودار مهم است. این یکی از زمینه‌هایی است که GraphQL در آن می‌درخشد—از آنجایی که مشتریان دقیقاً آنچه را که نیاز دارند درخواست می‌کنند، شما هرگز نمی‌پرسید که کدام روش‌ها واکشی شده‌اند اما در تولید پیاده‌سازی نمی‌شوند، همانطور که ممکن است با مدیریت REST API اتفاق بیفتد. به گفته DeBargalis، ردیابی استفاده دقیق از GraphQL با KPIها می تواند به نحوه تکامل مدل داده در طول زمان کمک کند.

مجوز

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

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

حفاظت از GraphQL به یک تنظیم اعلامی نیاز دارد که کنترل مجوز و زمینه را در جستارهای GraphQL ادغام کند. برای اجرای این امر، دبارگالیس از سبک فرمان و کنترل دفاع کرد. ابتدا، شما طرح را حول بیانیه داده و مشکل می سازید. در مرحله بعد، قوانین را میدان به میدان ادغام می کنید و نقاط تماس حساس را به عنوان PII علامت گذاری می کنید.

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

آینده مقیاس پذیری GraphQL

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

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

علاوه بر این، برای کسانی که از یک طرز فکر سنتی REST API می آیند، GraphQL کمی الگوی جدید است که برای نشان دادن نقاط پایانی گراف به عنوان یک API تولید شده، نیاز به ماساژ دارد. انجام این کار احتمالاً شامل علامت‌گذاری بخش‌های منتخب نمودار بزرگ‌تر است تا در معرض دید شرکا قرار گیرد. DeBargalis گفت: “شروع با یک مورد استفاده داخلی GraphQL واقعا خوب کار می کند، اما تولید در اطراف GraphQL در راه است.”

ارزش یک نمودار یکپارچه آنقدر قوی است، و گرسنگی از پایین به بالا برای یک محیط گراف آنقدر شدید است که افزایش پذیرش GraphQL به نظر یک امر معین است. دیبرگالیس گفت: «در این مرحله، تمرکز بر گسترش است. “چگونه این را برای تیم های بیشتری ارائه کنیم؟”

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

[ad_2]

به این مطلب امتیاز دهید

توجه و هشدار
طبق ماده 12 فصل سوم قانون جرائم رایانه ای هرگونه کپی برداری از تگ سرویس و سایت های آن پیگرد قانونی دارد.
هرگونه کپی برداری از قالب و مطالب شرعا حرام بوده و پیگرد قانونی دارد وقابل پیگیری خواهد بود!
همچنین سایت یا وبلاگ متخلف گزارش dcma می شود!
منبع تگ سرویس
رمز فايل : www.tagservice.ir
۳ سال به صورت حرفه ای با وردپرس کار میکنم و به کارهای وب و سئو و همچنین برنامه نویسی علاقه مندم.
نوشته ایجاد شد 307

نوشته های مرتبط

متنی که میخواهید برای جستجو وارد کرده و دکمه جستجو را فشار دهید. برای لغو دکمه ESC را فشار دهید.

بازگشت به بالا
تبلیغات class=