Deployed by Laravel Cloud 🤩

https://cloudy-develop-tgs3td.laravel.cloud

App Manager UI

🚀 خوب Laravel 12 و قابلیت جدید `when()` با Closure!


توسعه‌دهنده‌های لاراول، احتمالاً با متد when() آشنا هستین، ولی می‌دونستین که توی Laravel 12 به بعد حالا می‌تونین از Closure به‌عنوان شرط استفاده کنین؟ 🤌


💡 چرا این قابلیت مهمه؟
چون باعث می‌شه شرط‌های پیچیده‌تر رو به‌شکل خواناتر و تمیزتر بنویسیم!


مثال:

$taxRate = when(
    $country === 'US',
    fn() => 0.07, // ۷٪ مالیات برای آمریکا
    fn() => 0.2   // ۲۰٪ مالیات برای سایر کشورها
);

یا برای تعیین مهلت پرداخت فاکتور:

$invoiceDueDate = when(
    fn() => $user->isVIP() && now()->isWeekday(),
    fn() => now()->addDays(10), // کاربران VIP ده روز اضافه دارند
    fn() => now()->addDays(5)   // کاربران عادی پنج روز اضافه دارند
);

✅ نتیجه؟ کد تمیزتر، خواناتر و انعطاف‌پذیرتر! 😎

@panicdev

🛠 چطور `defer` در لاراول کار می‌کند؟

در نگاه اول، ممکنه فکر کنین که defer یه چیزی شبیه صف‌ها (queues) هست، ولی در واقع اینطور نیست!

لاراول از طریق Middleware مخصوص به نام InvokeDeferredCallbacks پردازش‌های defer رو بعد از ارسال پاسخ اجرا می‌کنه.

🔍 پشت صحنه اجرای defer
📌 لاراول متدی به نام terminate داره که بعد از ارسال پاسخ، توابع defer ذخیره‌شده رو اجرا می‌کنه:

class InvokeDeferredCallbacks
{
    public function terminate(Request $request, Response $response)
    {
        Container::getInstance()
            ->make(DeferredCallbackCollection::class)
            ->invokeWhen(fn ($callback) => $response->getStatusCode() < 400 || $callback->always);
    }
}

✅ یعنی اگه پاسخ موفقیت‌آمیز باشه (کد ۲xx یا ۳xx)، توابع defer اجرا می‌شن!


🤔 چطور لاراول بعد از ارسال پاسخ، defer رو اجرا می‌کنه؟
شاید عجیب باشه، چون درخواست کاربر تموم شده و پاسخ ارسال شده، ولی چطور defer هنوز اجرا می‌شه؟ 🤔

✅ دلیلش اینه که PHP روی FastCGI اجرا می‌شه که اجازه می‌ده پردازش بعد از ارسال پاسخ هم باز بمونه و اجرا بشه!

📌 ترتیب اجرای defer در لاراول

1️⃣ کاربر / رو باز می‌کنه.
2️⃣ لاراول کال‌بک defer رو ذخیره می‌کنه (ولی اجرا نمی‌کنه).
3️⃣ پاسخ (response) فوراً به کاربر نمایش داده می‌شه.
4️⃣ (پردازش PHP هنوز باز هست) 🚀
5️⃣ لاراول متد terminate رو اجرا می‌کنه.
6️⃣ و`defer` اجرا شده و عملیات در پس‌زمینه پردازش می‌شه.
7️⃣ بعد PHP این کد رو بدون تأخیر در نمایش پاسخ، در پس‌زمینه اجرا می‌کنه.

✅ این دقیقاً مثل queue نیست ولی شبیه اجراهای پس‌زمینه‌ای هست که بعد از ارسال پاسخ، وظایف رو اجرا می‌کنه!


@panicdev

همه چی عالی !
جای شما خالی ....

بحث #دیتابیس #mysql

داشتم یک مطلبی میخوندم ،‌ به یک دستوری اشاره کرد به اسم ANALYZE کنجکاو شدم که بدونم به چه کاری میاد و باهاش میشه چیکار کرد .

مواردی که تونستم در بیارم زیاد نبود ،‌
ولی یه خلاصه و چند مورد از سناریو هایی که بهتر هست از این دستور استفاده کنیم رو بخوام بگم. این هستش که :

دستور ANALYZE TABLE یک دستور مفید برای به‌روزرسانی آمار داخلی جدول که به بهینه‌سازی اجرای کوئری‌ها کمک میکنه !

حالا مواردی که اشاره شده بود برای استفاده از این دستور این ها هستش :


✅زمانی که بعد از تغییرات بزرگ در داده‌ها، کوئری‌ها کند شدند.
✅ زمانی که بعد از افزودن ایندکس، ایندکس استفاده نمی‌شود.
✅ زمانی که MySQL به جای استفاده از ایندکس، کل جدول را اسکن می‌کند.
✅ زمانی که بعد از بازیابی بکاپ، سرعت پایگاه داده کاهش یافته است.
✅ زمانی که جدول را با OPTIMIZE TABLE بهینه کرده‌اید.



✴️ نکات و best practices
🔹 تحلیل منظم: به‌طور مرتب دستور ANALYZE TABLE را روی جداولی که تغییرات داده‌ای زیادی دارند اجرا کنید تا عملکرد کوئری‌ها حفظ شود.

🔹 پایش عملکرد: این دستور را به‌عنوان بخشی از نگهداری دوره‌ای اجرا کنید، به‌ویژه پس از عملیات حجیم روی داده‌ها، تا آمارها به‌روز بمانند.

