| کانال توسعه‌دهندگان لاراول |

⚡️ Eager Loading برای جلوگیری از N+1 در لاراول

خیلی وقت‌ها کندی عجیب در صفحه‌هایی دیده می‌شود که لیست‌ها را با روابط Eloquent نمایش می‌دهند؛ ریشه‌اش معمولاً مشکل معروف N+1 Query است. خوشبختانه با یک تغییر کوچک در کوئری می‌شود کلی بهبود گرفت. 🚀

فرض کن هر Post یک User دارد و موقع لیست پست‌ها، نام نویسنده را هم نمایش می‌دهی. اگر ساده بنویسی:

$posts = Post::all();

foreach ($posts as $post) {
    echo $post->user->name;
}

اینجا یک کوئری برای گرفتن همه پست‌ها اجرا می‌شود و بعد برای هر پست یک کوئری جدا برای گرفتن user؛ یعنی N+1 کوئری 😬

به‌جاش از eager loading استفاده کن:

$posts = Post::with('user')->get();

foreach ($posts as $post) {
    echo $post->user->name;
}

حالا فقط دو کوئری اجرا می‌شود: یکی برای پست‌ها، یکی برای همه کاربران مرتبط. هم تمیزتر، هم سریع‌تر، مخصوصاً روی دیتابیس‌های سنگین. 🔥

مرجع: Laravel Docs - Eager Loading

این الگو را در همه لیست‌ها و APIهای پرترافیک پروژه استفاده کن و تاثیرش را در لاگ و پروفایلینگ ببین. 😉

🔖 #Laravel #PHP #لاراول #Laravel #Eloquent #Performance #Eager_Loading #N+1

👤 Developix

💎 Channel: @DevelopixLaravel

در کد زیر داخل یک Controller تلاش شده روی مدل User فیلتر اعمال و نتیجه را paginate کند، اما از یک Anti Pattern جدی استفاده شده که می‌تواند باعث بروز باگ و رفتار غیرمنتظره شود:

use App\Models\User;
use Illuminate\Support\Facades\DB;

class UserController extends Controller
{
    public function index()
    {
        $users = User::all();

        $users = DB::table('users')
            ->where('is_active', true)
            ->paginate(15);

        return view('users.index', compact('users'));
    }
}

در این مثال ابتدا از Eloquent Model و بعد از آن مستقیماً از DB::table برای همان جدول استفاده شده است و همین موضوع باعث می‌شود مزایای Eloquent (مثل Accessor ها، Mutator ها، Scope ها و ...) دور زده شوند.

چه چیزی باید در این کد اصلاح شود تا فقط با استفاده از Eloquent مدل User، لیست کاربران فعال به‌صورت صحیح paginate شود؟

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

در نمونه‌کد بالا، در حالت اول تمام رکوردها از دیتابیس خوانده می‌شوند و بعد با استفاده از Collection فیلتر می‌گردند که باعث افزایش شدید مصرف مموری و کاهش کارایی در جدول‌های بزرگ می‌شود. در حالت دوم با تعریف یک Query Scope، منطق فیلتر مستقیماً روی کوئری SQL اعمال می‌شود و فقط داده‌های لازم از دیتابیس لود می‌گردند.

شما در پروژه‌های Laravel خود به جای فیلتر کردن روی Collection بعد از get() یا all()، می‌توانید با استفاده از Local Scopeها منطق فیلتر را به لایه دیتابیس منتقل کنید؛ این کار علاوه بر خوانایی بهتر کد، باعث کاهش I/O دیتابیس، کاهش مصرف مموری و بهبود محسوس سرعت در کوئری‌های سنگین می‌شود.

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

در نمونه‌کد بالا برای بدست آوردن تعداد کامنت‌های هر پست از یک حلقه روی کالکشن استفاده شده که باعث بروز مشکل کلاسیک N+1 Query و افزایش شدید تعداد کوئری‌ها در Laravel می‌شود. در نسخه‌ی اصلاح‌شده با استفاده از متد withCount() روی Eloquent Query Builder، تمام شمارش‌ها در یک یا چند کوئری بهینه انجام شده و هم کارایی و هم زمان پاسخ‌دهی در سناریوهایی با تعداد زیاد پست و کامنت به‌طور محسوسی بهتر می‌شود.

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

در کد زیر می‌خواهیم لیست Categoryها را همراه با تعداد Postهای منتشرشده (status = 'published') بگیریم:

$categories = Category::query()
    ->withCount('posts')
    ->get();

foreach ($categories as $category) {
    echo $category->name.": ".$category->posts
        ->where('status', 'published')
        ->count()."\n";
}

در این تکه کد هم از withCount استفاده شده و هم داخل حلقه روی رابطه posts فیلتر زده شده است که می‌تواند باعث N+1 Query و منطق اشتباه شود.

