Eloquent Modellerinin Kuyruğa Alınan İşlere Geçirilmesinin Sorunlu Olabileceği Nedenler

TL;DR

Tam Eloquent modellerle iş göndermekten kaçının.

SendOrderConfirmation::dispatch($user);

Yerine, işin gerçekten ihtiyaç duyduğu verileri geçin.

SendOrderConfirmation::dispatch($user->id);

Modelleri geçmek şunlara neden olabilir:

1. Kuyruk yük boyutunun artması
2. Yayınlar sonrasında işlerin bozulması
3. Hassas verilerin günlüklere ya da başarısız işlere açığa çıkması

Daha küçük yükler, sisteminizi daha dayanıklı, öngörülebilir ve güvenli hale getirir.

Tam Makale

Bu modeli genellikle PR’lerde sıkça görüyorum. Ve açık olmak gerekirse — bunu büyük bir mesele haline getirmeye çalışmıyorum. İşe yarıyor.

Fakat bu, bu küçük karar için şaşırtıcı derecede büyük sorunlar yaratabilir.

1. Kuyruk yükünüz beklenmedik şekilde artabilir
Ve çoğu zaman bu, kasıtlı değildir. Daha büyük sistemlerde, bir modelin zaten ilişkileriyle yüklü olabileceğini unutmak kolaydır. Bu ilişkiler, istek yaşam döngüsünde daha önce yüklenmiş olabilir — belki de yazmadığınız bir kod tarafından yüklenmiştir.

$user->load('products');

Eğer o kullanıcıda 50 ürün yüklüyse, bu ilişkiler iş kuyruğuna itildiğinde iş yükü olarak serileştirilebilir — ister Amazon SQS, ister Redis kullanıyor olun.

Artık kuyruk mesajı, işin gerçekten ihtiyaç duyduğu veriden çok daha fazla veriyi içermektedir.

Birçok durumda, işin yalnızca basit bir şeye ihtiyacı vardır:

Başka bir şey yok.

2. Yayınlar kuyruklanmış işleri bozabilir
Şu senaryoyu hayal edin:

1. Bir iş, serileştirilmiş bir model ile gönderilir
2. Yeni bir yayın yapılır
3. Model yapısı değişir
4. İş yeniden denendiğinde eski yükü serileştirmeye çalışır

Suddenly, görev işçi doğru şekilde nesneyi yeniden inşa edemez.

Bu, kırılgan işlere neden olur ve hata toleransını azaltır.
İşlerin, mümkün olduğunca bağımsız ve sürüm dayanıklı olması gerekir.

3. Hassas veriler kuyruk günlüklerine girebilir
Bir model serileştirildiğinde, nitelikleri kuyruk yükü içinde yer alabilir.

Bu, bilgilerin şu alanlarda ortaya çıkabileceği anlamına gelir:

• başarısız iş günlükleri
• kuyruk panelleri (örneğin Horizon)
• hata ayıklama araçları
• ölü mektup kuyrukları

Düzenlenmiş ortamlarda (örneğin sağlık veya finans), bu bir uyum riski haline gelebilir.

Şifreler hashlenmiş olsa bile, diğer alanlar hala kişisel tanımlanabilir bilgileri (PII) içerebilir.

Daha az veri göndererek, sisteminizi korumayı sağlar.

Daha Güvenli Bir Desen

İşleri yalnızca ihtiyaç duydukları kimliklerle gönderin:

SendOrderConfirmation::dispatch($user->id);

Sonrasında modeli işin içinde çözün:

public function handle(): void
{
    $user = User::findOrFail($this->userId);
}

Bu, işlerinizi:

• daha hafif
• daha güvenli
• yeniden denemesi daha kolay
• değişime daha dayanıklı

Bazen en iyi PR geri bildirimi, sadece:

“Burada gerçekten tüm modeli geçmemiz gerekiyor mu?”

Çoğu zaman, cevap hayırdır.