معماری مجدد برنامه ها برای مقیاس. نحوه استفاده Coinbase از Relay و GraphQL… | توسط Coinbase | مه، 2022

چگونه Coinbase از Relay و GraphQL برای فعال کردن hypergrowth استفاده می کند

توسط کریس اریکسون و ترنس بزمن

کمی بیش از یک سال پیش، کوین بیس انتقال اپلیکیشن موبایل اولیه ما به React Native را تکمیل کرد. در طول مهاجرت، متوجه شدیم که رویکرد موجود ما به داده‌ها (نقاط پایانی REST و یک کتابخانه واکشی داده‌های REST ساخته‌شده) با رشدی که به‌عنوان یک شرکت تجربه می‌کردیم، مطابقت ندارد.

“Hypergrowth” واژه‌ای است که بیش از حد استفاده می‌شود، بنابراین بیایید منظورمان را در این زمینه روشن کنیم. در 12 ماه پس از مهاجرت به برنامه React Native، ترافیک API ما 10 برابر افزایش یافت و تعداد دارایی های پشتیبانی شده را 5 برابر افزایش دادیم. در همان بازه زمانی، تعداد مشارکت کنندگان ماهانه در برنامه های اصلی ما سه برابر شد و به 300 نفر رسید. با این افزوده‌ها، ویژگی‌ها و آزمایش‌های جدید افزایش یافت، و ما شاهد کاهش سرعت این رشد به این زودی‌ها نیستیم (تنها امسال به دنبال استخدام 2000 نفر دیگر در بخش محصولات، مهندسی و طراحی هستیم).

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

GraphQL در ابتدا به عنوان رویکردی برای کمک به تکامل API و تجمیع درخواست ها پیشنهاد شد.

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

در حالت پایانی آن، ما توسط یک سیستم ناکارآمد محدود شدیم، همانطور که توسط چند حکایت نشان داده شده است:

1. یک نقطه پایانی داشبورد وب موجود برای صفحه اصلی جدید تغییر کاربری داده شد. این نقطه پایانی مسئول 14٪ از کل بار پشتیبان ما بود. متأسفانه داشبورد جدید فقط از این نقطه پایانی برای یک فیلد بولی واحد استفاده می کرد.
2. نقطه پایانی کاربر ما آنقدر متورم شده بود که تقریباً 8 مگابایت پاسخ داشت – اما هیچ مشتری واقعاً به همه این داده ها نیاز نداشت.
3. اپلیکیشن موبایل هنگام راه‌اندازی باید ۲۵ تماس API موازی برقرار می‌کرد، اما در آن زمان React Native ما را به ۴ تماس موازی محدود می‌کرد که باعث ایجاد یک آبشار غیرقابل کاهش شد.

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

خوشبختانه، این دقیقاً همان چیزی است که GraphQL برای آن ایجاد شده است. با GraphQL، مشتری می‌تواند یک درخواست تکی واکشی کند فقط داده هایی که برای نمایی که نشان می دهد نیاز دارد. (در واقع با Relay می توانیم نیاز آنها فقط داده‌های مورد نیاز خود را درخواست کنید — بعداً در مورد آن بیشتر توضیح خواهیم داد.) این منجر به درخواست‌های سریع‌تر، کاهش ترافیک شبکه، بار کمتر در سرویس‌های باطن ما و به طور کلی برنامه سریع‌تر می‌شود.

زمانی که Coinbase از 5 دارایی پشتیبانی می‌کرد، برنامه می‌توانست چند درخواست داشته باشد: یکی برای دریافت دارایی‌ها (5) و دیگری برای دریافت آدرس کیف پول (تا 10) برای آن دارایی‌ها و پیوند آنها بر روی مشتری. با این حال، زمانی که یک مجموعه داده به اندازه کافی بزرگ می شود که نیاز به صفحه بندی داشته باشد، این مدل به خوبی کار نمی کند. یا اندازه صفحه غیرقابل قبول بزرگی دارید (که عملکرد API شما را کاهش می دهد)، یا با API های دست و پا گیر و درخواست های آبشاری روبرو می شوید.

اگر آشنا نیستید، یک آبشار در این زمینه زمانی اتفاق می‌افتد که مشتری ابتدا باید صفحه‌ای از دارایی‌ها را بخواهد (10 دارایی اول پشتیبانی شده را به من بدهید)، و سپس باید کیف پول‌ها را بخواهد. برای آن دارایی ها (کیف پول هایی برای «BTC»، «ETH»، «LTC»، «DOGE»، «SOL»، و … به من بدهید). از آنجایی که درخواست دوم به درخواست اول وابسته است، یک آبشار درخواست ایجاد می کند. هنگامی که این درخواست های وابسته از مشتری انجام می شود، تأخیر ترکیبی آنها می تواند به عملکرد وحشتناکی منجر شود.

این یکی دیگر از مشکلاتی است که GraphQL حل می‌کند: به داده‌های مرتبط اجازه می‌دهد تا در درخواست تودرتو شوند و این آبشار را به سرور پشتیبان منتقل کند که می‌تواند این درخواست‌ها را با تأخیر بسیار کمتری ترکیب کند.

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

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

این مزایا از الگوی Relay در استفاده از قطعات برای هم‌سویی وابستگی‌های داده در اجزایی که داده‌ها را ارائه می‌کنند، ناشی می‌شود. اگر یک جزء به داده نیاز دارد، باید از طریق نوع خاصی از پروپوزال منتقل شود. این پایه‌ها غیرشفاف هستند (مولفه اصلی فقط می‌داند که باید یک {ChildComponentName}Fragment را بدون دانستن محتوای آن ارسال کند)، که جفت شدن بین مؤلفه‌ها را محدود می‌کند. قطعات همچنین تضمین می کنند که یک جزء فقط فیلدهایی را می خواند که صریحاً درخواست کرده است، و جفت شدن با داده های اساسی را کاهش می دهد. این امر چکش خواری، ایمنی و عملکرد را افزایش می دهد. کامپایلر Relay به نوبه خود قادر است قطعات را در یک پرس و جو جمع کند، که از آبشار مشتری و درخواست چندین بار داده های مشابه جلوگیری می کند.

همه اینها کاملاً انتزاعی است، بنابراین یک مؤلفه ساده React را در نظر بگیرید که داده ها را از یک REST API واکشی می کند و یک لیست ارائه می دهد (این شبیه به چیزی است که با استفاده از React Query، SWR یا حتی Apollo می سازید):