در مدل Category رابطه به این صورت تعریف شده است:

public function posts()
{
    return $this->hasMany(Post::class);
}

چه چیزی باید در این کد اصلاح شود تا تعداد Postهای منتشرشده برای هر Category به‌صورت بهینه و درست از دیتابیس گرفته شود؟

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

ویراک کلود | تجربه‌ی ابری بدون محدودیت ☁️🚀

🎁 ۲۰٪ شارژ هدیه روی اولین واریزی

مزیت‌هایی که واقعاً فرق می‌سازن:
⚡️ پهنای باند 980 مگ
🌐با IP مازاد
⏱️ راه‌اندازی فوری
💳 پرداخت ساعتی
🛡 پشتیبانی ۲۴/۷

💬 هر سوالی داشتی، تیم ما کنارتـه
✅ مناسب استارتاپ‌ها، تیم‌های فنی، تا سازمان‌های بزرگ

همین الان شروع کن و با حداکثر منابع، سریع‌تر رشد کن 👇🏻

📞 تماس سریع: 02191555530
🔗 https://virakcloud.com

ساخت Service Layer در لاراول برای تمیز نگه‌داشتن Controllerها 🧼

یکی از شایع‌ترین مشکلات در پروژه‌های لاراول این است که Controllerها پر از منطق تجاری (Business Logic) می‌شوند؛ نتیجه‌اش کلاس‌های چاق، سخت‌قابل‌تست و به‌هم‌ریخته است.

یک راه‌حل استاندارد و پرکاربرد، استفاده از Service Layer است؛ یعنی منطق اصلی را از Controller بیرون بکشیم و داخل Serviceهای مجزا قرار بدهیم. این رویکرد در پروژه‌های متوسط و بزرگ به‌شدت روی مقیاس‌پذیری و تست‌پذیری تاثیر مثبت دارد. 💡

مثال ساده: ثبت کاربر با منطق داخل Controller (کد ناخوانا و شلوغ)

class RegisterController extends Controller
{
    public function store(Request $request)
    {
        $data = $request->validate([
            'name' => 'required',
            'email' => 'required|email|unique:users,email',
            'password' => 'required|min:8',
        ]);

        $user = User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => Hash::make($data['password']),
        ]);

        event(new Registered($user));

        Mail::to($user->email)->send(new WelcomeMail($user));

        return response()->json($user, 201);
    }
}

همه‌چیز در یک متد جمع شده؛ اگر جای دیگری هم نیاز به همین منطق باشد، تکرار شروع می‌شود و تست‌نویسی سخت خواهد شد.

این منطق را به یک UserService منتقل می‌کنیم:

namespace App\Services;

use App\Models\User;
use App\Mail\WelcomeMail;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Mail;
use Illuminate\Auth\Events\Registered;

class UserService
{
    public function register(array $data): User
    {
        $user = User::create([
            'name' => $data['name'],
            'email' => $data['email'],
            'password' => Hash::make($data['password']),
        ]);

        event(new Registered($user));

        Mail::to($user->email)->send(new WelcomeMail($user));

        return $user;
    }
}

حالا Controller فقط نقش هماهنگ‌کننده دارد و بسیار تمیزتر است:

class RegisterController extends Controller
{
    public function __construct(private UserService $userService) {}

    public function store(RegisterRequest $request)
    {
        $user = $this->userService->register($request->validated());

        return response()->json($user, 201);
    }
}

نکات مهم ✅

• Dependency Injection از Service Container لاراول استفاده می‌کند؛ نیازی به new کردن دستی کلاس‌ها نیست.

• با این ساختار، Unit Test برای UserService بدون نیاز به Request یا HTTP بسیار ساده‌تر می‌شود.

• Controllerها فقط ورودی/خروجی HTTP را مدیریت می‌کنند؛ منطق تجاری در Service قرار می‌گیرد و پروژه ساختار تمیزتر و قابل‌گسترش‌تری پیدا می‌کند.

برای مطالعه بیشتر، مستندات رسمی Service Container لاراول:
https://laravel.com/docs/container

قدم‌به‌قدم هر منطق شلوغی را از Controller جدا و به Serviceها منتقل کنید؛ بعد از مدتی، معماری نرم‌افزار قابل‌حفاظت‌تر و توسعه ویژگی‌های جدید لذت‌بخش‌تر می‌شود. 🚀

🔖 #Laravel #PHP #لاراول #Laravel #Service_Layer #Clean_Code #Architecture #PHP

👤 Developix

💎 Channel: @DevelopixLaravel

