این پست در اصل در وب سایت Stax.

ساخت یک کنسول وب برای محصولی به پیچیدگی Stax تعدادی از چالش ها را به وجود آورده است. اولین API ، پلت فرم بدون سرور ما طیف متنوعی از ویژگی ها را برای شرکت هایی که می خواهند اکوسیستم AWS خود را مدیریت و بهینه کنند ارائه می دهد.

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

این پست آنچه را که قصد ساختن Stax Console داشتیم ، تجربه ساخت یک GraphQL API بدون سرور برای تأمین انرژی آن و درسهایی که در این راه آموختیم را پوشش خواهد داد.

بدون سرور توسط طراحی

ما می خواستیم راه حلی را تولید کنیم که از ابتدا بدون سرور باشد ، تا با معماری مورد استفاده برای بقیه محصولات مطابقت داشته باشد. یکی از بزرگترین مزایایی که از ادامه کار مشاهده کرده ایم معماری های بدون سرور در Stax به روز بودن و قابلیت اطمینان است. اجتناب از اتکا به سروری که می تواند به یک نقطه خرابی تبدیل شود ، به ما امکان می دهد توافق نامه سطح سرویس خود را رعایت کنیم و اطمینان حاصل کنیم که مشتریان می توانند در زمان اوج بارگذاری به سیستم عامل دسترسی داشته باشند. استفاده كردن AWS لامبدا به معنای نمایش داده شده از مقیاس front-end ما به صورت افقی است و همیشه منابع محاسبه کافی برای پردازش درخواست ها وجود دارد.

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

حداقل زیرساخت های اضافی هنگام سرور ، به تیم ما این امکان را می دهد تا به طور کامل مالک استقرار و نظارت بر GraphQL API ما باشد. به عنوان مثال ، توسعه دهندگان می توانند جدید اضافه کنند شبکه های عملکرد با استفاده از توابع Lambda جداگانه به آنهایی که برای واکشی داده های حساب استفاده می شود ، شعاع انفجار را از فشار دادن تغییر جدید به تولید به حداقل می رساند.

روزهای نخست

اولین تکرار کنسول ما دارای معماری کاملاً سنتی وب بود. یک برنامه React تک صفحه ای (SPA) به نام Stax REST API مستقیماً ، که با استفاده از آن یک راه حل بدون سرور است AWS API Gateway و AWS Lambda در مقابل یک پایگاه داده رابطه ای. یادگیری AWS تأیید اعتبار کاربر و ورود به سیستم را برای Console و REST API کنترل می کند.

با این روش به چند مسئله فنی برخوردیم:

  1. ابزار. چارچوب های جلویی مدرن به سرعت تکامل می یابند. مصرف داده ها از REST API ها با React پیچیده بود و مدیریت وضعیت آن دشوار بود.
  2. ثبات. اتصال دقیق SPA جلویی ما با API REST back-end کارآمد بود ، اما قرارداد بین سیستم ها به طور مداوم در حال تغییر بود زیرا ویژگی هایی ایجاد می شد که باعث از بین رفتن رابط کاربری ما می شود.
  3. به روز رسانی در زمان واقعی. برای انتقال داده ها به SPA جلویی خود برای ارائه به روزرسانی های واقعی ، باید پیاده سازی WebSocket خود را ایجاد کنیم. اجرای این امر در هر دو قسمت جلویی و عقب پیچیده بوده است.

همچنین مشخص شد که با رشد Stax به عنوان یک محصول ، کنسول نیاز به ادغام با سایر سرویس های پشتیبان غیر از REST API ما ، مانند داده های هزینه و انطباق برای حساب ها و سرویس پشتیبانی مشتری ما دارد. رابط کاربری با چندین API و پروتکل ، همه با مکانیسم های مختلف احراز هویت ، ما را به فکر انداخت Back End برای Front End الگوی با یک GraphQL API منفرد.

معماری کنسول ما اکنون

مرکز معماری بر روی a GraphQL لایه API که به عنوان یک پروکسی بین سرویس های جلو و عقب ما عمل می کند. GraphQL یک زبان پرس و جو برای API ها است. این به توسعه دهندگان اجازه می دهد تا انواع داده ها را در یک سیستم (طرحواره) تعریف کنند ، و توابع را برای واکشی داده ها از منابع مختلف (حلال ها) سیم کشی می کنند. روابط بین داده ها را می توان در یک پرس و جو GraphQL واحد گسترش داد. به عنوان مثال ، یک درخواست واحد می تواند حل کند حجم کار Stax و کاربری که آن را با یک حرکت مستقر کرده است.

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

در Stax ، ما از نزدیک با AWS همکاری می کنیم و سعی می کنیم در صورت امکان از راه حل های AWS بومی به عنوان بخشی از فلسفه توسعه خود استفاده کنیم. ما تصمیم به استفاده از AWS AppSync، پیاده سازی GraphQL بدون سرور کاملاً مدیریت شده به عنوان هسته اصلی خدمات ما.

