‏تشیل: پلن و محدودیت فیچر برای اپ لاراولی

تو مقالهٔ Laravel News اومده که خیلی از اپ‌های لاراولی پلن‌هاشون فقط سر قیمت فرق نداره، سر «چیکار می‌تونی بکنی» هم فرق داره. مثال خودشون یه سرویس هاست پادکسته: پلن Hobby ماهی چهار آپلود اپیزود می‌ده، پلن Studio سی آپلود به‌علاوهٔ دامنهٔ اختصاصی. تشیل (Tashil)، پکیجی از Foysal Ahmed، همین پلن‌ها رو تو دیتابیس خودت ذخیره می‌کنه و حساب می‌کنه هر مشتری چقدر از هر فیچر رو خورده. نکتهٔ مهم اینه که خودش درگاه پرداخت نیست.

مشترک می‌تونه هر مدل Eloquent باشه، پس تو این مثال مدل Team قرارداد Subscribable و trait HasSubscriptions رو می‌گیره. بعد فیچرها رو می‌سازی و با یه مقدار به پلن می‌چسبونی. فیچر یا سقف‌داره (limit()) یا فقط روشن/خاموشه (boolean())، و سقف‌ها می‌تونن هر ماه ریست شن:

$uploads = Tashil::feature('episode-uploads')->name('Episode Uploads')->limit()->create();
$uploads->update(['reset_period' => ResetPeriod::Monthly]);

$hobby = Tashil::package('hobby')
    ->name('Hobby')
    ->price(12)
    ->monthly()
    ->feature($uploads, value: '4')
    ->create();

برای شمردن مصرف، useFeature() یکی به شمارنده اضافه می‌کنه و اگه تیم به سقفش رسیده باشه جای اضافه‌کردن false برمی‌گردونه. یعنی آپلود پنجم روی پلن Hobby همون‌جا رد می‌شه:

if (! $team->useFeature('episode-uploads')) {
    return back()->withErrors([
        'audio' => "You've used all {$team->featureValue('episode-uploads')} uploads this month.",
    ]);
}

چک‌کردن سقف و بالا بردن شمارنده تو یه کوئری انجام می‌شه، پس دو آپلود هم‌زمان نمی‌تونن جفتی از سقف بزنن بیرون. وقتی تیم به ۸۰٪ سقف می‌رسه هم رویداد UsageLimitWarning یه بار برای اون دوره فایر می‌شه (روی Studio با سی آپلود، سر آپلود بیست‌وچهارم) که می‌تونی باهاش ایمیل ارتقا بفرستی. اگه بعداً پلن رو عوض کنی، تیم‌هایی که قبلاً روش بودن همون سقف قبلی رو نگه می‌دارن و فقط مشترک‌های جدید مقدار تازه رو می‌گیرن.

سمت پول، اشتراک با subscribe() ساخته می‌شه و یه فاکتور در انتظار درست می‌شه؛ تا وقتی پرداخت درگاه رو با recordPayment() ثبت نکنی فعال نمی‌شه، و اگه وبهوک دو بار بیاد همون رکورد قبلی برمی‌گرده نه یه رکورد تکراری. متدهای جدا برای ارتقا، تنزل آخر دوره و کنسل‌کردن هست و دستورهای زمان‌بندی‌شده‌ش فاکتور تمدید می‌سازن، مصرف رو ریست می‌کنن و آزمایشی‌های تمام‌شده رو می‌بندن. Tashil::analytics() هم MRR، نرخ churn و نرخ تبدیل تریال رو حساب می‌کنه (نویسنده می‌گه عدد MRR تیم‌هایی که هنوز تو دورهٔ آزمایشی هستن رو هم حساب می‌کنه).

به گفتهٔ نویسنده نزدیک‌ترین گزینهٔ جایگزین Subscriptionify هست که پلن و سقف و مصرف رو داره ولی فاکتور و گزارش درآمد نمی‌سازه، در عوض می‌تونه به یه مشتری خاص سهم اضافه بده. Cashier و Laravel Polar هر کدوم به یه درگاه گره خوردن و پلن‌ها رو همون‌جا تعریف می‌کنی، و Pennant فقط فیچر رو روشن/خاموش می‌کنه بدون پلن و سقف.

نکات کلیدی:

• تشیل پرداخت نمی‌گیره؛ فقط پلن، سقف فیچر، مصرف، فاکتور و گزارش رو تو دیتابیس خودت نگه می‌داره
• سه نوع فیچر: روشن/خاموش، سقف مصرف، و قیمت‌گذاری metered
• چک سقف و افزایش شمارنده تو یک کوئری، پس race condition سقف رو رد نمی‌کنه
• رویداد UsageLimitWarning سر ۸۰٪ سقف، یک بار در هر دوره
• تغییر پلن روی مشترک‌های قدیمی اثر نمی‌ذاره؛ فقط مشترک جدید مقدار جدید رو می‌گیره
• ثبت دوبارهٔ یک پرداخت رکورد تکراری نمی‌سازه
• Tashil::analytics() برای MRR، churn سی‌روزه و نرخ تبدیل تریال
• نیاز به PHP 8.2 یا بالاتر، سازگار با لاراول ۱۰ تا ۱۳