🔍 در مثال بالا در نسخه‌ی اول برای گرفتن «پست‌های محبوب کاربر» روی Eloquent Collection بعد از get() فیلتر انجام شده و عملاً همه‌ی رکوردها از دیتابیس خوانده می‌شوند. این کار روی جدول‌های بزرگ می‌تواند باعث افزایش شدید مصرف مموری و زمان پاسخ شود. در نسخه‌ی دوم با استفاده از Query Builder و انتقال شرط به خودِ کوئری، فیلتر روی سطح دیتابیس انجام می‌شود و فقط داده‌های موردنیاز لود خواهند شد.

به‌جای فیلتر کردن بعد از get() روی Collection، بهتر است تا حد امکان شرط‌ها را قبل از اجرا شدن کوئری با متدهایی مثل where()، whereHas() و ... روی خود Query اعمال کنید تا هم مصرف مموری کم شود و هم سرعت پاسخ‌دهی API در سناریوهای پرفشار بهتر شود.

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

✳️ یک قطعه کد Eloquent در Laravel را در نظر بگیرید:

در این کد، ما در حال ساختن یک query روی مدل User هستیم و از local scope‌ها و یک macro روی Builder استفاده می‌کنیم:

<?php

use App\Models\User;
use Illuminate\Database\Eloquent\Builder;

Builder::macro('activeEmails', function () {
    return $this->whereNotNull('email_verified_at')
                ->where('active', true)
                ->pluck('email')
                ->toArray();
});

// در مدل User فرض کنید این scope تعریف شده:
// public function scopeAdmin(Builder $query)
// {
//     return $query->where('role', 'admin');
// }

$query = User::query();

$admins = $query->admin();

$all = $query->get();

$emails = $admins->activeEmails();

var_dump($all->count(), $admins->count(), $emails);

خروجی نهایی اجرای این اسکریپت (خروجی دقیق var_dump) چه خواهد بود؟

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

در کد زیر یک Anti Pattern خطرناک در Eloquent دیده می‌شود که می‌تواند باعث N+1 Query و مصرف زیاد منابع شود:

چه تغییری باید در این کد بدهید تا مشکل N+1 Query برطرف شود و کوئری‌ها بهینه شوند؟

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

⭕️ ویراک کلود
زیرساختی مطمئن برای کسب و کارهای آنلاین
🎁 20% شارژ بیشتر روی اولین واریزی
⚡️با کد معرف: 10%  شارژ برای شما و 10% برای دوستتان!

🔘با IPv6 رایگان
🔘با IP مازاد
🔘تست رایگان 2 روزه
🔘فایروال اختصاصی
🔘با API برای حرفه‌ای ها
🔘پشتیبانی 24 ساعته
🔘آپلود رایگان


📞 همین حالا با ما تماس بگیرید و این فرصت فوق‌العاده رو از دست ندید!
🔻02191555530
🌐Virakcloud.com

خیلی وقت‌ها توی پروژه‌های Laravel بی‌دلیل همهٔ ستون‌های جدول رو لود می‌کنیم، درحالی‌که فقط ۲–۳ تا فیلد لازم داریم. همین کار ساده می‌تونه رم، زمان اجرا و حجم پاسخ API رو بی‌خودی سنگین کنه. 🚀

به‌جای این:

$users = User::where('is_active', true)->get();

فقط همون فیلدهایی که لازم هست رو بگیر:

$users = User::where('is_active', true)
    ->select(['id', 'name', 'email'])
    ->get();

حالا اگه رابطه هم داری (مثلاً posts)، باز هم می‌شه کم‌حجم نگهش داشت:

$users = User::with(['posts:id,user_id,title'])
    ->select(['id', 'name'])
    ->get();

✅ نکته‌ها:
- ستون کلید خارجی (مثلاً user_id) حتماً توی select رابطه بیاد، وگرنه Eloquent نمی‌تونه رابطه رو درست مپ کنه.
- برای APIها و لیست‌های بزرگ (لیست کاربران، محصولات، گزارش‌ها) این کار واقعاً روی Performance تاثیر محسوس داره.
- موقع debug می‌شه موقتاً select رو برداشت تا مطمئن شد چیزی جا نمونده، بعد دوباره بهینه‌اش کرد. 😉

این عادت کوچیک که همیشه توی Queryها به select فکر کنی، جلوی کلی Memory Leak ریز و Query سنگین توی پروژه‌های بزرگ رو می‌گیره و API تمیزتر و سریع‌تری تحویل می‌ده. 💡

برای جزئیات بیشتر مستند رسمی Laravel در مورد Eloquent & Query Builder:
https://laravel.com/docs/11.x/queries#select-statements

🔖 #Laravel #PHP #لاراول #Laravel #Eloquent #Performance #Query #select

👤 Developix

💎 Channel: @DevelopixLaravel