AWS AppSync دستورالعمل های اصلی GraphQL را اجرا می کند ، از جمله اشتراک های GraphQL که اتصالات WebSocket بین کلاینت ها و GraphQL API شما را مدیریت می کنند. AWS Lambda واکشی و تبدیل داده ها در توابع حلگر GraphQL ، AWS DynamoDB برای ذخیره داده های بدون سرور استفاده می شود ، و AWS EventBridge عملکردهای Lambda را در پاسخ به رویدادهای سیستم آغاز می کند.

معماری کنونی Stax Console ما از GraphQL ، AWS AppSync ، AWS Dynamo و AWS EventBridge استفاده می کند

ساخته شده با Stax

Stax اولین محصول API است ، بنابراین ما از Stax REST API که در دسترس عموم قرار دارد استفاده کردیم تا اکثر کنسول مشتری را بسازیم. مصرف (غذای سگ، واقعاً) REST API خود به این معنی است که ما می توانیم قبل از انتشار قابلیت برای مشتریان ، عملکرد جاده را آزمایش کنیم و اسناد خود را بهبود بخشیم ، به عنوان کنترل کیفیت خودمان عمل می کنیم. داشتن یک GraphQL API که پشتوانه ماست ، همچنین به ما امکان می دهد ویژگی های جدید را قبل از اینکه در Stax REST API به مشتریان عمومی شود ، در کنسول معرفی کنیم. ما می توانیم به سادگی آن را به AppSync متصل کنیم و به عنوان قابلیت “Beta” به کنسول اضافه کنیم.

GraphQL API ما با به اشتراک گذاری اطلاعات تأیید اعتبار از AWS Cognito بین سرویس ها با Stax back end ارتباط برقرار می کند. این اطمینان می دهد که داده های کاربر در هر مرحله از فرآیند به طور دقیق توسط سازمان مشتری تفکیک می شود و یک ردیف حسابرسی را که به کاربر خاصی که اقدام را آغاز کرده است ، حفظ می کند. داشتن یک GraphQL API برای قسمت جلوی ما همچنین به ما امکان می دهد که آن را اجرا کنیم کنترل دسترسی مبتنی بر نقش، به این معنی که ما می توانیم محدودیت هایی را برای اقدامات کاربر بر اساس نقش آنها در سطح درخواست اعمال کنیم.

AppSync API همچنین به Stax Event Bus متصل است تا به رویدادهای سیستم تولید شده توسط سرویس های back-end مانند وضعیت مراحل تنظیم حساب فردی) کامل شدن ما استفاده می کنیم اشتراک های GraphQL برای افزایش عملکرد ارائه شده توسط Stax Event Bus و فشار دادن به روزرسانی ها در کنسول بدون اینکه مشتریان نیاز به تازه کردن صفحه خود داشته باشند.

پذیرش محدودیت ها

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

AWS AppSync امکان تصدیق احراز هویت توسط را آسان می کند با استفاده از AppSync Pipeline Resolvers، اما هنوز مهم است که اطمینان حاصل شود که تماس با خدمات با محدودیت نرخ دقیق مانند AWS Cognito به حداقل رسیده است. ما با انتزاع تعاملات با Cognito به یک سرویس اختصاصی به این مهم نزدیک شدیم ، اما جای این وجود دارد که با caching بهتر شود.

به عنوان یک محصول نسبتاً جدید ، AWS AppSync در اجرای GraphQL محدودیت هایی داشت که باید بر آنها غلبه می کردیم. AppSync یک وقفه 30 ثانیه ای دقیق برای همه درخواست ها اعمال می کند ، به این معنی که لیست های صفحه ای بزرگ داده با روابط تودرتو باید با دقت مدیریت شوند. AppSync همچنین هنگام کار با روابط یک به چند توابع Lambda را دسته ای می کند ، اما در حال حاضر محدودیت دسته ای 5 دارد که برای استفاده در عمل بسیار کم است. با استفاده از پیاده سازی GraphQL خود می توانستیم از این مسائل جلوگیری کنیم ، اما مزایای استفاده از یک راه حل کاملاً بدون سرور مدیریت شده بیش از نقاط درد است.

مراحل بعدی

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

با ادامه تکامل پلت فرم Stax ، ما همچنان ویژگی های جدیدی را به کنسول خود اضافه می کنیم تا سازمان شما بتواند همه جوانب اکوسیستم AWS خود را از یک مکان واحد مدیریت کند. اما از آنجا که ما از یک رویکرد بدون سرور استفاده می کنیم ، نیازی به اختصاص تلاش برای نگهداری سرورها نیست. در عوض ، ما می توانیم بر روی ایجاد تجربیات شگفت انگیزتر برای مشتریان خود تمرکز کنیم و در عین حال ایمن و سازگار باشیم ، حتی با پیشرفت پیچیده تر سیستم عامل.

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