Geliştirici Günlüğü: 2026-06-22 — Yapılandırılabilir Zamanlayıcılar, Yük Testi Araç Setleri ve MCP Sunucusu

<p>Genellikle bir günde iş, birkaç projeye yayılabilir veya büyük bir özellik olarak toplanabilir. Bugün, her biri öğrenmeye değer olan üç farklı konu vardı. Detaylara girmeden, genel bir model üzerinden öğretmek istiyorum: <em>Hardcoded veya geçici olan her şeyi yapılandırılabilir, tekrarlanabilir ve güvenilir bir şeye dönüştürün.</em></p>

<h2>
    <a name="thread-1-make-scheduled-tasks-configurable-instead-of-codeonly" href="#thread-1-make-scheduled-tasks-configurable-instead-of-codeonly"></a>
    Thread 1 — Zamanlanmış görevleri yalnızca kod yerine yapılandırılabilir hale getirin
</h2>

<p>Bir Laravel uygulaması çalıştırdıysanız, zamanlayıcının kodun içinde, yani <code>routes/console.php</code> veya kernel'de bulunduğunu bilirsiniz; <code>-&gt;daily()</code>, <code>-&gt;everyFiveMinutes()</code>, <code>-&gt;cron(...)</code> gibi. Bu durum, bir operatörün — yazılımcı olmayan birinin — bir görevin ne zaman çalıştığını değiştirmek istediği güne kadar iş görür. O zaman, yalnızca bir cron ifadesini değiştirmek için yeniden dağıtım (deploy) yapıyorsunuz. Saçma.</p>

<p>Bugün, zamanlayıcı yapılandırmasını bir ayar destekli kullanıcı arayüzüne taşıdık. Bu model çalınmaya değiyor: zamanlama kodda bir literal olmak yerine, <em>ayarlar deposundan</em> okunuyor ve onu düzenlemek için bir yönetim ekranı var.</p>

<div class="highlight js-code-highlight">
    <pre class="highlight php"><code><span class="c1">// Hardcoded cadans yerine...</span>

