خداحافظی با nwidart/laravel-modules؛ سلام به panicdevs/modules
آرمین هوشمند
طبق معمول، همه‌چیز از یک نیاز شروع شد. بعد از سه سال توسعه‌ی مداوم روی بیش از ۱۵۰ ماژول تجاری و کاربردی، بالاخره تصمیم گرفتم مسیرم رو عوض کنم: دیگه از nwidart/laravel-modules استفاده نمی‌کنم و سراغ پکیج شخصی‌مون یعنی panicdevs/modules رفتم.
چرا این تغییر؟
اگه بخوام دلیلش رو در یک کلمه بگم: پرفورمنس. همین و بس.
ماژولار بودن برای ما فقط بحث راحتی نبود. توی پروژه‌هایی که لود بالا دارن، چند میلی‌ثانیه زمان بیشتر می‌تونه تفاوت جدی بسازه. هر چیزی که باعث می‌شد کند بشیم، باید حذف یا بازنویسی می‌شد.
شروع داستان ماژول‌ها
سه سال پیش من و حسام تصمیم گرفتیم چارچوب ماژولار اختصاصی خودمون رو داشته باشیم. چیزی که هم توسعه‌پذیر باشه، هم در پروژه‌های بزرگ پایدار.
تقریبا تمام این مدت در یک تیم بودیم و همین باعث شد تعامل زیادی داشته باشیم. ساختار رو بارها تست کردیم، بازخورد گرفتیم و اصلاح کردیم. اوایل امسال رسیدیم به نقطه‌ای که می‌تونستیم بگیم: «ساختار پایدار شد».
- چارچوب کاملاً جا افتاده بود.
- توی پروژه‌های تجاری واقعی امتحان شده بود.
- بدون باگ جدی و با اعتماد به نفس بالا.
یه جور حس zero issue داشتیم؛ انگار بعد از کلی آزمون و خطا بالاخره همه‌چیز سر جای خودش قرار گرفته بود.
دغدغه‌ی پرفورمنس
اما بعد از مدتی ذهنمون رفت سمت یه سوال: «آیا میشه سریع‌ترش کرد؟» حتی اگر سیستم خوب باشه، همیشه جا برای بهتر شدن هست.
اینجا بود که از ماژول Core شروع کردیم.
ایده‌ی Core Module رو اولین بار چند سال قبل خودم اجرا کرده بودم و حتی توی یکی از issueهای گیت‌هاب مطرحش کردم.
جالب اینکه David Carr، یکی از Maintainerهای اصلی nwidart/laravel-modules همونجا نوشت:
I like your idea for a core module, it's a nice approach 👍
همین یک جمله برای من شد انگیزه‌ی جدی برای ادامه دادن این مسیر.
چرا nwidart/laravel-modules کافی نبود؟
مشکل اصلی این بود که nwidart یک پکیج عمومی بود. یعنی باید نیازهای ساده‌ی همه رو پوشش می‌داد.
نتیجه این شد که کلی ابزار و قابلیت مثل discoveryها، commandها و configهای مختلف داشت که ما اصلاً بهشون نیازی نداشتیم.
در عمل ما حتی دستی ماژول می‌ساختیم. (به درجه عرفان از توسعه ماژولار رسیده بودیم 😂) تنها چیزی که برامون اهمیت داشت، پرفورمنس بود.
هر چیزی که سرعت رو کم می‌کرد حذف می‌کردیم. هر جایی که bottleneck بود بازنویسی می‌کردیم.
تولد panicdevs/modules
اینجا بود که تصمیم گرفتم پکیج اختصاصی خودمون رو بسازم: panicdevs/modules. با یک هدف خیلی ساده:
- کمترین overhead روی Laravel
- توسعه‌ی اختصاصی فقط برای نیازهای خودمون
- تمرکز روی پرفورمنس
لاراول در حالت خام (بدون optimize) هر درخواست رو حدود ۱۰ تا ۱۲ میلی‌ثانیه پاسخ می‌ده. وقتی optimize بشه این عدد می‌رسه به حدود ۷ تا ۹ میلی‌ثانیه.
پس هر فاصله‌ای از این محدوده، یعنی جایی از کدمون به اندازه‌ی کافی بهینه نیست. اینجا بود که panicdevs/modules تونست تفاوت جدی ایجاد کنه.
تجربه‌ی پرفورمنس (خلاصه متنی)
وقتی روی پروژه‌های واقعی تست گرفتیم، نتیجه واضح بود:
- استفاده از nwidart/laravel-modules زمان پاسخ رو به شکل قابل توجهی بالا می‌برد. مخصوصاً وقتی تعداد ماژول‌ها زیاد می‌شد، اختلاف میلی‌ثانیه‌ها تبدیل به ده‌ها میلی‌ثانیه می‌شد.
- با panicdevs/modules تونستیم همین زمان رو تا حدود ۵۰٪ کاهش بدیم.
یعنی در پروژه‌ای با ۲۰ ماژول، جایی که nwidart درخواست‌ها رو در ۳۰ تا ۵۰ میلی‌ثانیه جواب می‌داد، panicdevs/modules همون درخواست رو در ۱۲ تا ۲۰ میلی‌ثانیه پاسخ می‌داد.
توی تصویر زیر مقایسه کامل همه حالت‌ها انجام شده و میتونید با جزئیات کامل بررسی‌شون کنید.
جمع‌بندی
سه سال تجربه‌ی توسعه ساختارهای ماژولار با nwidart/laravel-modules برای ما پر از یادگیری بود. اما امروز نیاز داشتیم چیزی داشته باشیم که دقیقاً برای ما ساخته شده باشه.
راه‌حلی که هیچ قابلیت اضافه‌ای نداشته باشه و فقط روی یک چیز تمرکز کنه: پرفورمنس.
اینجا بود که panicdevs/modules متولد شد.
نه فقط به عنوان یک پکیج، بلکه به عنوان نتیجه‌ی سه سال تجربه، آزمون و خطا و تلاش برای رسیدن به سرعت بالاتر در مقیاس واقعی.
امیدوارم این تجربه برای شما هم مفید بوده باشه. تا یادداشت بعدی، بدرود :)