𝗟𝗮𝗿𝗮𝘃𝗲𝗹 में 𝗘𝘃𝗲𝗻𝘁-𝗗𝗿𝗶𝘃𝗲𝗻 𝗗𝗲𝗰𝗼𝘂𝗽𝗹𝗶𝗻𝗴 में महारत हासिल करना

आपके Laravel controllers अक्सर business logic के ढेर बन जाते हैं।

आप एक साधारण registration flow के साथ शुरुआत करते हैं। जल्द ही, आप एक ही method में email notifications, Slack alerts, audit logs, और API calls जोड़ देते हैं। इससे एक fat controller बन जाता है।

Fat controllers आपके code को नाजुक (fragile) बना देते हैं। उन्हें test करना कठिन होता है। वे Single Responsibility Principle का उल्लंघन करते हैं।

इसे ठीक करने के लिए आपको RabbitMQ जैसे जटिल tools की आवश्यकता नहीं है। Laravel में एक built-in event system है जो अधिकांश जरूरतों के लिए पर्याप्त है।

Tight coupling के साथ समस्या: यदि कोई newsletter API धीमी है, तो आपका user registration भी धीमा हो जाता है। यदि कोई mail service विफल हो जाती है, तो पूरी request विफल हो जाती है।

समाधान: Event-Driven Architecture.

Events एक मध्य परत (middle layer) के रूप में कार्य करते हैं। आपका controller एक action की घोषणा करता है। Listeners उस action पर स्वतंत्र रूप से प्रतिक्रिया करते हैं।

एक lean controller ऐसा दिखता है:

public function register(RegisterRequest $request)
{
    $user = User::create($request->validated());

    UserRegistered::dispatch($user);

    return response()->json(['message' => 'Success'], 201);
}

अब controller केवल data persistence को संभालता है। इसे side effects से कोई सरोकार नहीं है।

आपको तीन प्रमुख लाभ मिलते हैं:

• Performance: उपयोगकर्ताओं को तुरंत response मिलता है। भारी कार्य ShouldQueue interface का उपयोग करके background में चलते हैं।
• Resilience: यदि कोई service डाउन है, तो listener मुख्य application को बाधित किए बिना कार्य को पुनः प्रयास (retry) कर सकता है।
• Extensibility: आप एक नया listener जोड़कर push notifications जैसी नई सुविधाएँ जोड़ सकते हैं। आपको मूल controller को छूने की आवश्यकता नहीं होती है।

पालन करने योग्य सर्वोत्तम अभ्यास (Best practices):

• Side effects पर ध्यान दें: post-processing के लिए events का उपयोग करें। उन्हें उस core logic के लिए उपयोग न करें जिसे तुरंत होना चाहिए।
• वर्णनात्मक नामों (descriptive names) का उपयोग करें: OrderPlaced या UserRegistered जैसे past-tense नामों का उपयोग करें। यह दर्शाता है कि action पहले ही हो चुका है।
• अत्यधिक abstraction से बचें: यदि code का कोई हिस्सा सरल है और केवल एक ही स्थान पर उपयोग किया जाता है, तो event के बजाय function call बेहतर है।

Database परिवर्तनों के लिए Eloquent Observers का उपयोग करें। Business actions के लिए Events का उपयोग करें।

Events में refactoring करना durability (स्थायित्व) के बारे में है। यह आपके code को debug करना आसान और test करना तेज़ बनाता है।

आज ही अपने controller में किसी एक शोर मचाने वाले (noisy) side effect को चुनें और उसे listener में स्थानांतरित करें।

इस sandbox उदाहरण को आज़माएँ: https://onlinephp.io/c/1f7b2

Fat Controllers से आगे: Laravel में Event-Driven Decoupling में महारत हासिल करना

Laravel development की दुनिया में, हम अक्सर एक आम समस्या का सामना करते हैं: "Fat Controller"। जैसे-जैसे applications बढ़ते हैं, controllers में अधिक से अधिक logic जमा होने लगता है, जिससे वे bloated और maintain करने में कठिन हो जाते हैं।

Fat Controllers क्या हैं?

एक Fat Controller वह controller है जो बहुत सारी responsibilities संभालता है। Application के flow को direct करने के बजाय, यह business logic चलाने, emails भेजने, third-party APIs के साथ interact करने और बहुत कुछ करने लगता है।

Fat Controllers के साथ समस्या क्या है?

1. Single Responsibility Principle (SRP) का उल्लंघन: एक controller को केवल request को handle करने और response देने के लिए जिम्मेदार होना चाहिए।
2. Test करना कठिन: सब कुछ करने वाले controller का test करना एक nightmare हो सकता है।
3. Maintain करना मुश्किल: जैसे-जैसे logic बढ़ता है, controller एक "God Object" बन जाता है जिसे समझना और modify करना कठिन होता है।
4. Low Reusability: Controller के भीतर फंसा हुआ logic application के अन्य हिस्सों में आसानी से reuse नहीं किया जा सकता है।

समाधान: Event-Driven Decoupling

इसे हल करने के लिए, हम Laravel के built-in Event और Listener system का उपयोग कर सकते हैं। यह हमें मुख्य action (जैसे user बनाना) को उसके side effects (जैसे welcome email भेजना) से decouple करने की अनुमति देता है।

यह कैसे काम करता है

Controller में सब कुछ करने के बजाय, controller बस एक event "fire" करता है। विभिन्न "listeners" फिर उस event को "listen" करते हैं और अपने विशिष्ट कार्य करते हैं।

पहले: The Fat Controller

public function store(Request $request)
{
    $user = User::create($request->all());

    // Welcome email भेजना
    Mail::to($user->email)->send(new WelcomeMail($user));

    // Default roles assign करना
    $user->assignRole('customer');

    // Admin को notify करना
    Notification::send($admin, new NewUserRegistered($user));

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

बाद में: The Decoupled Approach

1. Event बनाएं

php artisan make:event UserRegistered

2. Listeners बनाएं

php artisan make:listener SendWelcomeEmail --event=UserRegistered
php artisan make:listener AssignDefaultRole --event=UserRegistered
php artisan make:listener NotifyAdmin --event=UserRegistered

3. Refactored Controller

public function store(Request $request)
{
    $user = User::create($request->all());

    // Event fire करें
    event(new UserRegistered($user));

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

Event-Driven Architecture के लाभ

• Decoupling: Controller को emails या roles के बारे में जानने की आवश्यकता नहीं है।
• Scalability: आप controller को बदले बिना और अधिक listeners जोड़ सकते हैं।
• Testability: आप प्रत्येक listener का isolation में test कर सकते हैं।
• Asynchronous Processing: Listeners को background में process करने के लिए queue में भेजा जा सकता है।