<p>İki şey bu temizliği sağladı. İlk olarak, değerlerin tiplenmiş, önbelleklenen ve taşınabilir olduğu bir <code>SchedulerSettings</code> nesnesi (Spatie'nin ayar modeli) kullandık — bu, string anahtarla <code>Setting::get('...')</code> yapmaktan çok daha iyi. İkinci olarak, daha kullanıcı odaklı zamanlamaların kendi modalları altında gruplanması, her cron'u dev bir formda dökme yerine daha kullanışlı. Bir abonelikle ilgili zamanlama, aboneliklerin yanında yer alır; bir platform zamanlaması ise yönetim alanında yer alır. Aynı veri, ama <em>kimlerin dokunması gerektiğine</em> göre düzenlenmiş.</p>

<p>İzlenmesi gereken bir kenar durumu: Kullanıcı arayüzü ile düzenlenebilir bir cron ifadesi, insanlara saçmalık yazmaları için bir tuzak olabilir. İfadeyi kaydederken doğrulayın ve her zaman bir varsayılan bırakın, böylece boş bir ayar asla bir işi sessizce devre dışı bırakamaz.</p>

<h2>
    <a name="thread-2-a-loadtesting-toolkit-is-documentation-you-can-run" href="#thread-2-a-loadtesting-toolkit-is-documentation-you-can-run"></a>
    Thread 2 — Yük testi aracı, çalıştırabileceğiniz bir belgedir
</h2>

<p>İkinci konu, önceden tahmin edilebilen yoğun dönemler için kapasite planlama notları ile birlikte bir yük testi aracının geliştirilmesiydi — bu, normalin 10 katı trafiğin olduğu bilinen sezonluk zirveler gibi.</p>

<p>Şunu aktarmak istiyorum: <strong>Bir yük testi, büyük bir gün öncesinde panikle yapılan bir seferlik değil, taahhüt edilen bir eser olmalıdır</strong> — senaryoları, bir yürütücü, bir karşılaştırma adımını kapsayan, hepsi repo içinde bulunan scripted (senkronize edilmiş) senaryolar. Değer sadece rakamlar değil; "sistem zirvede ne yapar?" artık herkesin rahatça çalıştırabileceği bir komut haline gelir, bir mühendisin kafasındaki bir bilgi değil.</p>

<p>İşleyen yapı: her trafik profili için ayrı senaryo yapılandırmaları (normal saatler vs. birçok farklı zirve şekli), yaygın kurulumlar için ortak bir kitaplık, tek bir yürütücü ve yan yana iki çalışmayı karşılaştırabileceğiniz bir karşılaştırma betiği. Kapasite planlama, o durumda her zaman yanına yazmamızı sağlıyor — varsayımlar kaydedilmiş, böylece bir sonraki çeyrekte her şeyi yeniden hesaplamak yerine bir belge güncelliyorsunuz.</p>

<p>Öğrenilmesi gereken nokta: zirve senaryolarını açıkça planladığınızda, <em>varsayımlarınızı adlandırmak</em> zorundasınız — beklenen eş zamanlı kullanıcılar, istek karışımı, kabul edilebilir p95. Bu adlandırma eylemi yarısının değeri. Belirsiz "zirveyi kaldırmalı" ifadesi, "işte profil, işte çalışma, işte nerede büküldü" haline gelir.</p>

<h2>
    <a name="thread-3-an-mcp-server-done-with-auth-taken-seriously" href="#thread-3-an-mcp-server-done-with-auth-taken-seriously"></a>
    Thread 3 — Gerçekten ciddiye alınan bir kimlik ile bir MCP sunucusu
</h2>

<p>En büyük konu, bir Model Context Protocol (MCP) sunucusunun Laravel uygulamasına entegre edilmesi, böylece AI ajanlarının belirtilmiş, izin denetimli araçları çağırabilmesi oldu; kullanıcı arayüzüne müdahale etmeden. Bu konunun kendi başına bir ayrıntılı yazısı var çünkü kimlik doğrulama unsuru oldukça dikkat çekici — dual kimlik doğrulaması (birinci taraf çağırıcılar için Sanctum, delege üçüncü taraf ajanlar için OAuth 2.1), her aracın bir RBAC yeteneğine haritalanması ve çıktının belirli projeksiyonlara göre düzenlenmesi, böylece bir araç tüm modeli sızdırmaz.</p>

<p>Kısacası: bir MCP sunucusu, AI ajanları için bir resepsiyon masasıdır — kim olduklarını kontrol eder, ne yapmalarına izin verildiğini kontrol eder, yalnızca bir adlandırılmış görevi yerine getirir ve yapılandırılmış bir yanıt döndürür. Diğer her şey resepsiyon masasında kalır. (Tam ayrıntılar ayrıntılı yazıda.)</p>

<h2>
    <a name="the-thread-that-ties-them-together" href="#the-thread-that-ties-them-together"></a>
    Hepsini birleştiren ipucu
</h2>

<p>Yapılandırılabilir zamanlayıcılar, taahhüt edilen yük testleri, araç tabanlı bir AI yüzeyi — görüldüğü gibi, bağımsız konular. Ama aynı içgüdüyü üç kez tekrar ediyor: <em>gizli olan bir şeyi</em> (koda gömülü bir cadans, birinin hafızasında yaşayan zirve davranışı, "AI, API'mizi biraz kullanıyor") alıp <em>açık ve kullanılabilir</em> hale getiriyoruz — yapılandırılmış, script edilmiş, yetkilendirilmiş. Bu, "bir sistemin olgunlaşmasını sağlamak" anlamının çoğudur.</p>

<p>Sonraki adım: kullanıcı arayüzü ile düzenlenebilir cron ifadelerini sağlam bir şekilde doğrulamak ve MCP yolundaki OAuth onay adımını sıkılaştırmak.</p>