Tag: laravel

  • Contoh Implementasi Observer di Laravel 12: Auto-Slug, Audit Trail, dan Cache

    Artikel ini melanjutkan penjelasan konsep Observer di Laravel 12 dengan studi kasus implementasi lengkap: sistem audit trail dan auto-slug generation.

    Studi Kasus 1: Auto-Slug Generation

    Masalah umum: setiap kali artikel dibuat atau diupdate, slug harus di-generate dari title. Tanpa Observer, logika ini tersebar di berbagai controller.

    Dengan Observer, cukup satu tempat:

    <?php
    
    namespace AppObservers;
    
    use AppModelsArticle;
    use IlluminateSupportStr;
    
    class ArticleObserver
    {
        public function creating(Article $article): void
        {
            $article->slug = $this->generateUniqueSlug($article->title);
        }
    
        public function updating(Article $article): void
        {
            if ($article->isDirty('title')) {
                $article->slug = $this->generateUniqueSlug($article->title, $article->id);
            }
        }
    
        private function generateUniqueSlug(string $title, ?int $excludeId = null): string
        {
            $slug  = Str::slug($title);
            $query = Article::where('slug', $slug);
    
            if ($excludeId) {
                $query->where('id', '!=', $excludeId);
            }
    
            if (!$query->exists()) {
                return $slug;
            }
    
            // Tambah angka kalau slug sudah ada
            $counter = 1;
            while (Article::where('slug', "{$slug}-{$counter}")
                          ->when($excludeId, fn ($q) => $q->where('id', '!=', $excludeId))
                          ->exists()) {
                $counter++;
            }
    
            return "{$slug}-{$counter}";
        }
    }

    Studi Kasus 2: Audit Trail Otomatis

    Rekam semua perubahan pada model penting, berguna untuk compliance, debugging, atau fitur “lihat riwayat perubahan”:

    <?php
    
    namespace AppObservers;
    
    use AppModelsArticle;
    use AppModelsAuditLog;
    
    class ArticleObserver
    {
        public function created(Article $article): void
        {
            $this->log('created', $article, [], $article->getAttributes());
        }
    
        public function updated(Article $article): void
        {
            $this->log('updated', $article, $article->getOriginal(), $article->getChanges());
        }
    
        public function deleted(Article $article): void
        {
            $this->log('deleted', $article, $article->getAttributes(), []);
        }
    
        private function log(string $action, Article $article, array $old, array $new): void
        {
            AuditLog::create([
                'user_id'     => auth()->id(),
                'model_type'  => Article::class,
                'model_id'    => $article->id,
                'action'      => $action,
                'old_values'  => $old,
                'new_values'  => $new,
                'ip_address'  => request()->ip(),
            ]);
        }
    }

    Model AuditLog:

    Schema::create('audit_logs', function (Blueprint $table) {
        $table->id();
        $table->foreignId('user_id')->nullable()->constrained()->nullOnDelete();
        $table->string('model_type');
        $table->unsignedBigInteger('model_id');
        $table->string('action'); // created, updated, deleted
        $table->json('old_values')->nullable();
        $table->json('new_values')->nullable();
        $table->string('ip_address')->nullable();
        $table->timestamp('created_at');
    
        $table->index(['model_type', 'model_id']);
    });

    Studi Kasus 3: Cache Invalidation

    Cache artikel halaman statis dan harus di-clear saat artikel berubah:

    <?php
    
    namespace AppObservers;
    
    use AppModelsArticle;
    use IlluminateSupportFacadesCache;
    
    class ArticleObserver
    {
        public function saved(Article $article): void
        {
            // Clear cache artikel individual
            Cache::forget("article:{$article->id}");
            Cache::forget("article:{$article->slug}");
    
            // Clear cache daftar artikel
            Cache::forget('articles:latest');
            Cache::forget("articles:category:{$article->category_id}");
        }
    
        public function deleted(Article $article): void
        {
            Cache::forget("article:{$article->id}");
            Cache::forget("article:{$article->slug}");
            Cache::forget('articles:latest');
        }
    }

    Studi Kasus 4: Observer dengan Multiple Models

    Kalau beberapa model butuh audit trail yang sama, buat Observer yang reusable:

    <?php
    
    namespace AppObservers;
    
    use AppModelsAuditLog;
    
    class AuditableObserver
    {
        public function created($model): void
        {
            AuditLog::create([
                'user_id'    => auth()->id(),
                'model_type' => get_class($model),
                'model_id'   => $model->id,
                'action'     => 'created',
                'new_values' => $model->getAttributes(),
            ]);
        }
    
        public function updated($model): void
        {
            AuditLog::create([
                'user_id'    => auth()->id(),
                'model_type' => get_class($model),
                'model_id'   => $model->id,
                'action'     => 'updated',
                'old_values' => $model->getOriginal(),
                'new_values' => $model->getChanges(),
            ]);
        }
    }

    Register ke beberapa model sekaligus:

    // Di AppServiceProvider
    Article::observe(AuditableObserver::class);
    Product::observe(AuditableObserver::class);
    Order::observe(AuditableObserver::class);

    Bypass Observer saat Seeding

    <?php
    
    namespace DatabaseSeeders;
    
    use AppModelsArticle;
    
    class ArticleSeeder extends Seeder
    {
        public function run(): void
        {
            // Bypass observer agar tidak trigger audit trail saat seeding
            Article::withoutObservers(function () {
                Article::factory(100)->create();
            });
        }
    }

    Baca Juga

    Butuh tim yang bantu implementasi arsitektur yang clean di aplikasi Laravel? Lihat layanan pengembangan aplikasi kami.

    Baca Juga

  • Contoh Implementasi Policy dan Gate di Laravel 12: Studi Kasus CMS Multi-Role

    Artikel ini melanjutkan penjelasan konsep Policy dan Gate di Laravel 12 dengan studi kasus implementasi lengkap: sistem manajemen konten dengan beberapa level akses.

    Studi Kasus: Sistem CMS dengan Multi-Role

    Skenario: aplikasi CMS dengan role admin, editor, dan author. Aturannya:

    • Admin bisa lakukan semua aksi di artikel mana saja
    • Editor bisa buat, edit, dan publish artikel mana saja
    • Author hanya bisa buat dan edit artikel miliknya sendiri

    Setup Model User dengan Role

    <?php
    
    namespace App\Models;
    
    use Illuminate\Foundation\Auth\User as Authenticatable;
    
    class User extends Authenticatable
    {
        protected $fillable = ['name', 'email', 'password', 'role'];
    
        public function isAdmin(): bool
        {
            return $this->role === 'admin';
        }
    
        public function isEditor(): bool
        {
            return in_array($this->role, ['admin', 'editor']);
        }
    }

    ArticlePolicy Lengkap

    <?php
    
    namespace App\Policies;
    
    use App\Models\Article;
    use App\Models\User;
    
    class ArticlePolicy
    {
        // Ini dijalankan sebelum semua method lain
        // Return true = admin bypass semua check
        public function before(User $user, string $ability): ?bool
        {
            if ($user->isAdmin()) {
                return true;
            }
    
            return null; // null = lanjut ke check berikutnya
        }
    
        public function viewAny(?User $user): bool
        {
            // Semua orang bisa lihat daftar artikel yang published
            return true;
        }
    
        public function view(?User $user, Article $article): bool
        {
            if ($article->status === 'published') {
                return true;
            }
    
            // Draft hanya bisa dilihat pemilik atau editor
            return $user && ($article->user_id === $user->id || $user->isEditor());
        }
    
        public function create(User $user): bool
        {
            return $user->hasVerifiedEmail();
        }
    
        public function update(User $user, Article $article): bool
        {
            // Editor bisa edit semua, author hanya punya sendiri
            return $user->isEditor() || $article->user_id === $user->id;
        }
    
        public function delete(User $user, Article $article): bool
        {
            // Hanya admin (via before()) atau pemilik artikel
            return $article->user_id === $user->id;
        }
    
        public function publish(User $user, Article $article): bool
        {
            // Hanya editor ke atas yang bisa publish
            return $user->isEditor();
        }
    
        public function restore(User $user, Article $article): bool
        {
            return $user->isEditor() || $article->user_id === $user->id;
        }
    }

    Menggunakan Policy di Controller

    <?php
    
    namespace App\Http\Controllers;
    
    use App\Models\Article;
    use App\Http\Requests\StoreArticleRequest;
    
    class ArticleController extends Controller
    {
        public function index()
        {
            $this->authorize('viewAny', Article::class);
    
            $articles = Article::with('author')
                               ->when(!auth()->user()?->isEditor(), fn ($q) =>
                                   $q->where('status', 'published')
                                     ->orWhere('user_id', auth()->id())
                               )
                               ->paginate(15);
    
            return view('articles.index', compact('articles'));
        }
    
        public function edit(Article $article)
        {
            $this->authorize('update', $article);
            return view('articles.edit', compact('article'));
        }
    
        public function destroy(Article $article)
        {
            $this->authorize('delete', $article);
            $article->delete();
            return redirect()->route('articles.index')
                             ->with('success', 'Artikel dihapus.');
        }
    
        public function publish(Article $article)
        {
            $this->authorize('publish', $article);
            $article->update(['status' => 'published', 'published_at' => now()]);
            return back()->with('success', 'Artikel dipublish.');
        }
    }

    Policy di Blade Template

    @foreach ($articles as $article)
        <div>
            <h2>{{ $article->title }}</h2>
    
            @can('update', $article)
                <a href="{{ route('articles.edit', $article) }}">Edit</a>
            @endcan
    
            @can('publish', $article)
                @if($article->status === 'draft')
                    <form action="{{ route('articles.publish', $article) }}" method="POST">
                        @csrf @method('PATCH')
                        <button>Publish</button>
                    </form>
                @endif
            @endcan
    
            @can('delete', $article)
                <form action="{{ route('articles.destroy', $article) }}" method="POST">
                    @csrf @method('DELETE')
                    <button>Hapus</button>
                </form>
            @endcan
        </div>
    @endforeach

    Gate untuk Aksi Global

    Untuk akses fitur yang tidak terkait model tertentu, pakai Gate:

    // Di AppServiceProvider
    Gate::define('access-analytics', fn (User $user) => $user->isEditor());
    Gate::define('export-all-data',  fn (User $user) => $user->isAdmin());
    
    // Di controller
    Gate::authorize('access-analytics');
    return view('analytics.dashboard');
    
    // Di Blade
    @can('access-analytics')
        <a href="/analytics">Analytics</a>
    @endcan

    Baca Juga

    Butuh tim yang bantu implementasi sistem otorisasi yang tepat untuk aplikasi Laravel Anda? Lihat layanan pengembangan aplikasi kami.

    Baca Juga

  • Contoh Penggunaan Concurrency di Laravel 12: Dashboard, API Paralel, dan Defer

    Artikel sebelumnya membahas konsep Concurrency di Laravel 12. Artikel ini fokus pada implementasi: studi kasus nyata bagaimana Concurrency bisa mempercepat aplikasi secara signifikan.

    Studi Kasus 1: Dashboard dengan Banyak Data Source

    Dashboard admin yang butuh data dari beberapa tabel berbeda. Ini biasanya jadi bottleneck karena diquery satu per satu.

    Sebelum (sequential — sekitar 800ms):

    public function dashboard()
    {
        $totalOrders    = Order::thisMonth()->count();          // ~200ms
        $totalRevenue   = Order::thisMonth()->sum('total');     // ~200ms
        $pendingOrders  = Order::where('status', 'pending')->count(); // ~150ms
        $newCustomers   = User::thisMonth()->count();           // ~150ms
        $topProducts    = Product::topSelling(5)->get();       // ~100ms
    
        return view('dashboard', compact(...));
    }

    Sesudah (paralel — sekitar 200ms):

    use IlluminateSupportFacadesConcurrency;
    
    public function dashboard()
    {
        [$totalOrders, $totalRevenue, $pendingOrders, $newCustomers, $topProducts] =
            Concurrency::run([
                fn() => Order::thisMonth()->count(),
                fn() => Order::thisMonth()->sum('total'),
                fn() => Order::where('status', 'pending')->count(),
                fn() => User::thisMonth()->count(),
                fn() => Product::topSelling(5)->get(),
            ]);
    
        return view('dashboard', compact(
            'totalOrders', 'totalRevenue', 'pendingOrders', 'newCustomers', 'topProducts'
        ));
    }

    Studi Kasus 2: Multiple API Calls

    Halaman product detail yang butuh data dari beberapa API eksternal:

    use IlluminateSupportFacadesConcurrency;
    
    public function productDetail(Product $product): View
    {
        [$reviews, $stock, $shippingOptions] = Concurrency::run([
            fn() => $this->reviewApi->getProductReviews($product->id),    // API 1
            fn() => $this->inventoryApi->getStock($product->sku),         // API 2
            fn() => $this->shippingApi->getOptions($product->weight),     // API 3
        ]);
    
        return view('products.detail', compact('product', 'reviews', 'stock', 'shippingOptions'));
    }

    Kalau masing-masing API butuh 500ms, tanpa concurrency total 1.5 detik. Dengan concurrency, cukup ~500ms.

    Studi Kasus 3: Defer untuk Aksi Non-Blocking

    User logout — beberapa aksi perlu terjadi tapi tidak perlu selesai sebelum response dikirim:

    use IlluminateSupportFacadesConcurrency;
    
    public function logout(Request $request): RedirectResponse
    {
        $user = $request->user();
    
        Auth::logout();
        $request->session()->invalidate();
        $request->session()->regenerateToken();
    
        // Jalankan setelah response dikirim
        Concurrency::defer([
            fn() => $this->activityLog->record($user, 'logout'),
            fn() => $this->deviceTokenService->revokeAll($user),
            fn() => $this->sessionCleanup->cleanup($user),
        ]);
    
        return redirect('/');
    }

    Studi Kasus 4: Generate Laporan Parallel

    Generate beberapa bagian laporan sekaligus lalu gabungkan:

    public function generateAnnualReport(int $year): array
    {
        [$salesData, $customerData, $productData, $regionData] = Concurrency::run([
            fn() => $this->salesReport->compile($year),
            fn() => $this->customerReport->compile($year),
            fn() => $this->productReport->compile($year),
            fn() => $this->regionReport->compile($year),
        ]);
    
        return [
            'year'     => $year,
            'sales'    => $salesData,
            'customers' => $customerData,
            'products' => $productData,
            'regions'  => $regionData,
            'generated_at' => now()->toIso8601String(),
        ];
    }

    Error Handling di Concurrency

    Kalau salah satu closure melempar exception, Concurrency akan meneruskan exception tersebut:

    use IlluminateSupportFacadesConcurrency;
    
    try {
        [$data1, $data2] = Concurrency::run([
            fn() => riskyApiCall(),
            fn() => anotherApiCall(),
        ]);
    } catch (Exception $e) {
        // Handle error — biasanya fallback ke data cached atau default
        Log::warning("Concurrency error: {$e->getMessage()}");
        [$data1, $data2] = [getFromCache('data1'), getFromCache('data2')];
    }

    Kapan Tidak Pakai Concurrency

    Jangan pakai untuk operasi yang sangat cepat. Overhead membuka child process (~50-100ms) lebih mahal dari manfaatnya kalau setiap closure selesai dalam 5ms.

    Gunakan untuk operasi yang masing-masing butuh 100ms ke atas, terutama I/O seperti HTTP request, query database, atau baca file besar.

    Baca Juga

    Butuh tim yang bantu optimasi performa aplikasi Laravel Anda? Lihat layanan pengembangan aplikasi kami.

    Baca Juga

  • Contoh Penggunaan Contract di Laravel 12: Implementasi dan Binding

    Kalau Anda sudah membaca artikel tentang apa itu Contract di Laravel 12, artikel ini melanjutkannya dengan contoh penggunaan nyata: bagaimana membuat implementasi Contract sendiri dan kapan ini berguna dalam proyek.

    Menggunakan Contract Bawaan Laravel

    Contract bawaan Laravel ada di namespace Illuminate\Contracts\*. Contoh yang paling sering dipakai adalah type-hinting di constructor untuk decoupling:

    <?php
    
    namespace App\Services;
    
    use Illuminate\Contracts\Cache\Repository as CacheContract;
    use Illuminate\Contracts\Mail\Mailer as MailerContract;
    
    class NotificationService
    {
        public function __construct(
            private CacheContract  $cache,
            private MailerContract $mailer,
        ) {}
    
        public function sendIfNotSent(string $userId, string $template): void
        {
            $cacheKey = "notification:{$userId}:{$template}";
    
            if ($this->cache->has($cacheKey)) {
                return; // Sudah dikirim
            }
    
            $this->mailer->send($template, [], fn ($m) => $m->to($userId));
            $this->cache->put($cacheKey, true, now()->addDay());
        }
    }

    Service ini bisa ditest dengan mudah — tinggal inject mock CacheContract dan MailerContract.

    Membuat Contract Sendiri

    Studi kasus: aplikasi yang butuh fitur kirim notifikasi ke berbagai channel (email, SMS, WhatsApp). Dengan Contract, kita bisa ganti implementasi tanpa mengubah kode yang memakainya.

    Buat Contract interface di app/Contracts/NotificationChannel.php:

    <?php
    
    namespace App\Contracts;
    
    interface NotificationChannel
    {
        public function send(string $recipient, string $message): bool;
        public function isAvailable(): bool;
    }

    Buat beberapa implementasi:

    <?php
    
    namespace App\Services\Notifications;
    
    use App\Contracts\NotificationChannel;
    use Illuminate\Support\Facades\Mail;
    
    class EmailChannel implements NotificationChannel
    {
        public function send(string $recipient, string $message): bool
        {
            try {
                Mail::raw($message, fn ($m) => $m->to($recipient));
                return true;
            } catch (\Exception $e) {
                return false;
            }
        }
    
        public function isAvailable(): bool
        {
            return config('mail.default') !== null;
        }
    }
    
    <?php
    
    namespace App\Services\Notifications;
    
    use App\Contracts\NotificationChannel;
    
    class WhatsAppChannel implements NotificationChannel
    {
        public function __construct(
            private WhatsAppApiClient $client
        ) {}
    
        public function send(string $recipient, string $message): bool
        {
            return $this->client->sendMessage($recipient, $message);
        }
    
        public function isAvailable(): bool
        {
            return !empty(config('services.whatsapp.token'));
        }
    }
    

    Bind Contract ke Implementasi di Service Provider

    <?php
    
    namespace App\Providers;
    
    use App\Contracts\NotificationChannel;
    use App\Services\Notifications\WhatsAppChannel;
    use Illuminate\Support\ServiceProvider;
    
    class AppServiceProvider extends ServiceProvider
    {
        public function register(): void
        {
            // Bind default implementation
            $this->app->bind(NotificationChannel::class, WhatsAppChannel::class);
        }
    }

    Sekarang di mana saja Anda type-hint NotificationChannel, Laravel otomatis inject WhatsAppChannel:

    <?php
    
    namespace App\Http\Controllers;
    
    use App\Contracts\NotificationChannel;
    
    class AlertController extends Controller
    {
        public function __construct(
            private NotificationChannel $channel
        ) {}
    
        public function send(Request $request): Response
        {
            $sent = $this->channel->send(
                $request->recipient,
                $request->message
            );
    
            return response()->json(['success' => $sent]);
        }
    }

    Manfaat: Mudah Ganti Implementasi

    Kalau besok ingin switch dari WhatsApp ke SMS, cukup ganti binding di service provider:

    $this->app->bind(NotificationChannel::class, SmsChannel::class);

    Controller dan semua kode yang pakai NotificationChannel tidak perlu diubah sama sekali.

    Contoh: Kontekstual Binding

    Kalau perlu inject implementasi berbeda di class berbeda:

    $this->app->when(AlertController::class)
              ->needs(NotificationChannel::class)
              ->give(WhatsAppChannel::class);
    
    $this->app->when(ReportController::class)
              ->needs(NotificationChannel::class)
              ->give(EmailChannel::class);

    Baca Juga

    Mau tim yang bantu bangun arsitektur aplikasi Laravel yang scalable? Lihat layanan pengembangan aplikasi kami.

    Baca Juga

  • Apa Itu Observer di Laravel 12 dan Kapan Menggunakannya

    Kalau Event dan Listener cocok untuk “sesuatu terjadi di aplikasi, beri tahu komponen lain”, Observer punya fokus berbeda: “ketika Eloquent model berubah, jalankan kode ini.”

    Artikel ini menjelaskan apa itu Observer di Laravel 12, perbedaannya dengan Event Listener, dan kapan sebaiknya dipakai.

    Apa Itu Observer?

    Observer adalah kelas yang merespons event lifecycle Eloquent model: saat model dibuat, diupdate, dihapus, dll. Daripada pasang listener di banyak tempat, Observer mengumpulkan semua hook untuk satu model di satu kelas.

    Event lifecycle yang bisa di-observe:

    • creating / created
    • updating / updated
    • saving / saved
    • deleting / deleted
    • restoring / restored (untuk soft deletes)
    • forceDeleting / forceDeleted

    Membuat Observer

    php artisan make:observer ArticleObserver --model=Article

    File dibuat di app/Observers/ArticleObserver.php:

    <?php
    
    namespace AppObservers;
    
    use AppModelsArticle;
    use IlluminateSupportStr;
    
    class ArticleObserver
    {
        public function creating(Article $article): void
        {
            // Auto-generate slug sebelum disimpan
            if (empty($article->slug)) {
                $article->slug = Str::slug($article->title);
            }
        }
    
        public function created(Article $article): void
        {
            // Kirim notifikasi ke admin
            cache()->forget('articles.count');
        }
    
        public function updating(Article $article): void
        {
            // Update slug kalau title berubah
            if ($article->isDirty('title')) {
                $article->slug = Str::slug($article->title);
            }
        }
    
        public function deleting(Article $article): void
        {
            // Hapus gambar terkait sebelum artikel dihapus
            $article->images()->each(fn ($img) => $img->delete());
        }
    }

    Registrasi Observer

    Di app/Providers/AppServiceProvider.php:

    <?php
    
    namespace AppProviders;
    
    use AppModelsArticle;
    use AppObserversArticleObserver;
    use IlluminateSupportServiceProvider;
    
    class AppServiceProvider extends ServiceProvider
    {
        public function boot(): void
        {
            Article::observe(ArticleObserver::class);
        }
    }

    Atau bisa dengan attribute di model (Laravel 12):

    use AppObserversArticleObserver;
    use IlluminateDatabaseEloquentAttributesObservedBy;
    
    #[ObservedBy([ArticleObserver::class])]
    class Article extends Model
    {
        // ...
    }

    Observer vs Event Listener: Kapan Pakai Yang Mana?

    Kondisi Pilihan
    Hook spesifik ke satu Eloquent model Observer
    Aksi yang dipicu dari banyak model berbeda Event Listener
    Logika bisnis yang tidak terkait model Eloquent Event Listener
    Semua hook untuk satu model ingin dikumpulkan di satu tempat Observer

    Menonaktifkan Observer Sementara

    Berguna saat import data massal, agar Observer tidak dipanggil ribuan kali:

    // Import tanpa trigger Observer
    Article::withoutObservers(function () {
        foreach ($rows as $row) {
            Article::create($row);
        }
    });
    
    // Atau nonaktifkan event model seluruhnya
    Article::unsetEventDispatcher();

    Setelah import selesai, event otomatis aktif kembali.

    Baca Juga

    Mau tim yang bantu setup arsitektur model-driven di aplikasi Laravel Anda? Lihat layanan pengembangan aplikasi kami.

  • Apa Itu Event dan Listener di Laravel 12: Arsitektur Event-Driven

    Salah satu ciri arsitektur Laravel yang baik: ketika sesuatu terjadi di aplikasi, komponen lain bisa “mendengarkan” dan merespons, tanpa si pengirim perlu tahu siapa yang merespons.

    Itulah fungsi Event dan Listener di Laravel. Artikel ini menjelaskan cara kerjanya dan bagaimana implementasinya dengan contoh nyata.

    Konsep Event dan Listener

    Event adalah kejadian yang terjadi di aplikasi: user mendaftar, order diproses, pembayaran berhasil. Listener adalah kode yang merespons kejadian tersebut.

    Satu event bisa punya beberapa listener. Misalnya saat UserRegistered:

    • Listener 1: kirim email selamat datang
    • Listener 2: create profil default
    • Listener 3: sync ke CRM

    Controller yang trigger event tidak perlu tahu ada 3 listener di belakang. Ini yang membuat kode lebih modular.

    Membuat Event dan Listener

    php artisan make:event UserRegistered
    php artisan make:listener SendWelcomeEmail --event=UserRegistered
    php artisan make:listener CreateDefaultProfile --event=UserRegistered

    Kelas event (app/Events/UserRegistered.php):

    <?php
    
    namespace AppEvents;
    
    use AppModelsUser;
    use IlluminateFoundationEventsDispatchable;
    use IlluminateQueueSerializesModels;
    
    class UserRegistered
    {
        use Dispatchable, SerializesModels;
    
        public function __construct(
            public readonly User $user
        ) {}
    }

    Listener (app/Listeners/SendWelcomeEmail.php):

    <?php
    
    namespace AppListeners;
    
    use AppEventsUserRegistered;
    use AppMailWelcomeMail;
    use IlluminateContractsQueueShouldQueue;
    use IlluminateSupportFacadesMail;
    
    class SendWelcomeEmail implements ShouldQueue
    {
        public function handle(UserRegistered $event): void
        {
            Mail::to($event->user)->send(new WelcomeMail($event->user));
        }
    }

    Implement ShouldQueue agar listener dijalankan di background queue, tidak memperlambat proses registrasi.

    Registrasi Event dan Listener

    Di Laravel 12 (dan sejak Laravel 11), cukup tambahkan di app/Providers/AppServiceProvider.php:

    <?php
    
    namespace AppProviders;
    
    use AppEventsUserRegistered;
    use AppListenersSendWelcomeEmail;
    use AppListenersCreateDefaultProfile;
    use IlluminateSupportFacadesEvent;
    use IlluminateSupportServiceProvider;
    
    class AppServiceProvider extends ServiceProvider
    {
        public function boot(): void
        {
            Event::listen(UserRegistered::class, SendWelcomeEmail::class);
            Event::listen(UserRegistered::class, CreateDefaultProfile::class);
        }
    }

    Laravel juga mendukung auto-discovery. Kalau nama listener mengikuti konvensi, registrasi manual tidak diperlukan. Tapi registrasi manual lebih eksplisit dan lebih mudah di-trace.

    Dispatch Event

    // Di controller atau service
    use AppEventsUserRegistered;
    
    $user = User::create($validated);
    
    UserRegistered::dispatch($user);
    
    // Atau lewat helper
    event(new UserRegistered($user));

    Listener Synchronous vs Queued

    Kalau listener implement ShouldQueue, dijalankan di background. Kalau tidak, dijalankan langsung (synchronous) sebelum response dikirim.

    Kapan pakai synchronous:

    • Listener yang hasilnya dibutuhkan sebelum response dikirim
    • Operasi yang sangat cepat (kurang dari 10ms)

    Kapan pakai queued:

    • Kirim email, notifikasi, sync ke API eksternal
    • Semua operasi yang tidak perlu hasilnya sekarang

    Wildcard Listener

    Kalau perlu listen ke banyak event sekaligus (misalnya untuk logging):

    Event::listen('AppEvents*', function (string $eventName, array $data) {
        Log::info("Event: {$eventName}", $data);
    });

    Baca Juga

    Butuh tim untuk merancang arsitektur event-driven di aplikasi Laravel Anda? Lihat layanan pengembangan aplikasi kami.

  • Apa Itu Policy dan Gate di Laravel 12: Sistem Otorisasi yang Tepat

    Bayangkan ada dua pertanyaan berbeda soal keamanan di aplikasi Anda: “Apakah user ini boleh edit artikel?” dan “Apakah user yang login adalah editor?”

    Pertanyaan pertama terkait Policy: otorisasi berdasarkan resource. Pertanyaan kedua terkait Gate: otorisasi berdasarkan kemampuan/role. Keduanya bagian dari sistem Authorization di Laravel.

    Apa Itu Gate?

    Gate adalah cara mendefinisikan otorisasi berbasis kemampuan (ability) secara sederhana, biasanya untuk aksi yang tidak terkait langsung dengan model tertentu.

    Definisikan Gate di app/Providers/AppServiceProvider.php:

    <?php
    
    namespace AppProviders;
    
    use AppModelsUser;
    use IlluminateSupportFacadesGate;
    use IlluminateSupportServiceProvider;
    
    class AppServiceProvider extends ServiceProvider
    {
        public function boot(): void
        {
            Gate::define('access-admin-panel', function (User $user) {
                return $user->role === 'admin';
            });
    
            Gate::define('manage-settings', function (User $user) {
                return in_array($user->role, ['admin', 'superadmin']);
            });
        }
    }

    Gunakan di controller atau view:

    // Di controller
    if (Gate::denies('access-admin-panel')) {
        abort(403);
    }
    
    // Dengan authorize (auto-throw 403 jika gagal)
    Gate::authorize('access-admin-panel');
    
    // Di Blade
    @can('access-admin-panel')
        <a href="/admin">Admin Panel</a>
    @endcan

    Apa Itu Policy?

    Policy adalah kelas yang mengelompokkan logika otorisasi untuk satu model. Cocok untuk otorisasi seperti “siapa yang boleh edit, hapus, atau lihat resource ini?”

    php artisan make:policy ArticlePolicy --model=Article

    File dibuat di app/Policies/ArticlePolicy.php:

    <?php
    
    namespace AppPolicies;
    
    use AppModelsArticle;
    use AppModelsUser;
    
    class ArticlePolicy
    {
        public function viewAny(User $user): bool
        {
            return true; // Semua user bisa lihat daftar artikel
        }
    
        public function view(User $user, Article $article): bool
        {
            // Bisa lihat kalau published, atau kalau milik sendiri
            return $article->status === 'published' || $article->user_id === $user->id;
        }
    
        public function create(User $user): bool
        {
            return $user->hasVerifiedEmail();
        }
    
        public function update(User $user, Article $article): bool
        {
            // Hanya pemilik yang bisa edit
            return $article->user_id === $user->id;
        }
    
        public function delete(User $user, Article $article): bool
        {
            // Pemilik dan admin bisa hapus
            return $article->user_id === $user->id || $user->role === 'admin';
        }
    }

    Registrasi Policy

    Di Laravel 12, policy otomatis ditemukan (auto-discovery) kalau struktur folder sesuai konvensi. Tapi Anda juga bisa register manual di AppServiceProvider:

    use AppModelsArticle;
    use AppPoliciesArticlePolicy;
    use IlluminateSupportFacadesGate;
    
    Gate::policy(Article::class, ArticlePolicy::class);

    Menggunakan Policy

    // Di controller
    public function edit(Article $article)
    {
        $this->authorize('update', $article); // Throw 403 kalau tidak bisa
    
        return view('articles.edit', compact('article'));
    }
    
    // Cek tanpa throw exception
    if ($request->user()->can('update', $article)) {
        // boleh lanjut
    }
    
    // Di Blade
    @can('update', $article)
        <a href="{{ route('articles.edit', $article) }}">Edit</a>
    @endcan
    
    @cannot('delete', $article)
        <p>Anda tidak bisa hapus artikel ini.</p>
    @endcannot

    Gate vs Policy: Kapan Pakai Yang Mana?

    Kondisi Gunakan
    Otorisasi terkait satu model (Article, Order, dll.) Policy
    Otorisasi berdasarkan role/kemampuan global Gate
    Aturan sederhana yang tidak butuh kelas terpisah Gate
    Banyak aturan berbeda untuk satu model Policy

    Baca Juga

    Butuh tim yang bantu implementasi sistem otorisasi yang aman di aplikasi Laravel? Lihat layanan pengembangan aplikasi kami.

  • Cara Membuat Custom Artisan Command di Laravel 12

    Artisan bawaan Laravel sudah mencakup banyak kebutuhan. Tapi kadang Anda butuh command yang spesifik untuk proyek Anda, misalnya generate laporan harian, kirim email batch, atau sync data dari API eksternal.

    Di sinilah custom Artisan command berguna. Artikel ini menunjukkan cara membuat, mengatur parameter, dan menjalankan scheduled command di Laravel 12.

    Membuat Custom Command

    Gunakan Artisan untuk generate skeleton command:

    php artisan make:command SendDailyReport

    File dibuat di app/Console/Commands/SendDailyReport.php:

    <?php
    
    namespace AppConsoleCommands;
    
    use IlluminateConsoleCommand;
    
    class SendDailyReport extends Command
    {
        protected $signature = 'report:daily';
        protected $description = 'Send daily sales report to managers';
    
        public function handle(): int
        {
            // logika command di sini
    
            return Command::SUCCESS;
        }
    }

    Jalankan:

    php artisan report:daily

    Menambahkan Argumen dan Opsi

    Command yang berguna biasanya butuh input. Ada dua jenis: argumen (wajib) dan opsi (opsional dengan --).

    protected $signature = 'report:send
                            {type : Tipe laporan: sales atau inventory}
                            {--date= : Tanggal laporan (default: hari ini)}
                            {--dry-run : Simulasi tanpa kirim email}';
    

    Cara mengakses di dalam handle():

    public function handle(): int
    {
        $type    = $this->argument('type');
        $date    = $this->option('date') ?? now()->toDateString();
        $dryRun  = $this->option('dry-run');
    
        $this->info("Membuat laporan {$type} untuk tanggal {$date}...");
    
        if ($dryRun) {
            $this->warn('Mode dry-run: email tidak akan dikirim.');
        }
    
        // proses laporan...
    
        $this->info('Selesai.');
        return Command::SUCCESS;
    }

    Contoh penggunaan:

    php artisan report:send sales
    php artisan report:send sales --date=2025-04-01
    php artisan report:send inventory --dry-run

    Output yang Informatif

    Artisan menyediakan beberapa helper untuk output yang bersih:

    $this->info('Pesan biasa');      // hijau
    $this->error('Ada error!');     // merah
    $this->warn('Perhatian');       // kuning
    $this->line('Teks biasa');      // putih
    $this->comment('// komentar'); // abu-abu
    
    // Progress bar untuk proses batch
    $users = User::all();
    $bar   = $this->output->createProgressBar(count($users));
    $bar->start();
    
    foreach ($users as $user) {
        // proses
        $bar->advance();
    }
    
    $bar->finish();

    Dependency Injection di Custom Command

    Inject service lewat constructor, sama seperti controller:

    <?php
    
    namespace AppConsoleCommands;
    
    use AppServicesReportService;
    use AppServicesMailService;
    use IlluminateConsoleCommand;
    
    class SendDailyReport extends Command
    {
        protected $signature = 'report:daily {--date=}';
        protected $description = 'Send daily report via email';
    
        public function __construct(
            private ReportService $reportService,
            private MailService   $mailService,
        ) {
            parent::__construct();
        }
    
        public function handle(): int
        {
            $date   = $this->option('date') ?? now()->toDateString();
            $report = $this->reportService->generate($date);
    
            if ($report->isEmpty()) {
                $this->warn("Tidak ada data untuk tanggal {$date}.");
                return Command::SUCCESS;
            }
    
            $this->mailService->sendReport($report);
            $this->info("Laporan {$date} berhasil dikirim ke " . $report->recipientCount() . " penerima.");
    
            return Command::SUCCESS;
        }
    }

    Menjadwalkan Command Otomatis

    Di Laravel 12, jadwal command diatur di routes/console.php — bukan lagi di app/Console/Kernel.php:

    <?php
    
    use IlluminateSupportFacadesSchedule;
    
    // Kirim laporan setiap hari jam 7 pagi
    Schedule::command('report:daily')->dailyAt('07:00');
    
    // Bersihkan log setiap minggu
    Schedule::command('log:cleanup')->weekly();
    
    // Sync produk setiap 30 menit
    Schedule::command('products:sync')->everyThirtyMinutes();
    
    // Jalankan khusus hari kerja
    Schedule::command('report:daily')->weekdays()->at('08:00');

    Tambahkan satu baris ke crontab server untuk menjalankan scheduler setiap menit:

    * * * * * cd /var/www/html && php artisan schedule:run >> /dev/null 2>&1

    Testing Custom Command

    Laravel menyediakan helper untuk test command tanpa harus jalankan manual:

    public function test_report_command_runs_successfully(): void
    {
        $this->artisan('report:daily')
             ->expectsOutput('Laporan berhasil dikirim')
             ->assertExitCode(0);
    }
    
    // Test dengan argumen
    public function test_report_with_date(): void
    {
        $this->artisan('report:send', [
            'type'   => 'sales',
            '--date' => '2025-04-01',
        ])->assertExitCode(0);
    }

    Baca Juga

    Kalau Anda butuh tim untuk membangun dan maintain aplikasi Laravel Anda, lihat layanan pengembangan aplikasi kami.

  • Concurrency Adalah? Cara Kerja Concurrency di Laravel 12

    Concurrency adalah kemampuan menjalankan beberapa proses secara bersamaan (paralel), bukan satu per satu secara berurutan. Di dunia web modern, concurrency artinya bisa memanggil tiga API eksternal sekaligus dan menunggu semuanya selesai — dibanding menunggu satu selesai, baru mulai berikutnya. Laravel 12 memperkenalkan Concurrency facade yang membuat pola ini jauh lebih mudah diimplementasikan di aplikasi PHP.

    Artikel ini menjelaskan apa itu Concurrency di Laravel 12, bagaimana cara kerjanya secara teknis, dan kapan sebaiknya dipakai — beserta kasus di mana lebih baik tidak menggunakannya.

    Apa Itu Concurrency di Laravel 12?

    Concurrency adalah teknik eksekusi paralel di mana beberapa operasi berjalan secara bersamaan, bukan berurutan. Dalam konteks Laravel, concurrency artinya Anda bisa menjalankan beberapa closure PHP secara paralel dan mengumpulkan semua hasilnya sekaligus.

    Concurrency facade di Laravel 12 memungkinkan Anda menjalankan beberapa closure secara bersamaan (paralel) dan menunggu semua hasilnya. Ini berguna saat Anda punya beberapa operasi yang tidak bergantung satu sama lain dan masing-masing membutuhkan waktu, seperti memanggil beberapa API eksternal atau query ke database berbeda.

    Tanpa concurrency (sequential):

    // Total waktu: 1 + 2 + 1.5 = ~4.5 detik
    $weather  = fetchWeather($city);     // 1 detik
    $stock    = fetchStockPrice($code);  // 2 detik
    $exchange = fetchExchangeRate();     // 1.5 detik

    Dengan concurrency (paralel):

    use Illuminate\Support\Facades\Concurrency;
    
    // Total waktu: ~2 detik (terlama)
    [$weather, $stock, $exchange] = Concurrency::run([
        fn() => fetchWeather($city),
        fn() => fetchStockPrice($code),
        fn() => fetchExchangeRate(),
    ]);

    Bagaimana Cara Kerjanya?

    Laravel Concurrency bekerja dengan membuka beberapa proses PHP secara paralel (bukan thread). Setiap closure dijalankan di child process terpisah, hasilnya di-serialize dan dikembalikan ke parent process.

    Ini berbeda dengan async programming di Node.js atau Go. Laravel Concurrency tidak non-blocking event loop, melainkan multi-process. Artinya ada overhead untuk setiap proses baru, jadi tidak ideal untuk tugas yang sangat pendek (di bawah 100ms).

    Contoh Penggunaan Nyata

    Dashboard analytics yang perlu data dari beberapa sumber:

    use Illuminate\Support\Facades\Concurrency;
    
    [$orders, $revenue, $topProducts, $visitors] = Concurrency::run([
        fn() => Order::thisMonth()->count(),
        fn() => Order::thisMonth()->sum('total'),
        fn() => Product::topSelling(5)->get(),
        fn() => Analytics::uniqueVisitors(today()),
    ]);
    
    return view('dashboard', compact('orders', 'revenue', 'topProducts', 'visitors'));

    Tanpa concurrency, kalau tiap query butuh 200ms, total jadi 800ms. Dengan concurrency, total sekitar 200ms (sesuai yang terlama).

    Defer: Jalankan Setelah Response Dikirim

    Laravel 12 juga punya Concurrency::defer() — mirip dengan concurrency, tapi closure dijalankan setelah response HTTP sudah dikirim ke browser.

    use Illuminate\Support\Facades\Concurrency;
    
    // Response langsung dikirim ke user
    // Tiga closure di bawah jalan di background
    Concurrency::defer([
        fn() => $this->updateLastLogin($user),
        fn() => $this->logActivity($user, 'login'),
        fn() => $this->syncWithCRM($user),
    ]);
    
    return redirect()->intended('dashboard');

    Berguna untuk aksi “fire and forget” yang tidak perlu hasilnya sebelum response dikirim.

    Kapan Pakai, Kapan Tidak?

    Cocok untuk:

    • Beberapa panggilan API eksternal yang independent
    • Query ke database berbeda (multi-connection) yang tidak saling bergantung
    • Proses komputasi berat yang bisa diparalelkan

    Tidak cocok untuk:

    • Tugas sangat cepat (overhead proses lebih mahal daripada keuntungannya)
    • Operasi yang saling bergantung (output A dibutuhkan input B)
    • Operasi yang butuh akses ke state yang sama (tidak ada shared memory antar proses)

    Concurrency vs Queue vs Async: Apa Bedanya?

    Banyak developer bingung membedakan tiga konsep ini. Berikut perbedaannya dalam konteks Laravel:

    • Concurrency (Laravel 12) — Proses berjalan paralel, hasilnya ditunggu langsung di request yang sama. Ideal untuk operasi I/O yang independent dalam satu request.
    • Queue (Laravel Queue) — Tugas dikirim ke antrian dan dikerjakan di background oleh worker terpisah. Tidak menunggu hasilnya. Ideal untuk email, notifikasi, proses besar yang tidak perlu hasilnya segera.
    • Async (JavaScript/Node.js) — Non-blocking event loop. PHP secara native bukan bahasa async, jadi Laravel Concurrency mensimulasikannya via multi-process.

    Aturan sederhana: Butuh hasilnya sekarang di dalam request? → Gunakan Concurrency. Tidak butuh hasilnya segera? → Gunakan Queue.

    Pitfalls dan Hal yang Perlu Diperhatikan

    Tidak Ada Shared State Antar Proses

    Karena setiap closure berjalan di child process terpisah, tidak ada shared memory. Variabel, singleton, atau cache in-memory yang diubah di satu closure tidak akan terlihat di closure lain atau di parent process.

    Exception Handling

    Jika salah satu closure throw exception, Concurrency::run() akan menangkapnya dan throw ulang di parent process. Pastikan setiap closure ditangani dengan baik:

    [$result1, $result2] = Concurrency::run([
        fn() => safeApiCall1(),
        fn() => safeApiCall2(),
    ]);

    Database Connection per Process

    Setiap child process butuh koneksi database sendiri. Pastikan database connection pool Anda cukup untuk menampung jumlah proses konkuren yang Anda jalankan.

    Baca Juga

    FAQ: Pertanyaan Umum tentang Concurrency di Laravel

    Apa itu concurrency dalam pemrograman?

    Concurrency adalah kemampuan sistem menjalankan beberapa proses atau operasi secara bersamaan. Concurrency artinya tidak ada satu proses yang harus menunggu proses lain selesai sebelum bisa mulai — semua bisa berjalan paralel.

    Apa perbedaan concurrency dan parallelism?

    Concurrency adalah konsep logis (beberapa pekerjaan dalam proses yang tumpang-tindih), sementara parallelism adalah eksekusi fisik secara bersamaan di beberapa CPU core. Laravel Concurrency di balik layar menggunakan multi-process, yang merupakan bentuk true parallelism.

    Apakah Laravel Concurrency tersedia di Laravel 11?

    Concurrency facade diperkenalkan di Laravel 11 (sebagai fitur eksperimental) dan disempurnakan di Laravel 12. Jika Anda menggunakan Laravel 11.x, pastikan versi Laravel Anda sudah mendukung Illuminate\Support\Facades\Concurrency.

    Apakah laravel concurrency aman untuk production?

    Ya, aman untuk production selama Anda memahami limitasinya: tidak ada shared state antar proses, exception harus ditangani dengan baik, dan jumlah concurrent process harus sesuai dengan kapasitas server (RAM dan database connections).

    Concurrency artinya apa dalam bahasa Indonesia?

    Concurrency artinya “kebersamaan” atau “pemrosesan bersamaan” — kemampuan menjalankan beberapa tugas secara paralel. Dalam konteks Laravel, concurrency artinya beberapa closure PHP dieksekusi secara bersamaan di proses terpisah.

    Tertarik Membangun Aplikasi Laravel yang Performant?

    Memahami fitur seperti Concurrency adalah bagian dari membangun aplikasi Laravel yang benar-benar scalable. Jika tim Anda butuh bantuan merancang arsitektur aplikasi PHP yang efisien — mulai dari pemilihan teknik pemrosesan yang tepat hingga deployment di server production — tim Arrazy Inovasi siap membantu.

    Ada proyek yang ingin didiskusikan? Konsultasi gratis dengan tim kami.

  • Tutorial Laravel 12: Menggunakan Context Facade untuk Propagasi Data

    Tutorial Laravel 12: Menggunakan Context Facade untuk Propagasi Data

    Laravel 12 nambah fitur baru namanya Context. Kalau kamu pernah bingung gimana caranya nyebarin data kayak tenant_id, request_id, atau user_id ke semua log, job, dan event tanpa harus ngoper variabel ke mana-mana — ini solusinya.

    Tutorial ini bahas Context dari dasar sampai implementasi nyata. Cocok buat kamu yang udah familiar sama Laravel tapi belum pernah pakai Context facade.

    Apa Itu Context di Laravel 12?

    Context adalah cara Laravel nyimpen data yang terikat sama satu request atau satu eksekusi. Data ini bisa diakses dari mana aja tanpa harus ngoper variabel ke tiap fungsi atau class.

    Bayangin kamu punya aplikasi multi-tenant. Setiap request butuh tahu tenant_id-nya siapa. Biasanya kamu harus:

    • Ngirim $tenantId ke controller
    • Terus ke service
    • Terus ke repository
    • Terus ke job
    • Terus ke log

    Ribet. Context bikin ini jadi simpel:

    use Illuminate\Support\Facades\Context;
    
    // Set sekali di middleware
    Context::add('tenant_id', 123);
    
    // Ambil di mana aja
    $tenantId = Context::get('tenant_id'); // 123

    Data ini otomatis ikut ke log, job, event, dan exception yang terjadi dalam request yang sama.

    Cara Pakai Context: Dasar

    Context tersedia lewat facade Illuminate\Support\Facades\Context atau helper context().

    Menambah Data ke Context

    Context::add('request_id', 'REQ-20260525-0001');
    Context::add('user_id', 42);
    
    // Atau sekaligus
    Context::add([
        'request_id' => 'REQ-20260525-0001',
        'user_id' => 42,
    ]);

    Mengambil Data dari Context

    $requestId = Context::get('request_id');
    
    // Dengan default value kalau tidak ada
    $userId = Context::get('user_id', 0);

    Menghapus Data dari Context

    // Hapus satu key
    Context::forget('request_id');
    
    // Hapus semua
    Context::flush();

    Studi Kasus 1: Request ID di Semua Log

    Masalah klasik: saat ada error, susah tahu log mana yang terkait satu request. Apalagi kalau traffic tinggi, log campur aduk.

    Solusinya: bikin middleware yang nambah request ID ke Context.

    <?php
    
    namespace App\Http\Middleware;
    
    use Closure;
    use Illuminate\Http\Request;
    use Illuminate\Support\Facades\Context;
    use Illuminate\Support\Str;
    
    class AddRequestContext
    {
        public function handle(Request $request, Closure $next): mixed
        {
            Context::add([
                'request_id' => Str::uuid()->toString(),
                'url'        => $request->fullUrl(),
                'method'     => $request->method(),
                'ip'         => $request->ip(),
                'user_id'    => $request->user()?->id,
            ]);
    
            return $next($request);
        }
    }

    Daftarkan di bootstrap/app.php:

    ->withMiddleware(function (Middleware $middleware) {
        $middleware->prepend(AddRequestContext::class);
    })

    Sekarang semua log otomatis punya context:

    Log::info('Memproses pembayaran');
    
    // Output di log:
    // [2026-05-25 10:23:45] local.INFO: Memproses pembayaran 
    // {"request_id":"abc-123","url":"/checkout","user_id":42}

    Kalau ada error, tinggal cari semua log dengan request_id yang sama. Debugging jadi jauh lebih gampang.

    Studi Kasus 2: Multi-Tenancy dengan Context

    Aplikasi multi-tenant butuh tenant_id di hampir semua query. Biasanya kamu harus ngirim $tenantId ke mana-mana. Dengan Context, cukup set sekali di middleware:

    <?php
    
    namespace App\Http\Middleware;
    
    use Closure;
    use Illuminate\Http\Request;
    use Illuminate\Support\Facades\Context;
    
    class ResolveTenant
    {
        public function handle(Request $request, Closure $next): mixed
        {
            // Resolve tenant dari subdomain atau header
            $tenant = $this->getTenantFromRequest($request);
    
            Context::add('tenant_id', $tenant->id);
    
            return $next($request);
        }
    
        private function getTenantFromRequest(Request $request)
        {
            // Contoh: dari subdomain
            $subdomain = explode('.', $request->getHost())[0];
            return Tenant::where('subdomain', $subdomain)->firstOrFail();
        }
    }

    Sekarang di service atau repository, tinggal ambil dari Context:

    class OrderService
    {
        public function getCurrentTenantOrders()
        {
            $tenantId = Context::get('tenant_id');
    
            return Order::where('tenant_id', $tenantId)->get();
        }
    }

    Catatan penting: Jangan bergantung 100% pada Context untuk data bisnis kritis. Kalau kamu jalanin Artisan command atau test, Context mungkin kosong. Selalu kasih default value atau cek null.

    Studi Kasus 3: Propagasi Context ke Queue Jobs

    Masalah: ketika request trigger job di queue, context (request ID, user ID) hilang karena job jalan di worker terpisah.

    Kabar baiknya: Context otomatis dipropagasi ke jobs kalau job implement ShouldQueue.

    <?php
    
    namespace App\Jobs;
    
    use Illuminate\Bus\Queueable;
    use Illuminate\Contracts\Queue\ShouldQueue;
    use Illuminate\Foundation\Bus\Dispatchable;
    use Illuminate\Queue\InteractsWithQueue;
    use Illuminate\Support\Facades\Context;
    use Illuminate\Support\Facades\Log;
    
    class ProcessPayment implements ShouldQueue
    {
        use Dispatchable, InteractsWithQueue, Queueable;
    
        public function __construct(
            private int $orderId
        ) {}
    
        public function handle(): void
        {
            // Context dari request yang dispatch job ini otomatis tersedia
            $requestId = Context::get('request_id');
    
            Log::info("Memproses pembayaran order {$this->orderId}", [
                'request_id' => $requestId,
            ]);
    
            // proses pembayaran...
        }
    }

    Best practice: Untuk data penting kayak tenant_id, simpan juga sebagai property Job. Jangan cuma andalin Context, karena lifecycle worker bisa beda-beda.

    Studi Kasus 4: Hidden Context untuk Data Sensitif

    Kadang kamu butuh data di Context tapi nggak mau muncul di log (misalnya token atau API key).

    // Tambah context tersembunyi — tidak masuk ke log
    Context::addHidden([
        'payment_token' => $request->payment_token,
        'api_key'       => config('services.payment.key'),
    ]);
    
    // Ambil di bagian lain
    $token = Context::getHidden('payment_token');

    Data ini tetap bisa diakses di kode, tapi nggak akan muncul di log output.

    Kapan Pakai Context vs Dependency Injection?

    Context bukan pengganti dependency injection. Ini panduan kapan pakai mana:

    Pakai Context kalau:

    • Data perlu tersebar ke banyak layer (log, job, event) tanpa ubah signature
    • Multi-tenant: tenant_id butuh ada di mana-mana
    • Request tracing: request_id untuk debugging
    • Feature flags: tracking fitur apa yang aktif per request

    Pakai Dependency Injection kalau:

    • Data bisnis yang jelas dependensinya (misal OrderService butuh PaymentGateway)
    • Konfigurasi statis (cukup lewat config atau env)
    • Kode yang perlu di-test dengan mock/stub

    Intinya: Context untuk data “ambient” yang perlu ada di mana-mana. DI untuk dependensi eksplisit yang jelas.

    Testing Kode yang Pakai Context

    Di test, kamu harus set Context secara manual:

    use Illuminate\Support\Facades\Context;
    
    public function test_service_menggunakan_tenant_dari_context()
    {
        Context::flush(); // Pastikan kosong dulu
        Context::add('tenant_id', 10);
    
        $service = app(OrderService::class);
        $orders = $service->getCurrentTenantOrders();
    
        $this->assertTrue(
            $orders->every(fn ($order) => $order->tenant_id === 10)
        );
    }

    Jangan lupa Context::flush() di setUp() atau tearDown() biar nggak ada kebocoran state antar test.

    Pitfall yang Harus Dihindari

    1. Overuse Context = Global State

    Kalau semua data masuk Context, kode jadi susah di-trace. Pakai Context cuma untuk data yang emang perlu ada di mana-mana.

    2. Lupa Guard di CLI/Artisan

    Artisan command jalan tanpa request, jadi Context bisa kosong. Selalu kasih default:

    $tenantId = Context::get('tenant_id');
    
    if (is_null($tenantId)) {
        throw new \RuntimeException('Tenant ID tidak tersedia di context');
    }

    3. Ubah Context di Layer Bawah

    Kalau middleware A set tenant_id, jangan ubah lagi di service atau repository. Bikin aturan: Context cuma di-set di middleware, layer lain cuma baca.

    Ringkasan

    Context facade di Laravel 12 bikin kamu bisa nyebarin data ke seluruh aplikasi tanpa harus ngoper variabel ke mana-mana. Cocok buat:

    • Request tracing dengan request_id
    • Multi-tenancy dengan tenant_id
    • Feature flags dan debugging
    • Propagasi data ke log, job, dan event

    Tapi ingat: jangan overuse. Pakai Context untuk data ambient, pakai DI untuk dependensi eksplisit.

    Baca Juga

    Butuh tim yang bantu setup observability dan logging yang proper di aplikasi Laravel? Lihat layanan pengembangan aplikasi kami.