Geliştirici Kaydı: 2026-07-03 — idempotent senkronizasyonlar, izlenebilir e-posta ve boşaltma değil silme

TL;DR

• Sync idempotent olmalıdır. Bir gateway senkronizasyonunu tekrar çalıştırmak, ikinci geçişte patlama değil, birleşme sağlamalıdır — mevcut olanı benimseyin, UNIQUE çakışması yüzünden hata vermeyin.
• Gerçekten sayfalama yapın. 100 ile sınırlı bir liste API’si, 101 kaydınız olduğunda size yalan söyleyecektir. Farklılaştırmadan önce her sayfayı alın.
• Çıkan e-posta gözlemlenebilir olabilir — üçüncü parti bir hizmete ihtiyaç duymadan, Laravel’in e-posta olayları teslim edilme/açılma/tıklama kancaları sağlar.
• Diğer konular: ITIL bilet türleri + destek masasında büyük olay yönetimi, REST v1 API’ye bağlı bir Flutter mobil istemcisi ve aslında bir sahiplik hatası olan bir unvan hatası.

Gateway betiği: senkronizasyonu sıkıcı hale getirin

Bugünün çoğu bir API-gateway yönetimi uygulaması üzerinden geçti. Senkronizasyon düzeltmeleri kendi yazımını aldı (bu serideki idempotent-sync yazısı).

Kısa versiyon: bir gateway’e yapılandırma senkronizasyonu yapmak, bir ekleme değil, bir bütünleşme işlemidir. Hedef zaten mevcutsa, 409 hatasında onu benimseyin, atmayın. Bir liste uç noktası sayfalanıyorsa, tüm sayfaları okuyun — kısmi okuma, farklılaştırmanızı silinmiş gibi gösterebilir. Ve kapsamlı bir eklenti, sessizce küresel kapsam genişletmemelidir; kapsam kimliktir, göz ardı edilebilecek bir detay değil.

Gerçekten izleyebileceğiniz e-posta

Bir kimlik portalı, çıkan e-posta için teslim edilme/açılma/tıklanma izleme hizmeti aldı — dış bir ESP kullanmadan, sadece Laravel’in kendi MessageSending / MessageSent olayları artı bir izleme pikseli ve bağlantı yeniden yazımı ile (ayrıntılı yazımının tamamı). Güzel kısım: çalışma zamanı anahtarıdır, bu nedenle izlemeyi ortam bazında bir dağıtım olmadan kapatabilirsiniz.

Destek masası: olaylar biletlerden farklı bir yapıya sahiptir

Bir destek platformu ITIL bilet türleri ve büyük olay yönetimi aldı. Altındaki ders: büyük bir olay, sadece yüksek öncelikli bir bilet değildir. Kendine ait bir yaşam döngüsü vardır — ilan et, koordine et, durdur — ve kendine ait bir izleyici kitlesi vardır. Bunu birinci sınıf bir şey olarak modellemek (ilan/durma eylemleri, dahili iş maddeleri) öncelik alanını aşırı yüklemekten daha iyidir.

Aynı platform ayrıca emoji tepkileri, yanıt düzenleme, yumuşak silme ile çöp kurtarma, bir bildirim kutusu ve uçtan uca analizleri içeriyordu. Bir yan mobil uygulama olan Flutter da çevrimiçi oldu ve kimlik, biletler ve ekler için taze bir REST v1 API’si ile iletişim kurdu.

En çok şey öğreten küçük

Bir ithalat paketi, görünümlerinde sabit kodlanmış breadcrumb’lar içeriyordu. Çözüm, onları silmekti — ana uygulama zaten breadcrumb’ları küresel olarak oluşturuyor. Onları iki kez oluşturmak, bir stil hatası değil, bir sınır ihlali: paket, işinin parçası olmayan bir yerleşime girdi.

Öğüt

Üç ana fikir gün boyunca öne çıktı: senkronizasyon birleşir, bu nedenle idempotent oluşturun; gözlemlenebilirlik, bir hizmete ulaşmadan önce framework primitiflerinden oluşturulabilir; ve bir paketin işinin nerede sona erdiğini bilin — ana uygulamanın zaten sahip olduğu şeyi oluşturmaktan kaçının.