ForUs Messenger
یک پیامرسان Real-Time با معماری هیبریدی، طراحیشده برای دستیابی به بیشترین بازدهی روی سختافزارهای محدود؛ توسعهیافته توسط یک نفر با استفاده از FastAPI، WebSocket، PostgreSQL، MinIO و PWA.
زمان توسعه پروژه
توسعهدهنده اصلی
کانکشن همزمان WebSocket
بازنویسی پروژه از صفر
داستان پروژه
بزرگترین تصمیم
برای شناخت بهتر من، بهتر است ابتدا نگاهی به بزرگترین پروژهام، یعنی ForUs Messenger بیندازیم. پس از حدود پنج سال یادگیری و توسعه پروژههای کوچک، ساخت یک اپلیکیشن کامل به بزرگترین تصمیم من تبدیل شد؛ پروژهای که بیش از دو سال از زمان من را به خود اختصاص داد.
ایدهای برای جابهجایی فایل
این پروژه در ابتدا فقط یک راهکار ساده برای جابهجایی فایلها میان موبایل، لپتاپ و کامپیوتر شخصی بود. این ایده بهمرور توسعه پیدا کرد و در نسخه اولیه به یک پیامرسان ساده با معماری Polling تبدیل شد.
با بزرگتر شدن پروژه و افزایش نیازها، تصمیم گرفتم ارتباطات برنامه را بهشکل حرفهایتر و کاملاً Real-Time بازطراحی کنم.
بیشترین بازدهی با کمترین منابع
هدف اصلی، توسعه پیامرسانی بود که با ضعیفترین سختافزار ممکن، بهترین بازدهی را ارائه دهد. چالش شخصی من نیز توسعه تمام بخشها بهتنهایی، با کمترین هزینه و تنها یک توسعهدهنده بود.
در نسخههای ابتدایی، PostgreSQL برای دیتابیس، Go برای بکاند و PWA برای کلاینت انتخاب شدند. معماری بکاند نیز بهصورت هیبریدی و ترکیبی از HTTP API و WebSocket طراحی شد.
بازنویسیها و از دست رفتن کدها
بهدلیل آشنایی ناکافی با زبان Go و کمبود تجربه، نسخههای اولیه پروژه با مشکلات ساختاری مواجه شدند:
- تجربه ناکافی در توسعه پروژههای بزرگ با Go
- ماژولار نبودن ساختار و حجیمشدن اسکریپتها
- سختشدن فرایند توسعه، نگهداری و دیباگ
- سپردن بیش از حد تصمیمهای فنی به هوش مصنوعی
پروژه دو بار با این رویکرد شکست خورد. بخشی از کدهای بکاند روی VPS نیز از دست رفت و همزمان SSD لپتاپ من آسیب دید.
شروع دوباره با FastAPI
پروژه را با تجربهای کاملتر دوباره از صفر آغاز کردم. با توجه به تسلط بیشتر روی Python، این بار FastAPI را برای بکاند انتخاب کردم و با صرف زمان بیشتر و الگوبرداری از پیامرسانهایی مانند Telegram، نسخه PWA کلاینت را توسعه دادم.
ساختار نهایی پروژه
ساختار نهایی ForUs یک معماری هیبریدی است. عملیات معمول و درخواستهای مستقل از طریق HTTP API و رویدادهای بلادرنگ از طریق WebSocket مدیریت میشوند.
PWA Application
Cache · IndexedDB · LocalStorage
FastAPI
HTTP API · WebSocket · Validation
PostgreSQL + MinIO
Metadata · Messages · Object Storage
Backend
FastAPIمدیریت HTTP API، WebSocket، احراز هویت، اعتبارسنجی و هماهنگی رویدادهای پیامرسان.
Databases
PostgreSQL / MinIOPostgreSQL برای دادههای اصلی و MinIO برای نگهداری فایلها و محتوای Object Storage.
Frontend
Progressive Web Appکلاینت واکنشگرا با پشتیبانی از نصب، کش آفلاین و ذخیرهسازی محلی اطلاعات.
قابلیتهای پروژه
ارتباط Real-Time
انتقال سریع رویدادها و پیامها با استفاده از WebSocket.
اجرای آفلاین PWA
دسترسی به بخشهایی از رابط کاربری حتی بدون اتصال شبکه.
ذخیرهسازی محلی
استفاده از Cache، IndexedDB و LocalStorage در کلاینت.
مدیریت بهینه رسانه
ذخیره فایلها و تصاویر پروفایل در IndexedDB برای کاهش درخواستها و جلوگیری از کندی مرورگر.
Presigned URL
آپلود و دانلود مستقیم فایل میان کلاینت و MinIO بدون عبور محتوای فایل از FastAPI.
Web Push
نمایش اعلان پیامهای جدید در نسخه وب و PWA.
انواع فایل
پشتیبانی از ارسال و دریافت فرمتهای مختلف فایل.
ارسال پیام صوتی
ضبط، پیشنمایش و ارسال Voice Message در محیط چت.
Privacy
زیرساخت تنظیم سطح دسترسی و حریم خصوصی حساب کاربری.
سازگاری بین پلتفرمی
قابل استفاده روی Android، iOS، دسکتاپ و مرورگرهای مدرن.
رابط کاربری پویا
تعاملات نرم، انیمیشنهای هدفمند و تجربه کاربری واکنشگرا.
طراحی الگوبرداریشده
توسعه تجربه کاربری با بررسی رفتار پیامرسانهای مطرح فعلی.
Presigned URL؛ یکی از نقاط قوت پروژه
یکی از تصمیمهای مؤثر در معماری پروژه، استفاده از Presigned URL برای آپلود و دانلود فایلهاست. اگر تمام ترافیک فایل مستقیماً از FastAPI عبور میکرد، مصرف پهنای باند، حافظه و منابع سرور اصلی افزایش پیدا میکرد.
با Presigned URL، عملیات انتقال فایل مستقیماً میان کلاینت و Object Storage مانند MinIO انجام میشود. FastAPI فقط مسئول اعتبارسنجی درخواست، بررسی سطح دسترسی، ثبت metadata و صدور مجوز محدود است.
بررسیهای امنیتی پیش از تولید لینک
- آیا درخواست کاربر احراز هویت شده است؟
- آیا حساب کاربری درخواستدهنده وجود دارد؟
- آیا کاربر مجاز به ارسال فایل است؟
- آیا چت موردنظر متعلق به این کاربر است؟
- آیا کاربر یا حساب مقصد مسدود نشده است؟
- آیا تنظیمات چت اجازه ارسال این فایل را میدهد؟
هر لینک دارای Deadline یا زمان انقضا است و امکان استفاده دائمی از آن وجود ندارد. پس از تأیید بررسیها، لینک امن و محدود تولید میشود و انتقال فایل بدون تحمیل بار اضافه روی FastAPI انجام میگیرد.
کنترل چندمرحلهای آپلود فایل
فرایند آپلود فایل بهصورت چندمرحلهای طراحی شده است تا احتمال اسپم، آپلود مخرب و ثبت اطلاعات نامعتبر کاهش پیدا کند. کاربر ابتدا فایل را انتخاب و اطلاعات آن را در بخش پیشنمایش بررسی میکند؛ سپس چرخه زیر آغاز میشود.
upload-request
Client → Server
کلاینت قصد آپلود را به سرور اعلام میکند. اطلاعاتی مانند نوع فایل، فرمت، حجم، ابعاد تصویر یا ویدیو و metadataهای لازم همراه درخواست ارسال میشوند.
upload-ready
Server → Client
سرور احراز هویت و بررسیهای امنیتی را انجام میدهد. در صورت تأیید، اطلاعات فایل در دیتابیس ثبت و یک MinIO Presigned URL برای آپلود تولید میشود.
upload file
Client → MinIO
پس از دریافت رویداد upload-ready، حباب پیام با وضعیت uploading در کلاینت ایجاد میشود و فایل مستقیماً روی MinIO آپلود میگردد.
upload-complete
Client → Server
پس از پایان انتقال فایل، کلاینت تکمیل آپلود را به سرور اطلاع میدهد. کپشن، جزئیات پیام و اطلاعات نهایی فایل نیز میتوانند در این رویداد ارسال شوند.
upload-finished
Server → Client
سرور وجود فایل را در MinIO بررسی میکند. اگر فایل با رکورد
دیتابیس مطابقت داشته باشد، وضعیت رکورد به
uploaded تغییر میکند. سپس رویداد نهایی
برای فرستنده و رویداد new-message برای مقصد
ارسال میشود.
بخشهای در حال توسعه
مشخصات سختافزار فعلی سرور
پردازنده مجازی سرور
حافظه RAM سرور
فضای SSD در دسترس
مانیتورینگ و وضعیت منابع پروژه
پروژه روی Ubuntu 24 اجرا میشود. طبق گزارش سیستمعامل، در شرایط فعلی و با تعداد کاربران پایین، وضعیت CPU پایدار است و گلوگاه اصلی بیشتر به حافظه RAM مربوط میشود.
در شرایط فعلی
مصرف RAM برنامه در حالت عادی
حافظه آزاد قابل استفاده
مصرف تقریبی هر اتصال
-
01
در شرایط فعلی نیازی به افزایش تعداد هستههای CPU وجود ندارد؛ اما تنظیمات اجرای پروژه باید برای پردازش همزمان و کاهش latency بهینهسازی شود.
-
02
گلوگاه اصلی پروژه در وضعیت فعلی CPU نیست، بلکه RAM است.
-
03
سیستم کنترل اسپم در Message Handler وبسوکت حافظه کمی مصرف میکند. در مقیاس بزرگتر میتوان این بخش را با Redis پیادهسازی کرد.
-
04
مصرف حافظه سایر سرویسها در مقایسه با سرویسهای اصلی ناچیز است و فعلاً تأثیر قابلتوجهی بر منابع ندارد.
آینده پروژه
بررسی مهاجرت بکاند به Go
با افزایش تعداد کاربران، امکان بازنویسی بکاند با Go بررسی میشود تا تعداد اتصالهای همزمان روی سختافزار مشابه افزایش پیدا کند.
تکمیل قابلیتهای باقیمانده
تکمیل گروه، کانال، ربات، مدیریت دستگاهها، تنظیمات حریم خصوصی، زبان و Power Saving.
Error Handling
تکمیل مدیریت خطا در کلاینت و سرور با افزایش تعداد کاربران و دریافت گزارشهای واقعی.
Safe Send
طراحی یک روش ارسال امنتر که فعالسازی آن در اختیار کاربر قرار داشته باشد.
تشکیل تیم و توسعه Native
تشکیل تیم توسعه و انتشار نسخههای Android، Desktop و iOS پس از پایدارشدن نسخه اصلی.
گالری تصاویر
برای مشاهده هر تصویر در اندازه بزرگتر، روی آن کلیک کنید.