CarvePHP’i Geliştirdim: Laravel Monolitlerinde Hizmet Sınırlarını Belirleme

CarvePHP’yi Geliştirdim: Laravel Monolitlerinde Servis Sınırlarını Belirleme

Yeni bir açık kaynak Laravel paketi olan CarvePHP v0.1.2-alpha‘yı duyurdum. Bu paket, takımların büyük Laravel monolitlerini analiz etmelerine ve olası servis sınırlarını tanımlamalarına yardımcı oluyor.

Bu fikrin temelinde yaygın bir sorun yatıyor:

Bir monolitten servislere geçiş yapmak zor değildir; zor olan, neleri ayıracağınızı ve neden ayıracağınızı karar vermektir.

Çoğu Laravel monoliti zamanla doğal olarak büyür. Route’lar, controller’lar, model’ler, migration’lar, job’lar, olaylar ve veritabanı tabloları, klasör yapısından her zaman açık olmayan şekillerde birbirine bağlı hale gelir.

CarvePHP, bu bağlantıları görünür hale getirmeyi amaçlıyor.

CarvePHP Neler Yapıyor?

CarvePHP, statik analiz ve çalışma zamanı izleme yöntemlerini bir araya getiriyor.

Mevcut alfa sürüm özellikleri:

• Laravel route’larını, controller’larını, model’lerini, migration’larını ve veritabanı kullanımını tarar
• İsteğe bağlı olarak gerçek çalışma zamanı route/tablo bağlantılarını izler
• Bağımlılık grafiği oluşturur
• Olası servis sınırlarını önerir
• Markdown/JSON migration raporları oluşturur

Bu, “tek tıklama ile mikro servisler” aracı değildir.

Bu yanıltıcı olurdu.

Hedef, geliştiricilerin daha güvenilir ve açıklanabilir migration kararları vermelerine yardımcı olmaktır.

Örnek Çalışma Akışı

Composer ile kurulum yapın:

composer require carvephp/carve:^0.1@alpha --dev

Sonrasında şunları çalıştırın:

php artisan carve:install
php artisan carve:doctor
php artisan carve:scan --pretty
php artisan carve:analyze
php artisan carve:boundaries --report=carve-boundaries.md
php artisan carve:report --output=carve-report.md

Çıktı, olası sınırları, ilişkili route’lar/controller’lar/model’ler/tabloları, bağlılık sinyallerini ve uyarıları gösteren bir migration raporudur.

Neden Statik Analiz Yeterli Değil?

Statik analiz, kodun göründüğü gibi hangi unsurlara bağımlı olduğunu gösterebilir.

Ancak gerçek uygulamalar, çalışma zamanında farklı davranabilir.

Örneğin:

• Bir route, birden fazla tabloya dokunabilir
• İki tablo, sıklıkla aynı istek içinde birlikte görünebilir
• Bir controller, bir servis aracılığıyla dolaylı olarak bir modele bağımlı olabilir
• Paylaşılan tabloların ayrılması riski yüksek olabilir

Bu nedenle CarvePHP, isteğe bağlı çalışma zamanı izlemesi desteği sunmaktadır.

Çalışma zamanı izleme varsayılan olarak devre dışıdır ve güvenli olacak şekilde tasarlanmıştır. Varsayılan olarak istek gövdelerini veya SQL bağlamalarını kaydetmez.

Örnek Sınır Fikri

Bir rapor, aşağıdaki gibi bir sınır önerebilir:

Candidate: Billing

Tables:
- invoices
- payments
- customers

Evidence:
- invoice ve payment route’ları ilgili tablolara dokunuyor
- invoices ve payments çalışma zamanı izlerinde bir arada görünüyor
- billing controller’ları ve model’leri güçlü bir şekilde bağlantılı
Risk:
- customers tablosu diğer alanlarla paylaşılabilir

Bu, “otomatik olarak Billing’i ayırın” demek değildir.

Bu demektir ki:

“Burada bir olası sınır var ve arkasındaki kanıt burada.”

Gerçek bir migration işlemine başlamadan önce bu tür bilgileri isterim.

Henüz Neleri Yapmıyor?

CarvePHP hala alfa aşamasındadır.

Şu anda aşağıdakileri sağlamaz:

• otomatik hizmet çıkarma
• otomatik veritabanı bölme
• üretime hazır migration orkestrasyonu
• garantili mükemmel sınırlar

Bu, zor sorunlardır ve pazarlama diliyle gizlenmemelidir.

Şimdilik, CarvePHP analiz, görünürlük ve açıklanabilir raporlara odaklanmaktadır.

Desteklenen Sürümler

Mevcut alfa sürüm desteklemektedir:

• PHP 8.2+
• Laravel 11, 12 ve 13
• Composer 2.x

Bağlantılar

GitHub:

https://github.com/Muhammad-Waleed-Khalil/CarvePHP

Packagist:

https://packagist.org/packages/carvephp/carve

Kurulum:

composer require carvephp/carve:^0.1@alpha --dev

Geri Bildirim İstenen

Büyük monolitlerle çalışmış Laravel/PHP geliştiricilerinden geri bildirim almak istiyorum.

Birkaç soru:

• Bir servis sınır önerisini güvenilir bulmadan önce ne tür kanıtlara ihtiyacınız olur?
• Grafik görselleştirme faydalı olur mu?
• Bir sonraki sürüm, FormRequest analizi, API Resource analizi veya daha iyi raporlama üzerine mi odaklanmalı?
• Tarayıcı hangi Laravel kalıplarını öncelikle desteklemelidir?

Her türlü geri bildirim, eleştiri veya gerçek dünya uç durumları değerlendirilecektir.