Breeze v2, Go web frameworkünü yerleşik MCP ile AI-öncelikli platform olarak yeniden konumlandırıyor

gnet ağ kütüphanesi üzerine inşa edilmiş, Go için olay güdümlü bir web frameworkü olan Breeze, ikinci ana sürümünde AI-öncelikli bir uygulama platformu olarak yeniden konumlandırıldı. dev.to'da yapılan duyuruda projenin yazarı, v2'yi AI agent'ları, API'ler, servisler, workflow'lar, gözlemlenebilirlik (observability) ve runtime altyapısının tamamının birincil tasarım kaygıları olarak ele alındığı bir sistem olarak tanımlıyor; yani etrafına bir AI katmanı sarılmış bir web frameworkünden bahsetmiyor.

Web frameworkünden uygulama platformuna

Yazının temel argümanı mimari. Çoğu backend, insan istemciler ve dahili servisler için tasarlandı; agent'ların gelişi ise ekipleri ek katmanlar takmaya itti: bağımsız bir MCP sunucusu, ikinci bir kimlik doğrulama sistemi, ek API adaptörleri ve araçları açığa çıkarıp üretimi incelemek için ayrı bir yol. Yazar bunu tersten kurulmuş bir yaklaşım olarak görüyor — agent'lar yazılımın önemli tüketicileri haline geliyorsa, frameworkün kendisi onları baştan itibaren anlamalıdır.

dev.to duyurusuna göre Breeze v2 üç bileşen etrafında yapılandırılmış durumda: agent'lara uygulamaya standart bir arayüz veren MCP; dağıtık sistemlere yönelik birleşik bir gözlemlenebilirlik ve tracing katmanı olan Fleet; ve her şeyi birbirine bağlayıp uygulama kontrolünü üstlenen bir runtime.

Yalnızca üretmeyen, işletebilen bir agent

MCP, Breeze'te bir plugin değil — frameworkün kendisinin bir parçası. breeze-mcp --mode=generator ile başlatılan ilk exposure modu, geliştirme agent'larına yönelik yaklaşık 40 araç sunuyor. Yazıda listelendiği üzere bunlar; proje iskeleti oluşturma, resource üretme, framework özelliklerini bağlama, değişiklik setleri planlama, Go araç zincirini çalıştırma, servisleri, route'ları, hataları, logları, performansı ve trace'leri inceleme, sözleşme (contract) ihlallerini tespit etme, servis teşhisi ve Docker farkındalıklı fleet provisioning kapsıyor.

Buradaki çerçeveleme önemli: bir agent projenin nasıl yapılandırıldığını tahmin etmek yerine, tanımlı bir yetenek kümesi alıyor. Yazarın ifade ettiği hedef, basit kod üretimini aşarak bileşik taleplere geçmek — bir servis oluşturmak, açığa çıkarmak, testleri çalıştırmak, sonucu incelemek ve sorunları raporlamak — anlama, planlama, üretme, derleme, çalıştırma, inceleme, teşhis etme, değiştirme ve doğrulama döngüsünü izleyerek.

Üretim erişimi yapısal olarak salt-okunur

--mode=app-runtime adlı ikinci mod, çalışan bir sistemi agent'lara açıyor ancak salt-okunur. Yazı, net güvenlik sonuçları olan bir tasarım tercihinin altını çiziyor: değişiklik yapan araçlar yalnızca bir izin kontrolünün arkasına gizlenmiş değil — baştan hiç kayıt edilmiyorlar. Bir üretim agent'ı inceleyebilir, teşhis koyabilir, gözlemleyebilir ve analiz edebilir; ama yanlışlıkla tetiklenmeyi bekleyen bir mutasyon yüzeyi ortada yok. Yazar, AI altyapısının ihtiyaç duyduğu sınırın bu olduğunu savunuyor.

Süreç içi MCP ve araca dönüşen route'lar

Tasarımı tamamlayan iki yetenek daha var. MCP doğrudan bir Breeze uygulamasının içine gömülebiliyor; böylece bir uygulama, ayrı bir MCP süreci çalıştırmadan kendi MCP kontrol düzlemini normal HTTP trafiğinin yanında barındırabiliyor — aynı uygulama, aynı runtime, farklı tüketiciler; yetenek kapsamı, port ve token kod içinde tanımlanıyor.

Yazarın Auto-MCP adını verdiği diğer yetenek ise geliştiricilerin mevcut bir route'u yalnızca etiketleyerek agent tarafından çağrılabilir hale getirmesini sağlıyor; örneğin breeze.MCPTool("create_order", "Places an order for a customer.") gibi. Etiketlenmemiş route'lar açığa çıkmıyor. Kritik nokta şu: ortaya çıkan araç çağrısı, HTTP ile aynı middleware zincirinden geçiyor; dolayısıyla kimlik doğrulama ve diğer middleware'ler hâlâ geçerli. Yazı, Auto-MCP'nin uygulamanın mimarisini bypass etmediğini vurguluyor — agent'lar için kopyalanmış bir handler yok, sadece insanlara da modellere de hizmet veren tek bir route var.

Neden önemli

Breeze v2, birçok platform ekibinin şu anda sorduğu bir soruya erken ve somut bir yanıt denemesi: agent'lar sonradan eklenen bir düşünce değil, beklenen istemcilerse bir backend nasıl görünür? Üç ayrıntı öne çıkıyor. HTTP middleware zincirinin yeniden kullanılması, auth, doğrulama ve rate limiting'in agent çağrılarına otomatik olarak uzanması anlamına geliyor; bu, ekipler ayrı araç sunucuları kurduğunda ortaya çıkan yaygın bir boşluğu kapatıyor. Üretim modunda değiştirici araçların kayıt edilmemesi, bir izin bayrağından daha güçlü bir güvence; çünkü tehlikeli yetenek runtime'da basitçe mevcut değil. Ve route düzeyinde opt-in yaklaşımı, agent yüzeyini her şeyi varsayılan olarak açığa çıkarmak yerine açık seçik tutuyor.

Belirgin uyarı şu: bu birinci elden bir duyuru; araç sayıları, güvenlik özellikleri ve mimari iddiaların tamamı projenin kendi dev.to yazısından geliyor ve gerçek dünyadaki olgunluk henüz kanıtlanmalı. Yine de, backend frameworklerinin nereye gidebileceğine dair bir tasarım sinyali olarak izlenmeye değer bir hikaye.