Summarize this content to 400 words in Persian Lang در روزهای اولیه سفر مهندسی نرم افزارم، با کتابخانه ای به نام Socket.io برخوردم. احتمالاً در مورد آن شنیده اید. این ایده که می‌توانم ارتباط بلادرنگ را مستقیماً از برنامه‌های Node.js خود فعال کنم، یک پیشنهاد هیجان‌انگیز بود. مانند بسیاری از توسعه دهندگان، من بلافاصله شروع به فکر کردن به تمام راه هایی کردم که می توانم از این فناوری برای ساخت برنامه ها و خدمات نوآورانه استفاده کنم.
مانند بسیاری از توسعه دهندگان، من با یک برنامه چت شروع کردم – چه کسی این کار را نکرده است؟ من آن را با Backbone در سمت کلاینت ساختم، پشتیبان را روی یک قطره کوچک DigitalOcean میزبانی کردم، و از MySQL به عنوان ذخیره دائمی داده استفاده کردم.
اتاق‌ها، پیام‌های دائمی، آپلود فایل‌ها و آواتارهای کاربر داشت. من عقب نشستم و خلقت خود را تحسین کردم و به این فکر کردم که آیا این می تواند جذابیت بعدی اینترنت باشد. اسپویلر: قطعا اینطور نبود.
نمی‌دانستم که مقیاس‌بندی برنامه «پیشگامانه» من اولین چالش بزرگ من باشد. این به معنای برخورد با آداپتورها، متعادل کننده بار، جلسات چسبنده و مدیریت دقیق چرخه عمر اتصال سوکت بود.
پس از مقابله با چالش های مقیاس بندی، مانع بعدی مدیریت وضعیت برنامه بود. اتصالات WebSocket می‌تواند غیرقابل اعتماد باشد—اگر اتصال قطع شود، چگونه می‌توانم اطمینان حاصل کنم که کاربر دوباره به اتاق‌های خود وصل شده است و تجربه‌ای روان را حتی در زمانی که اتصال برقرار نیست ارائه کنم؟
بنابراین، من موفق شدم یک راه حل مقیاس پذیر با تداوم وضعیت برنامه را هک کنم. اما در این مرحله، هر کسی که URL را داشت می‌توانست به سرور WebSocket من متصل شود – این اساساً برای همه رایگان بود! متوجه شدم که حداقل به یک فایروال برنامه، محدود کردن نرخ و دسترسی ایمن نیاز دارم، احتمالاً با استفاده از احراز هویت مبتنی بر توکن.
این یک کابوس بود! من باید ویژگی‌های جدیدی را به برنامه چت خود اضافه می‌کردم، نه اینکه زیرساخت‌های باطن را ایجاد کنم.
در نهایت برنامه را کنار گذاشتم و روی حرفه ام در مهندسی نرم افزار تمرکز کردم. اما من مدام به پروژه های جانبی مربوط به عملکرد بلادرنگ کشیده می شدم، جایی که همیشه با چالش های مشابهی روبرو می شدم.
قطع کن تا الان…
اخیراً، من شروع به فکر کردن در مورد پروژه دیگری با برخی ویژگی‌های بلادرنگ کردم، بنابراین به پلتفرم‌هایی نگاه کردم که می‌توانند به من کمک کنند تا سریع کار کنم. طبیعتاً با نام های بزرگی مانند Supabase، Firebase و Appwrite برخورد کردم. همه آنها پشتیبانی عالی را برای عملکرد بلادرنگ ارائه می دهند، اما خرید ورود بسیار زیاد است. اجرای یک پلتفرم کامل روی یک پیشنهاد BaaS برای من منطقی نبود. بعلاوه، هزینه‌ها حتی با میزبانی شخصی که با هزینه‌های سربار خود همراه است، می‌تواند سر به فلک بکشد. من به چیزی نیاز داشتم که بتوانم آن را در برنامه خود قرار دهم تا عملکردهای بلادرنگ را در مقیاس انجام دهم و در عین حال به راحتی با تنظیمات موجود من مطابقت داشته باشم. این چیزی است که من به دنبال آن بودم:
احراز هویت ایمن اتصال
مدیریت چرخه عمر سوکت صاف
کنترل وضعیت برنامه قابل اعتماد
ردیابی حضور کاربر
تحویل پیام تضمینی
توانایی ارسال پیام ها از پشتیبان به مشتریان متصل
در حالت ایده آل، راهی برای اجرای همه چیز به صورت محلی در مرحله توسعه
برای یافتن راه‌حلی تلاش کردم و به این فکر کردم که آیا دیگران نیز با همین چالش‌ها روبرو هستند. من به یک سرویس ساده نیاز داشتم که بتواند عملکرد بلادرنگ را انجام دهد – بدون موارد اضافی یا برچسب قیمت سنگین. ناگهان، ایده اصلی پروژه من به عقب نشست. شاید بتوانم از درس هایی که در طول زندگی حرفه ای ام آموخته بودم برای ساختن پلتفرمی استفاده کنم که این مشکلات را یک بار برای همیشه حل کند.
پس از مدتی تحقیق، اولین فکر من این بود که رابطه خود را با Socket.io احیا کنم. این یک کتابخانه عالی با بسیاری از ویژگی‌های عالی است، اما دارای برخی مشکلات مدیریت حافظه در مقیاس است و ویژگی‌های اضافی آن می‌تواند سیستمی را که نیاز به ناب ماندن دارد، آزار دهد. من به چیزی نیاز داشتم که بتواند هر چیزی را که به سمتش پرتاب می کنم (در حد منطق) تحمل کند. این سیستم باید عملکرد بالا و تأخیر بسیار کم ارائه می داد. این زمانی بود که من شروع به سر و کله زدن با uWebSockets.js کردم و از معیارهای عملکرد آن، حتی در سخت‌افزار متوسط، شگفت‌زده شدم. بی‌معنی بود – این به هسته‌ی اصلی سیستم تبدیل می‌شد.
مقیاس پذیری
اولین چالش مقیاس پذیری بود – توزیع پیام ها در سرورهای با مقیاس افقی بدون تکیه بر جلسات چسبنده. من به یک کارگزار متمرکز برای ارائه پیام ها در مقیاس نیاز داشتم، و RabbitMQ با AMQP مناسب به نظر می رسید. با استفاده از تبادل موضوع، می‌توانم پیام‌ها را بر اساس شناسه‌های اتاق مسیریابی کنم. با این حال، داشتن یک صحافی برای هر اتاق منجر به ریزش زیاد می شود، به خصوص در برنامه های کاربردی با اتاق های زیاد. هش مداوم این مشکل را با اختصاص دادن یک صف به هر اتاق بر اساس مقدار هش آن حل کرد. پس از آزمایش‌ها و تنظیمات دقیق، یک واسطه پیام مقیاس‌پذیر در هسته سیستم داشتم.
چرخه حیات اتصال WebSocket و احراز هویت
بعدی مدیریت چرخه حیات سوکت و احراز هویت امن بود. Auth اغلب یک نقطه دردناک در توسعه برنامه است، اما مهم است که آن را به درستی انجام دهید. من یک سیستم قوی و مبتنی بر توکن برای تأیید اعتبار اتصالات قبل از ایجاد اتصال WebSocket ایجاد کردم. نتیجه یک سیستم احراز هویت زنده با ویژگی های غنی با MFA، OAuth و مدیریت چرخه عمر توکن داخلی بود. این سیستم حتی می‌توانست به‌عنوان یک کتابخانه احراز هویت هم‌شکل به تنهایی مورد استفاده قرار گیرد، اما مهم‌تر از همه، این سیستم در اتصال سرور WebSocket ادغام شد و اطمینان حاصل کرد که فقط اتصالات تأیید شده ارتقا می‌یابند.
مدیریت دولتی
مدیریت ایالت برای هر برنامه ای، به ویژه برنامه ای که از WebSockets استفاده می کند، بسیار مهم است. اتصال از دست رفته باید بتواند جلسه خود را به طور یکپارچه برای کاربر برقرار کند. من نمی‌خواستم سرعت سرور سوکت پرسرعت را با تماس‌های پرهزینه پایگاه‌داده ناهمزمان کند کنم، اما همچنان برای مدیریت اتصالات مجدد نیاز به پشتکار داشتم. Redis راه حل عالی بود – سرعت خواندن و نوشتن آن، به علاوه اسکریپت نویسی Lua برای عملیات اتمی، آن را به یک تناسب ایده آل تبدیل کرد. هر اتصال یک شناسه منحصربه‌فرد دریافت می‌کند که اجازه می‌دهد وضعیت آن در طول اتصال مجدد بازیابی شود.
عجب!!
اگر تا اینجا پیش رفتید، ممنونم! من می دانم که چیزهای زیادی برای باز کردن وجود دارد، و من جذاب ترین نویسنده نیستم، بنابراین از توجه شما بسیار سپاسگزارم. برای ادامه دادن آماده اید؟
خدمات اصلی
در مرحله بعد، من می‌خواستم برخی از خدمات اصلی را معرفی کنم، که با ردیابی حضور کاربر، تاریخچه پیام برای تحویل تضمینی، معیارها و یک سیستم وب‌هوک شروع می‌شود تا به خدمات شخص ثالث امکان اشتراک در رویدادهای بلادرنگ را بدهد. از آنجایی که این خدمات باید به طور مستقل با نوسانات تقاضا مقیاس شوند، یک سیستم توزیع شده بسیار منطقی است. سرور WebSocket رویدادها را به محض وقوع پردازش می کند و رویدادهای نامگذاری شده را در صف قرار می دهد که برای تداوم و ارسال به کنترل کننده های پایین دست هدایت می شوند. با توجه به اینکه من قبلاً از Redis برای مدیریت دولتی استفاده می کردم، BullMQ برای مدیریت این موضوع مناسب بود. پنج سرویس اصلی عبارتند از…
حضور
جلسه
معیارها
تاریخچه
وب هوک
هر سرویس BullMQ worker مخصوص به خود را اجرا می کند و به آن اجازه می دهد تا به طور مستقل بر اساس بار سیستم مقیاس شود. با استقرار در یک سرویس ارکستراسیون کانتینر مانند ECS، می‌توانم مقیاس‌بندی را با افزایش تقاضا به‌طور خودکار انجام دهم، در حالی که اطمینان حاصل کنم که حداقل یک نمونه کانتینر همیشه در حال اجرا است.
با این پنج سرویس که ستون فقرات سیستم را تشکیل می دادند، همه چیز واقعاً شروع به شکل گیری کرد. گام بعدی ارائه راهی برای توسعه دهندگان و کاربران برای تعامل با سیستم بود که اکنون RelayBox نامیده می شود.
کتابخانه های SDK
پلتفرم باید هم از مرورگر و هم از سرور قابل دسترسی باشد، بنابراین من دو کتابخانه ساختم: یک SDK مشتری و یک REST SDK. سرویس گیرنده SDK اتصالات WebSocket، مدیریت اتاق ها و احراز هویت را مدیریت می کند. REST SDK توکن‌هایی (برای احراز هویت) صادر می‌کند و رویدادهای سمت سرور را برای مشتریان متصل منتشر می‌کند. هدف من این بود که تا حد امکان عملکردهای بیشتری را در APIهای ساده انتزاعی کنم تا ساخت برنامه های بلادرنگ در RelayBox آسان شود.
برای کتابخانه سرویس گیرنده، من یک الگوی انتشار دهنده رویداد، شبیه به Socket.io، اما با قابلیت های اضافه شده برای مدیریت چرخه حیات سوکت، اتاق ها، احراز هویت، معیارها و موارد دیگر انتخاب کردم.
REST SDK پوشش‌هایی را برای تأیید امضای توکن و درخواست و همچنین درخواست‌های HTTP فراهم می‌کند که به رویدادها اجازه می‌دهد از برنامه‌های Node منتشر شوند. به عنوان مثال، یک تعامل با پایگاه داده ممکن است یک رویداد را برای مشتریانی که در یک جدول خاص مشترک شده اند راه اندازی کند، یا یک آپلود فایل می تواند مشتریان علاقه مند را مطلع کند. موارد استفاده بی پایان هستند!
در این مرحله، هسته پلت فرم تقریبا کامل شده است. از ابتدا، هدف من این بود که قابلیت‌های بلادرنگ را برای توسعه‌دهندگان بدون وادار کردن آنها به اتکای فوری به زیرساخت‌های ابر مدیریت‌شده در دسترس قرار دهم. من می خواستم توسعه دهندگان بتوانند تا زمانی که برنامه آنها برای تولید آماده شود، آزمایش، نمونه اولیه و ساخت محلی را انجام دهند.
کار آفلاین
با توجه به طراحی مدولار و ساختار کانتینری پلت فرم، ایجاد این امکان ساده بود. من تصمیم گرفتم یک جعبه ابزار ساده CLI ایجاد کنم که توسعه دهندگان می توانند از آن برای چرخش کل پلت فرم به صورت محلی با یک دستور واحد استفاده کنند، به لطف Docker Compose. Nginx نقش پراکسی برای کشف سرویس در شبکه محلی را بر عهده دارد، به این معنی که توسعه‌دهندگان فقط باید به یک نقطه پایانی در معرض یکپارچه متصل شوند.
و چه زمانی برنامه شما آماده انتشار است؟ مشکلی نیست – فقط از داشبورد برای ایجاد یک کلید API استفاده کنید و به طور یکپارچه به زیرساخت ابر مدیریت شده بروید. این به برنامه شما اجازه می‌دهد تنها با چند کلیک مقیاس جهانی داشته باشد، و به شما انعطاف‌پذیری را می‌دهد تا به صورت محلی توسعه داده شود و زمانی که آماده هستید در مقیاس اجرا شود. و برای کسانی که میزبانی خود را ترجیح می دهند، مدل منبع باز انعطاف پذیر است و از آن رویکرد نیز پشتیبانی کامل می کند.
در طول این مقاله، برخی از ویژگی‌های اصلی RelayBox را برجسته کرده‌ام، اما چیزهای بیشتری برای بررسی وجود دارد. از معماری منعطف آن که از توسعه محلی و استقرار در مقیاس ابری پشتیبانی می‌کند، تا ویژگی‌های امنیتی قوی مانند احراز هویت مبتنی بر رمز و ردیابی حضور کاربر، RelayBox به گونه‌ای طراحی شده است که توسعه بلادرنگ برنامه را نه تنها قدرتمند، بلکه مدیریت آن نیز آسان کند.
فراتر از خدمات اصلی، امکانات متعددی برای سفارشی سازی و مقیاس بندی متناسب با نیازهای منحصر به فرد پروژه شما وجود دارد. چه در حال ساخت یک برنامه چت، یک داشبورد زنده یا هر چیزی باشید که به داده های زمان واقعی متکی باشد، RelayBox می تواند بار را مدیریت کند و عملکردی بی نظیر در مقیاس ارائه دهد.
به علاوه، پلتفرم کاملاً منبع باز است، به این معنی که شما شفافیت کامل و توانایی مشارکت، اصلاح یا گسترش RelayBox را به هر نحوی که صلاح می‌دانید دارید. این با در نظر گرفتن توسعه دهندگان ساخته شده است، بنابراین شما می توانید بر روی ساخت ویژگی های کاربران خود تمرکز کنید، نه مدیریت زیرساخت.
خیلی چیزهای بیشتری زیر کاپوت وجود دارد، و من نمی‌توانم منتظر بمانم تا شما وارد آن شوید و ببینید که RelayBox چه کاری می‌تواند برای پروژه بعدی شما انجام دهد.
بعد چه می شود؟
من هنوز در حال بررسی مراحل بعدی برای RelayBox هستم، اما به سمت یکپارچه سازی یک محیط فراخوانی عملکرد بدون سرور متمایل هستم. این امر به رویدادهای خاص اجازه می‌دهد تا جریان‌های کاری را در حین وقوع ایجاد کنند و انعطاف‌پذیری و قدرت بیشتری را به پلتفرم اضافه کنند. تصور کنید کارهای پیچیده را در پاسخ به رویدادهای بی‌درنگ بدون مدیریت زیرساخت‌های اضافی خودکار کنید – این همان عملکردی است که من از آن هیجان‌زده هستم.
نظر شما چیست؟ من دوست دارم نظرات و ایده های شما را در مورد جایی که بعداً RelayBox را ببرم بشنوم!
اگر شما هم مثل من در مورد ساده سازی توسعه برنامه بلادرنگ هیجان زده اید، RelayBox را امتحان کنید! این منبع باز است و به گونه ای طراحی شده است که به راحتی در پروژه های موجود شما ادغام شود، چه در حال ساخت محلی باشید و چه در مقیاس. برای شروع به GitHub بروید، یا برای جزئیات بیشتر در مورد نحوه چرخش آن برای پروژه بعدی خود، اسناد را بررسی کنید.
در روزهای اولیه سفر مهندسی نرم افزارم، با کتابخانه ای به نام Socket.io برخوردم. احتمالاً در مورد آن شنیده اید. این ایده که می‌توانم ارتباط بلادرنگ را مستقیماً از برنامه‌های Node.js خود فعال کنم، یک پیشنهاد هیجان‌انگیز بود. مانند بسیاری از توسعه دهندگان، من بلافاصله شروع به فکر کردن به تمام راه هایی کردم که می توانم از این فناوری برای ساخت برنامه ها و خدمات نوآورانه استفاده کنم.
مانند بسیاری از توسعه دهندگان، من با یک برنامه چت شروع کردم – چه کسی این کار را نکرده است؟ من آن را با Backbone در سمت کلاینت ساختم، پشتیبان را روی یک قطره کوچک DigitalOcean میزبانی کردم، و از MySQL به عنوان ذخیره دائمی داده استفاده کردم.
اتاق‌ها، پیام‌های دائمی، آپلود فایل‌ها و آواتارهای کاربر داشت. من عقب نشستم و خلقت خود را تحسین کردم و به این فکر کردم که آیا این می تواند جذابیت بعدی اینترنت باشد. اسپویلر: قطعا اینطور نبود.
نمی‌دانستم که مقیاس‌بندی برنامه «پیشگامانه» من اولین چالش بزرگ من باشد. این به معنای برخورد با آداپتورها، متعادل کننده بار، جلسات چسبنده و مدیریت دقیق چرخه عمر اتصال سوکت بود.
پس از مقابله با چالش های مقیاس بندی، مانع بعدی مدیریت وضعیت برنامه بود. اتصالات WebSocket می‌تواند غیرقابل اعتماد باشد—اگر اتصال قطع شود، چگونه می‌توانم اطمینان حاصل کنم که کاربر دوباره به اتاق‌های خود وصل شده است و تجربه‌ای روان را حتی در زمانی که اتصال برقرار نیست ارائه کنم؟
بنابراین، من موفق شدم یک راه حل مقیاس پذیر با تداوم وضعیت برنامه را هک کنم. اما در این مرحله، هر کسی که URL را داشت می‌توانست به سرور WebSocket من متصل شود – این اساساً برای همه رایگان بود! متوجه شدم که حداقل به یک فایروال برنامه، محدود کردن نرخ و دسترسی ایمن نیاز دارم، احتمالاً با استفاده از احراز هویت مبتنی بر توکن.
این یک کابوس بود! من باید ویژگی‌های جدیدی را به برنامه چت خود اضافه می‌کردم، نه اینکه زیرساخت‌های باطن را ایجاد کنم.
در نهایت برنامه را کنار گذاشتم و روی حرفه ام در مهندسی نرم افزار تمرکز کردم. اما من مدام به پروژه های جانبی مربوط به عملکرد بلادرنگ کشیده می شدم، جایی که همیشه با چالش های مشابهی روبرو می شدم.
قطع کن تا الان…
اخیراً، من شروع به فکر کردن در مورد پروژه دیگری با برخی ویژگی‌های بلادرنگ کردم، بنابراین به پلتفرم‌هایی نگاه کردم که می‌توانند به من کمک کنند تا سریع کار کنم. طبیعتاً با نام های بزرگی مانند Supabase، Firebase و Appwrite برخورد کردم. همه آنها پشتیبانی عالی را برای عملکرد بلادرنگ ارائه می دهند، اما خرید ورود بسیار زیاد است. اجرای یک پلتفرم کامل روی یک پیشنهاد BaaS برای من منطقی نبود. بعلاوه، هزینه‌ها حتی با میزبانی شخصی که با هزینه‌های سربار خود همراه است، می‌تواند سر به فلک بکشد. من به چیزی نیاز داشتم که بتوانم آن را در برنامه خود قرار دهم تا عملکردهای بلادرنگ را در مقیاس انجام دهم و در عین حال به راحتی با تنظیمات موجود من مطابقت داشته باشم. این چیزی است که من به دنبال آن بودم:
- احراز هویت ایمن اتصال
- مدیریت چرخه عمر سوکت صاف
- کنترل وضعیت برنامه قابل اعتماد
- ردیابی حضور کاربر
- تحویل پیام تضمینی
- توانایی ارسال پیام ها از پشتیبان به مشتریان متصل
- در حالت ایده آل، راهی برای اجرای همه چیز به صورت محلی در مرحله توسعه
برای یافتن راه‌حلی تلاش کردم و به این فکر کردم که آیا دیگران نیز با همین چالش‌ها روبرو هستند. من به یک سرویس ساده نیاز داشتم که بتواند عملکرد بلادرنگ را انجام دهد – بدون موارد اضافی یا برچسب قیمت سنگین. ناگهان، ایده اصلی پروژه من به عقب نشست. شاید بتوانم از درس هایی که در طول زندگی حرفه ای ام آموخته بودم برای ساختن پلتفرمی استفاده کنم که این مشکلات را یک بار برای همیشه حل کند.
پس از مدتی تحقیق، اولین فکر من این بود که رابطه خود را با Socket.io احیا کنم. این یک کتابخانه عالی با بسیاری از ویژگی‌های عالی است، اما دارای برخی مشکلات مدیریت حافظه در مقیاس است و ویژگی‌های اضافی آن می‌تواند سیستمی را که نیاز به ناب ماندن دارد، آزار دهد. من به چیزی نیاز داشتم که بتواند هر چیزی را که به سمتش پرتاب می کنم (در حد منطق) تحمل کند. این سیستم باید عملکرد بالا و تأخیر بسیار کم ارائه می داد. این زمانی بود که من شروع به سر و کله زدن با uWebSockets.js کردم و از معیارهای عملکرد آن، حتی در سخت‌افزار متوسط، شگفت‌زده شدم. بی‌معنی بود – این به هسته‌ی اصلی سیستم تبدیل می‌شد.
مقیاس پذیری
اولین چالش مقیاس پذیری بود – توزیع پیام ها در سرورهای با مقیاس افقی بدون تکیه بر جلسات چسبنده. من به یک کارگزار متمرکز برای ارائه پیام ها در مقیاس نیاز داشتم، و RabbitMQ با AMQP مناسب به نظر می رسید. با استفاده از تبادل موضوع، می‌توانم پیام‌ها را بر اساس شناسه‌های اتاق مسیریابی کنم. با این حال، داشتن یک صحافی برای هر اتاق منجر به ریزش زیاد می شود، به خصوص در برنامه های کاربردی با اتاق های زیاد. هش مداوم این مشکل را با اختصاص دادن یک صف به هر اتاق بر اساس مقدار هش آن حل کرد. پس از آزمایش‌ها و تنظیمات دقیق، یک واسطه پیام مقیاس‌پذیر در هسته سیستم داشتم.
چرخه حیات اتصال WebSocket و احراز هویت
بعدی مدیریت چرخه حیات سوکت و احراز هویت امن بود. Auth اغلب یک نقطه دردناک در توسعه برنامه است، اما مهم است که آن را به درستی انجام دهید. من یک سیستم قوی و مبتنی بر توکن برای تأیید اعتبار اتصالات قبل از ایجاد اتصال WebSocket ایجاد کردم. نتیجه یک سیستم احراز هویت زنده با ویژگی های غنی با MFA، OAuth و مدیریت چرخه عمر توکن داخلی بود. این سیستم حتی می‌توانست به‌عنوان یک کتابخانه احراز هویت هم‌شکل به تنهایی مورد استفاده قرار گیرد، اما مهم‌تر از همه، این سیستم در اتصال سرور WebSocket ادغام شد و اطمینان حاصل کرد که فقط اتصالات تأیید شده ارتقا می‌یابند.
مدیریت دولتی
مدیریت ایالت برای هر برنامه ای، به ویژه برنامه ای که از WebSockets استفاده می کند، بسیار مهم است. اتصال از دست رفته باید بتواند جلسه خود را به طور یکپارچه برای کاربر برقرار کند. من نمی‌خواستم سرعت سرور سوکت پرسرعت را با تماس‌های پرهزینه پایگاه‌داده ناهمزمان کند کنم، اما همچنان برای مدیریت اتصالات مجدد نیاز به پشتکار داشتم. Redis راه حل عالی بود – سرعت خواندن و نوشتن آن، به علاوه اسکریپت نویسی Lua برای عملیات اتمی، آن را به یک تناسب ایده آل تبدیل کرد. هر اتصال یک شناسه منحصربه‌فرد دریافت می‌کند که اجازه می‌دهد وضعیت آن در طول اتصال مجدد بازیابی شود.
عجب!!
اگر تا اینجا پیش رفتید، ممنونم! من می دانم که چیزهای زیادی برای باز کردن وجود دارد، و من جذاب ترین نویسنده نیستم، بنابراین از توجه شما بسیار سپاسگزارم. برای ادامه دادن آماده اید؟
خدمات اصلی
در مرحله بعد، من می‌خواستم برخی از خدمات اصلی را معرفی کنم، که با ردیابی حضور کاربر، تاریخچه پیام برای تحویل تضمینی، معیارها و یک سیستم وب‌هوک شروع می‌شود تا به خدمات شخص ثالث امکان اشتراک در رویدادهای بلادرنگ را بدهد. از آنجایی که این خدمات باید به طور مستقل با نوسانات تقاضا مقیاس شوند، یک سیستم توزیع شده بسیار منطقی است. سرور WebSocket رویدادها را به محض وقوع پردازش می کند و رویدادهای نامگذاری شده را در صف قرار می دهد که برای تداوم و ارسال به کنترل کننده های پایین دست هدایت می شوند. با توجه به اینکه من قبلاً از Redis برای مدیریت دولتی استفاده می کردم، BullMQ برای مدیریت این موضوع مناسب بود. پنج سرویس اصلی عبارتند از…
- حضور
- جلسه
- معیارها
- تاریخچه
- وب هوک
هر سرویس BullMQ worker مخصوص به خود را اجرا می کند و به آن اجازه می دهد تا به طور مستقل بر اساس بار سیستم مقیاس شود. با استقرار در یک سرویس ارکستراسیون کانتینر مانند ECS، می‌توانم مقیاس‌بندی را با افزایش تقاضا به‌طور خودکار انجام دهم، در حالی که اطمینان حاصل کنم که حداقل یک نمونه کانتینر همیشه در حال اجرا است.
با این پنج سرویس که ستون فقرات سیستم را تشکیل می دادند، همه چیز واقعاً شروع به شکل گیری کرد. گام بعدی ارائه راهی برای توسعه دهندگان و کاربران برای تعامل با سیستم بود که اکنون RelayBox نامیده می شود.
کتابخانه های SDK
پلتفرم باید هم از مرورگر و هم از سرور قابل دسترسی باشد، بنابراین من دو کتابخانه ساختم: یک SDK مشتری و یک REST SDK. سرویس گیرنده SDK اتصالات WebSocket، مدیریت اتاق ها و احراز هویت را مدیریت می کند. REST SDK توکن‌هایی (برای احراز هویت) صادر می‌کند و رویدادهای سمت سرور را برای مشتریان متصل منتشر می‌کند. هدف من این بود که تا حد امکان عملکردهای بیشتری را در APIهای ساده انتزاعی کنم تا ساخت برنامه های بلادرنگ در RelayBox آسان شود.
برای کتابخانه سرویس گیرنده، من یک الگوی انتشار دهنده رویداد، شبیه به Socket.io، اما با قابلیت های اضافه شده برای مدیریت چرخه حیات سوکت، اتاق ها، احراز هویت، معیارها و موارد دیگر انتخاب کردم.
REST SDK پوشش‌هایی را برای تأیید امضای توکن و درخواست و همچنین درخواست‌های HTTP فراهم می‌کند که به رویدادها اجازه می‌دهد از برنامه‌های Node منتشر شوند. به عنوان مثال، یک تعامل با پایگاه داده ممکن است یک رویداد را برای مشتریانی که در یک جدول خاص مشترک شده اند راه اندازی کند، یا یک آپلود فایل می تواند مشتریان علاقه مند را مطلع کند. موارد استفاده بی پایان هستند!
در این مرحله، هسته پلت فرم تقریبا کامل شده است. از ابتدا، هدف من این بود که قابلیت‌های بلادرنگ را برای توسعه‌دهندگان بدون وادار کردن آنها به اتکای فوری به زیرساخت‌های ابر مدیریت‌شده در دسترس قرار دهم. من می خواستم توسعه دهندگان بتوانند تا زمانی که برنامه آنها برای تولید آماده شود، آزمایش، نمونه اولیه و ساخت محلی را انجام دهند.
کار آفلاین
با توجه به طراحی مدولار و ساختار کانتینری پلت فرم، ایجاد این امکان ساده بود. من تصمیم گرفتم یک جعبه ابزار ساده CLI ایجاد کنم که توسعه دهندگان می توانند از آن برای چرخش کل پلت فرم به صورت محلی با یک دستور واحد استفاده کنند، به لطف Docker Compose. Nginx نقش پراکسی برای کشف سرویس در شبکه محلی را بر عهده دارد، به این معنی که توسعه‌دهندگان فقط باید به یک نقطه پایانی در معرض یکپارچه متصل شوند.
و چه زمانی برنامه شما آماده انتشار است؟ مشکلی نیست – فقط از داشبورد برای ایجاد یک کلید API استفاده کنید و به طور یکپارچه به زیرساخت ابر مدیریت شده بروید. این به برنامه شما اجازه می‌دهد تنها با چند کلیک مقیاس جهانی داشته باشد، و به شما انعطاف‌پذیری را می‌دهد تا به صورت محلی توسعه داده شود و زمانی که آماده هستید در مقیاس اجرا شود. و برای کسانی که میزبانی خود را ترجیح می دهند، مدل منبع باز انعطاف پذیر است و از آن رویکرد نیز پشتیبانی کامل می کند.
در طول این مقاله، برخی از ویژگی‌های اصلی RelayBox را برجسته کرده‌ام، اما چیزهای بیشتری برای بررسی وجود دارد. از معماری منعطف آن که از توسعه محلی و استقرار در مقیاس ابری پشتیبانی می‌کند، تا ویژگی‌های امنیتی قوی مانند احراز هویت مبتنی بر رمز و ردیابی حضور کاربر، RelayBox به گونه‌ای طراحی شده است که توسعه بلادرنگ برنامه را نه تنها قدرتمند، بلکه مدیریت آن نیز آسان کند.
فراتر از خدمات اصلی، امکانات متعددی برای سفارشی سازی و مقیاس بندی متناسب با نیازهای منحصر به فرد پروژه شما وجود دارد. چه در حال ساخت یک برنامه چت، یک داشبورد زنده یا هر چیزی باشید که به داده های زمان واقعی متکی باشد، RelayBox می تواند بار را مدیریت کند و عملکردی بی نظیر در مقیاس ارائه دهد.
به علاوه، پلتفرم کاملاً منبع باز است، به این معنی که شما شفافیت کامل و توانایی مشارکت، اصلاح یا گسترش RelayBox را به هر نحوی که صلاح می‌دانید دارید. این با در نظر گرفتن توسعه دهندگان ساخته شده است، بنابراین شما می توانید بر روی ساخت ویژگی های کاربران خود تمرکز کنید، نه مدیریت زیرساخت.
خیلی چیزهای بیشتری زیر کاپوت وجود دارد، و من نمی‌توانم منتظر بمانم تا شما وارد آن شوید و ببینید که RelayBox چه کاری می‌تواند برای پروژه بعدی شما انجام دهد.
بعد چه می شود؟
من هنوز در حال بررسی مراحل بعدی برای RelayBox هستم، اما به سمت یکپارچه سازی یک محیط فراخوانی عملکرد بدون سرور متمایل هستم. این امر به رویدادهای خاص اجازه می‌دهد تا جریان‌های کاری را در حین وقوع ایجاد کنند و انعطاف‌پذیری و قدرت بیشتری را به پلتفرم اضافه کنند. تصور کنید کارهای پیچیده را در پاسخ به رویدادهای بی‌درنگ بدون مدیریت زیرساخت‌های اضافی خودکار کنید – این همان عملکردی است که من از آن هیجان‌زده هستم.
نظر شما چیست؟ من دوست دارم نظرات و ایده های شما را در مورد جایی که بعداً RelayBox را ببرم بشنوم!
اگر شما هم مثل من در مورد ساده سازی توسعه برنامه بلادرنگ هیجان زده اید، RelayBox را امتحان کنید! این منبع باز است و به گونه ای طراحی شده است که به راحتی در پروژه های موجود شما ادغام شود، چه در حال ساخت محلی باشید و چه در مقیاس. برای شروع به GitHub بروید، یا برای جزئیات بیشتر در مورد نحوه چرخش آن برای پروژه بعدی خود، اسناد را بررسی کنید.