🔎 در قطعه‌کد بالا، در روش اول برای محاسبه آمار سفارش‌ها، هر بار که روی یک user لوپ می‌زنیم، چندین کوئری جدید به دیتابیس اجرا می‌شود (مشکل N+1 Query) و همچنین محاسباتی مثل مجموع مبالغ سفارش‌های تکمیل‌شده را داخل PHP انجام می‌دهیم. در روش دوم با استفاده از Aggregation Query در خود دیتابیس و به‌کارگیری Eager Loading و توابعی مثل withSum و withCount، هم تعداد کوئری‌ها کاهش پیدا می‌کند، هم فشار زیادی از روی PHP برداشته می‌شود و کارایی سیستم در سناریوهایی مثل گزارش‌گیری روی تعداد زیاد کاربر و سفارش، به‌طور محسوسی بهتر می‌شود. به‌نظر شما در پروژه‌های واقعی لاراول، چه زمانی بهتر است این نوع محاسبات را از سطح PHP به سطح دیتابیس منتقل کنیم تا هم پیچیدگی کد کم شود و هم Performance بالاتر برود؟

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel

برای مدیریت نقش‌ها و دسترسی‌ها در اپ‌های متوسط و بزرگ لاراول، پکیج spatie/laravel-permission تقریبا استاندارد صنعت شده. به‌جای ifهای تو در تو و چک‌کردن role در هر کنترلر، یک سیستم تمیز و قابل‌گسترش می‌دهد. 🔐

چند مزیت مهم:

• تعریف role و permission در دیتابیس، نه هاردکد 🧱
• متدهای آماده روی مدل User مثل: hasRole ،can
• Middleware برای محدود کردن routeها
• هماهنگ با Gate/Policy خود لاراول

نصب و راه‌اندازی سریع:

composer require spatie/laravel-permission

php artisan vendor:publish \
  --provider\=\"Spatie\\Permission\\PermissionServiceProvider\"
php artisan migrate

// در مدل User:
use Spatie\\Permission\\Traits\\HasRoles;

class User extends Authenticatable
{
    use HasRoles;
}

// استفاده در کد:
$user->assignRole('admin');
if ($user->can('edit articles')) {
    // ...
}

در پروژه‌های تیمی، این پکیج جلوی کلی if بی‌منطق و duplication را می‌گیرد و مدیریت پنل ادمین، سطح دسترسی API و نقش‌های مختلف (admin, editor, support) را تمیز می‌کند. ✨

مستندات رسمی:
Docs
GitHub

امتحانش در یک پروژه واقعی حس خوبی از نظم و کنترل روی Authorization می‌دهد. 😉

🔖 #Laravel #PHP #لاراول #Laravel #spatie #laravel_permission #PHP #Authorization #Role #Permission

👤 Developix

💎 Channel: @DevelopixLaravel

پکیج امروز: Spatie Laravel Ray 🔍
یک دیباگر زنده که لاگ‌ها و query و jobها را به اپ دسکتاپ Ray می‌فرستد؛ مخصوص وقتی که var_dump و dd کل صفحه را منفجر می‌کنند 🙂

به چه درد می‌خورد؟
• دیدن لاگ‌ها، queryها، exceptionها به‌صورت لحظه‌ای
• گروهبندی، فیلتر و استایل‌دهی به لاگ‌ها
• دیباگ queue job، event، mail و حتی cache

نصب

composer require spatie/laravel-ray --dev
php artisan vendor:publish \
  --provider\="Spatie\LaravelRay\RayServiceProvider"

نمونه استفاده در کنترلر

use Spatie\LaravelRay\Ray;

public function index()
{
    ray('Load products');

    $products = Product::with('category')
        ->where('active', true)
        ->get();

    ray($products)->blue();

    return view('products.index', compact('products'));
}

برای پروژه‌های بزرگ لاراول که لاگ‌خوانی در فایل سخت می‌شود، Ray جریان دیباگ را خیلی تمیز و قابل‌ردیابی می‌کند. ارزش دارد یک‌بار روی یک feature واقعی تست شود و تنظیماتش را مطابق نیاز تیم‌تان شخصی‌سازی کنید 🚀

لینک‌ها:
GitHub
Docs

🔖 #Laravel #PHP #لاراول #Laravel #PHP #Spatie #Debugging #Laravel_Ray

👤 Developix

💎 Channel: @DevelopixLaravel

🔎 سوال برای توسعه‌دهندگان Laravel / PHP

خروجی اجرای این کد PHP چیست؟

به تفاوت بین type casting و type juggling در PHP و تاثیر آن روی کلیدهای آرایه دقت کنید.

$data = [
    "01" => "first",
    1    => "second",
    true => "third",
    "1"  => "fourth",
];

var_dump($data);

خروجی کامل تابع var_dump را بنویسید (ساختار آرایه و مقادیر آن).

🔖 #Laravel #PHP #لاراول

👤 Developix

💎 Channel: @DevelopixLaravel