Deferring Work

কাজ পরে কেন করবো?

এর সবচেয়ে সম্পূর্ণ রূপ queue — কিন্তু লারাভেল আরও হালকা উপায় দেয়, যখন কাজটা “শীঘ্রই” হলেই চলে, আর queue-এর retry, persistence বা worker ইনফ্রাস্ট্রাকচার লাগে না।

Terminable Middleware

সবচেয়ে সরাসরি deferring ঘটে HTTP রেসপন্স পাঠানোর পরে। PHP প্রসেস তখনো জীবিত, কিন্তু ইউজার আর অপেক্ষা করছে না।

class LogRequest
{
    public function handle(Request $request, Closure $next)
    {
        return $next($request); // রিকোয়েস্ট চলাকালীন
    }

    public function terminate(Request $request, Response $response): void
    {
        // রেসপন্স ব্রাউজারে যাওয়ার পর
        Log::info('Request processed: ' . $request->url());
    }
}

লগিং, মেট্রিক্স সংগ্রহ বা এমন যেকোনো ক্লিনআপ, যা ইউজার যা দেখে তাকে প্রভাবিত করে না।

defer() Helper

রেসপন্সের পরে কাজ ঠেলে দেওয়ার সবচেয়ে সহজ উপায় (Laravel 11+):

use function Illuminate\Support\defer;

$order = Order::create([...]);

defer(fn () => Mail::to($order->user)->send(new Receipt($order)));

return response()->json(['ok' => true]);

রেসপন্স সাথে সাথে চলে যায়। ইমেইল পরে যায় — একই PHP প্রসেসে।

বাস্তব উদাহরণ: ভিউ কাউন্ট

public function show(Post $post)
{
    defer(fn () => $post->increment('views')); // পরে চলবে

    return view('post.show', ['post' => $post]); // ইউজার সাথে সাথে পেজ পাবে
}

রেসপন্সের পর Job Dispatch

SendEmail::dispatchAfterResponse($user);

// অথবা closure
dispatch(function () {
    // কিছু করো
})->afterResponse();

Event ও HTTP Batch Defer

Event defer করা

OrderPlaced::dispatchAfterResponse($order);

Event-এর listener ভারী হলে আর রিকোয়েস্টের সময় ফলাফল না লাগলে কাজে আসে। Job-এর মতোই এটা Dispatchable trait ব্যবহার করে — ডকুমেন্টেড নয়, কিন্তু কাজ করে।

HTTP Client Batch defer করা

একাধিক outbound HTTP রিকোয়েস্ট ব্যাচ করে রেসপন্সের পরে চালানো:

use Illuminate\Http\Client\Batch;
use Illuminate\Support\Facades\Http;

$responses = Http::batch(fn (Batch $batch) => [
    $batch->get('http://localhost/first'),
    $batch->get('http://localhost/second'),
    $batch->get('http://localhost/third'),
])->then(function (Batch $batch, array $results) {
    // সব রিকোয়েস্ট সফল...
})->defer();

defer() কল লারাভেলকে বলে — রিকোয়েস্টের সময় নয়, রেসপন্স পাঠানোর পরে ব্যাচটা চালাও।

Deferred Service Providers

লারাভেল একই আইডিয়া ফ্রেমওয়ার্ক লেভেলেও প্রয়োগ করে। কিছু service provider deferred — শুধু তখনই লোড হয় যখন কেউ সত্যিই তাদের binding রিজলভ করে:

use Illuminate\Contracts\Support\DeferrableProvider;

class RiakServiceProvider extends ServiceProvider implements DeferrableProvider
{
    public function register(): void
    {
        $this->app->singleton(Connection::class, function (Application $app) {
            return new Connection($app['config']['riak']);
        });
    }

    public function provides(): array
    {
        return [Connection::class]; // কোন binding দিলে লোড হবে
    }
}

Boot-এ সব provider লোড না করে, লারাভেল deferred provider স্কিপ করে যতক্ষণ না তাদের সার্ভিস চাওয়া হয়। Boot টাইম কমে, যে কোড একটি রিকোয়েস্টে কখনো লাগবে না তা লোড হয় না।

Defer বনাম Queue

দুটোই কাজ পরে করে। পার্থক্য তাদের গ্যারান্টিতে:

সিদ্ধান্ত নেওয়ার গাইড

1. ইউজারের কি এই ফলাফল এখনই দেখা দরকার?
   হ্যাঁ → রিকোয়েস্টের ভেতরেই করুন। না → পরের প্রশ্ন।
2. কাজটা হারিয়ে গেলে কি বড় ক্ষতি? (পেমেন্ট, ইনভয়েস, OTP)
   হ্যাঁ → Queue। না → পরের প্রশ্ন।
3. কাজটা কি কয়েক সেকেন্ডের বেশি নেয়?
   হ্যাঁ → Queue। না → defer()।
4. প্রতিটি রিকোয়েস্টের শেষে লগ/মেট্রিক্স?
   → Terminable middleware।
5. ভারী service যা সব রিকোয়েস্টে লাগে না?
   → Deferred provider।

পুরো লারাভেলে Deferring

সারসংক্ষেপ ও যাচাই

• Deferring = আগে রেসপন্স, বাকি কাজ পরে।
• defer() সবচেয়ে সহজ; terminate() প্রতিটি রিকোয়েস্টের শেষে।
• After-response কাজ একই প্রসেসে — retry বা persistence নেই।
• ক্রিটিক্যাল বা ভারী কাজ → queue।
• Deferred provider boot টাইম কমায়।

নিজেকে যাচাই করুন