🔹 توجه به سربار پردازشی: در نظر داشته باشید که ANALYZE TABLE ممکن است هنگام تجزیه و تحلیل، جداول را قفل کند که می‌تواند بر عملیات همزمان تأثیر بگذارد. بهتر است آن را در ساعات کم‌بار اجرا کنید تا اثرات منفی کاهش یابد.

🔹 سازگاری با موتورهای ذخیره‌سازی: این دستور در موتورهای ذخیره‌سازی مانند InnoDB و MyISAM پشتیبانی می‌شود اما ممکن است برای همه موتورهای ذخیره‌سازی قابل استفاده نباشد. قبل از استفاده، از سازگاری آن اطمینان حاصل کنید.

🔹 اجرای خودکار: در برخی شرایط، MySQL ممکن است به‌طور خودکار ANALYZE TABLE را اجرا کند، اما اجرای دستی آن تضمین می‌کند که آمارها به‌روز باشند.

🔹 ارزیابی اثربخشی: برای بررسی تأثیر ANALYZE TABLE، برنامه‌های اجرای کوئری (Execution Plan) را قبل و بعد از آن مقایسه کنید. اگر موتور ذخیره‌سازی شما از آن پشتیبانی نمی‌کند یا باعث افت عملکرد قابل‌توجهی می‌شود، از اجرای آن خودداری کنید.


➕ نکته اضافه :

دستور EXPLAIN ANALYZE در MySQL هم داریم که اطلاعات دقیقی درباره‌ی برنامه‌ی اجرای کوئری میده ،‌ از جمله جزئیات مربوط به تصمیمات بهینه‌ساز، روش‌های دسترسی و هزینه‌های تخمینی. برخلاف EXPLAIN که فقط طرح اجرای کوئری را بدون اجرای واقعی آن نمایش میده EXPLAIN ANALYZE کوئری را اجرا میکنه و آمار زمان اجرا را ارائه می‌کند. این ویژگی یک ابزار ارزشمند برای تحلیل عملکرد کوئری‌ها و شناسایی نقاط قابل بهبود .


منابع که شاید برای مطالعه بیشتر دوست داشته باشید .

- لینک
- لینک
-لینک


#تجربه

خیلی دوست دارم کسانی که تجربه کار با این کامند داشتند ، تجربیاتشون رو با ما به اشتراک بگذارند . تاثیراتی که روی دیتابیس و کوئری ها بوده به چه صورتی بود و چقدر تائیر گذار داشته ، آیا این رو به صورت دوره ای schedule کردن ؟
ایا تجربه بدی هم ازش داشتن .
آیا اطلاعات بیشتری یا سناریو هایی بیشتری میشناسید که از این کامند استفاده کنیم ؟


با اشتراک گذاری اطلاعاتتون مارا خوشحال کنید .
سپاس

@panicdev

🚀 پکیج GPDF یک پکیج PHP/Laravel برای تولید PDFهای عربی، راست‌چین (RTL) و چندزبانه است که به‌صورت بومی از ۱۷ فونت عربی داخلی پشتیبانی می‌کند. این پکیج با پشتیبانی از فضای ابری S3 بر اساس DomPDF توسعه یافته و مشکلات رندر متن عربی را حل کرده است، در عین حال قابلیت‌های مدرنی را برای اسناد، فاکتورها و گزارش‌ها اضافه می‌کند.


https://github.com/omaralalwi/Gpdf



#package

@panicdev

#نکات دیتابیسی

شما یه جدول درست میکنی که تراکنش های هر کاربر رو ذخیره میکنه
مثلا میگه کاربر شماره X امده ۲۰ دلار در تاریخ فلان تراکنش انجام داده .

بعد اینو به زیبایی با یک میلیون رکورد پر میکنید . به وسیله PROCEDURE عزیز .

حالا نکته اینه که میخوایم ببینیم یه کوئری مثل این چقدر زمان لازم داره .
تا به ما بگه که هر کاربر در مجموع چقدر تراکنش داشته
به صورت یک گزارش .

 
SELECT user_id, SUM(amount) AS total_amount
FROM transactions
GROUP BY user_id;

خوب این کوئری ظاهرا ۱۵۰ ثانیه زمان لازم داره


چیکار کنیم ۱۵۰ ثانیه بشه ۲ ثانیه

@panicdev

گفتند که
اگر به جدول یه index برای user_id در نظر بگیرید

از ۱۵۰ ثانیه میشه ۸۰ ثانیه .

خوبست ،‌ دیگه چیکار کنیم ؟

@panicdev

گفتند که بیایم بر اساس transaction_date
جدول و پارتیشن بندی کنیم .

اینجوری سرعت کوئری از ۸۰ میرسه به ۲۰ .

من خودم روی صحت این قضیه شک دارم . چون که برای کوئری کلی مثل این ( گزارش تمام کاربر ها در تمام سال هارو بخوایم بگیریم ). نباید تاثیر خاصی داشته باشه .

ولی در عوض اگه بگیم گزارش همه کاربر هارو برای سال ۲۰۲۱ بده . خیلی باید تاثیر گذار و سریع باشه .


نظر شما چیست ؟

@panicdev

خوبه ،‌ دوستان اشارات خوبی کردن ، مچکریم

بعله ،‌ میریم سراغ Materialized

اینجا میگه یه جدول جدا میکنی روی
user_transaction_sums

بعد یه cron درست میکنی برای اونت
update_user_sums

که این میاد scheduler میکنه ،‌ هر یک ساعت یکبار ، محاسبات رو مجدد روی جدول انجام بده

و جدول شبه Materialized رو براتون آپدیت کنه .


الان میتونید از این کوئری بگیرید در حد ۲ ثانیه خروجی رو ببینید.

@panicdev