Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder’ın Multi-Source Sihri
Durun Bir Dakika, Gerçekten Tek API ile Kaç Farklı Veritabanı Yönetebilirsiniz?
Açıkçası, Bunu ilk duyduğumda “Yok artık, bu kadarı da fazla” dedim içimden. Data API Builder’ın (DAB) çoklu kaynak desteği—hani şu aynı anda birden fazla veritabanını tek endpoint’ten açma işi—gerçek mi sahiden? Şaka gibi ama gerçek; isterseniz SQL Server, PostgreSQL ve Cosmos DB’yi tek endpoint’ten sunun, kimse size ‘O işler öyle olmuyor kardeşim’ diyemiyor. Oluyor çünkü.
Dürüst olmak gerekirse, Kariyerimin başında – özellikle 2021’de finans sektöründeki büyük çaplı göçte – poliglot veri yönetimi bana fena hâlde saç döktürmüştü. O zamanlar farklı arabirimler ve güvenlik katmanlarıyla boğuşuyorduk. Şimdi DAB’in multi-source özelliğini deneyince gelen ferahlığı anlatamam… Kafamda ampul yandı desem yeridir. Neler değişti? Hadi bakalım.
DAB Multi-Source Özelliğine Bakış: Lafı Gevelemeden
JSON Konfigürasyonuyla Sınırları Zorlamak
DAB’in kalbinde o klasik JSON config dosyası var ya… Herkesin bildiği dab-config.json, işte onunla oynayacaksınız diye bir kural yok aslında – adını ne koyarsan koy sistem sallamıyor bile. “Benim-cool-konfig.json” mu yazdınız? Çalışır.
Şöyle söyleyeyim, Püf noktası: Ana bir konfig dosyanız olacak; oraya data-source-files diye bir dizi ekliyorsunuz. Her eleman başka child config’i gösteriyor. Hepsini topluyor, sanki elinizde devasa tekil bir veri kaynağı varmış gibi davranıyor sistem (en azından benim deneyimim böyle)
{
"data-source-files": [
"dab-config-catalog.json",
"dab-config-inventory.json",
"dab-config-recommendations.json"
]
}
Vallahi, Bak 2019’da kendi hosting firmamda benzerini yazmaya kalkıştım; haftalarca debelendim! Şimdi üç satır JSON yetiyor… İnsanın aklı almıyor bazen.
Kod Yazmadan Gerçekten Entegre Olur mu?
Eh, Bana sorarsanız olay burada kopuyor: Ne client’a yeni kod gerek, ne backend tarafına satırlarca patch çekiyorsunuz. Bütün entity tanımlarınızı çocuk konfiglere dağıtıp ana dosyada yalnızca üst seviye ayarlarla ilgilenmek yetiyor.
Data API Builder sayesinde ister REST ister GraphQL üzerinden tablonuz hangi veritabanında olursa olsun hepsine tek endpoint’ten erişiyorsunuz — tam anlamıyla üşengeç geliştirici lüksü!
Runtime Ayarlarında Dikkat Edilecekler
Ana config’te belirlediğiniz runtime seçenekleri (authentication, policy, cache vesaire) tüm bağlı kaynaklara şak diye uygulanıyor otomatikman. Child config’e runtime bölümü koysanız da DAB takmıyor — log’a minik uyarı atıp yoluna devam ediyor yanı! İlk denediğimde ben de şaştım kaldım; gereksiz uğraşmayın boşuna (yanlış duymadınız)
Küçük Startup mı Kurumsal Dev mi? Farklı Senaryolarda Multi-Source Kullanımı
Startup Dünyasında Hız ve Esneklik İhtiyacı
Düşünün ki elinizde üç microservice var – biri SQL Server kullanıyor diğeri Postgres öbürü apayrı… Modern startup mimarisinin vazgeçilmez karmaşası! Bu ekipler hızlı gitmek ister. Kontrol ellerinden kaçsın istemezler:
- Tüm microservis tablolarını ortak endpoint’e toplamak çocuk oyuncağı hâline geliyor.
- Ekipler ayrı migration yapsa bile API yapısı sabit kalıyor; versiyonlama derdi azalıyor resmen.
- Zaman-maliyet konusunda ciddi kazanç sağlanıyor — bak bunu birebir yaşadığım için rahatça söylüyorum!
Büyük Kurumsalda Yetki ve Güvenlik Kâbusu Çözümü
Peki bankacılıkta departmanlar arası veri paylaşımı projesinde bulundunuz mu hiç? Ben Logosoft ile geçen yıl buna kafa patlattım (müşteriyi anmam hoş olmaz şimdi). Her departmanın farklı DB’si vardı ama BI ekibi bunların hepsini görmek istiyordu… Bu konuyla ilgili VS Code’da MSSQL Eklentisinin 1.40 Güncellemesi: Gerçekten Fark Yaratıyor mu? yazımıza da göz atmanızı tavsiye ederim.
| Senaryo / Özellik | Multi-Source Olmadan | DAB Multi-Source ile |
|---|---|---|
| Küçük Startup’da Veri Erişimi | Ayrı ayrı backend servisleri gerekir | Tek endpoint yeterli |
| Büyük Kurumda Yetki Yönetimi | Dolaşıklık/Çakışma riski yüksek | Tüm data kaynaklarında tutarlı auth/policy |
| Maliyet/Karmaşıklık | Ciddi mühendislik gideri olur | Sadece konfig güncellemesiyle ilerlenir |
Beni Etkileyen Detaylar ve Gözlemlediğim Eksikler
Sistemin Dayanıklılığı Beklediğimden İyi Çıktı Ama…
Dürüst olayım—DAB’in multi-source tarafının ölçeğe dayanacağını pek sanmıyordum başta. En çok da eşzamanlı sorgu sayısı uçunca bottleneck oluşur sandım (hatta AZ-305 çalışırken böyle edge-case vakalar gözümün önünden geçiyordu). Uygulamaya gelince hem REST hem GraphQL performansı baya tatmin etti beni… Tabiî connection pooling ayarı çok kritik önü unutmayın!
Hangi Veritabanlarını Destekliyor?
- Azure SQL Database / SQL Server
- PostgreSQL
- Cassandra
- Cosmos DB
- (Liste sürekli uzuyor)
Miks yapmak serbest (örneğin Azure SQL + Cosmos DB), yeter ki bağlantı bilgilerini doğru girin! Yalnız bazı advanced özelliklerde hâlâ eksikler var; custom policy işleri henüz gelişme aşamasında… Bunları es geçmeyin derim. Daha fazla bilgi için VS Code’da MSSQL Eklentisinde Neler Değişti? Yapay Zekâlı Şema Tasarımı ve Daha Fazlası yazımıza bakabilirsiniz.
Neredeyse Kod Yok – Sadece JSON Yazarak Yönetmek Nasıl Bir His?
Neden Geliştirici Deneyimini Değiştiriyor?
Kimisinin basit bulacağı tarzdan ama düşünsenize — bugüne kadar hep ORM veya code-first alışkanlığıyla gittik ya (evet, doğru duydunuz). Burada %99 oranında her şey konfig’de bitiyor! Mart ayında test ortamında iki ayrı Postgres bağladığımda bitti gitti dedim:
- Sıfır kodla cross-db veri paylaşımı kurdum,
- Anlık hotfix gerektiğinde sadece config dokundum,
-
Sıfır deployment riskiyle prod’a çıkabiliyorsanız… Vallahi o sisteme laf söylenmez!
MCP Endpoint’i ile Agentic Uygulamalara Açılan Kapı mı?
Birkaç ay evvel MCP endpoint üzerinde oynarken jeton düştü bende – klasik data query dışında AI veya agent uygulamalarına doğrudan bağlanan client’lar için mükemmel kolaylık sunuyor bu yapı.
Misal yakınlarda Data API Builder MCP’ye dair detay notlarımı paylaştığım yazıya bakabilirsiniz:
Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi💡 Bilgi: Popülerleşen agentic application trendinde çoklu kaynaktan beslenen GraphQL/REST/MCP endpoint’i büyük avantaj — hele Zapier veya Power Automate gibi platformlarla entegrasyon işindeyseniz tadından yenmez!Peki Dezavantajları Var mı? Hayal Kırıklıkları Nerede Başlıyor?
Zincirin En Zayıf Halkası Yine Konfigürasyonun Kendisi mi?
Bazılarının unuttuğu gerçek şu ki… Kolaylaştırmak kimi zaman risk getirir! Yanlış dizilimde bir child config yüklemek yahut production’a hatalı connection string vermek felaket getirebilir.
Geçen hafta eski müşterimde staging ortamındaki “child”lardan biri eksik yüklenmişti – oturumlar birbirine girdi kısacası; otomasyona güvenip elle de kontrol etmek şart!- Migrasyon sırasında yanlış child config gözden kaçabilir,
- Kısacası “her derde deva” demeyeceğim; ileri düzey RBAC politikalarında ya da transaction bütünlük isteyen işlemlerde hâlâ elde kod yazmanız gerekebiliyor.
Ama pratikte çoğu iş için gayet makul hatta fazlasıyla başarılı buluyorum… Özetle idare eder değil, baya iyi diyebilirim!Daha Derine İnmek İsteyenlere Ek Kaynaklar & Pratik Notlarım:
- Dökümantasyonu mutlaka inceleyin, zira sürekli güncelleniyor:
Data API Builder Documentation — Microsoft Learn - Anında deneyebileceğiniz örnek repo:
Azure/DataApiBuilder Samples — Multi Database Demo Repo (GitHub) - MCP özelliklerine dair son tecrübemi anlattığım blog post’um:
Veritabanına Akıllı Soru Sorabilen AI: Data API Builder MCP ile Güvenli Analiz Dönemi - Eğer Polyglot altyapısının maliyet tarafına kafayı taktıysanız şu yazıda başka pencereler açılıyor:
Polyglot Veritabanı Maliyeti — Tüm Yumurtaları Aynı Sepete Koymanın Bedeli Ne? - Klasik Azure SQL gelişmelerinden geri kalmak istemeyenlere gelsin:
SQL Server’da JSON Depolama Yenilikleri - Daha fazla Azure haberlerine dalmak isteyen varsa
Azure SQL’de DiskANN Vektör İndeksleri hakkında yazımı inceleyebilir.
Sıkça Sorulan Sorular
DAB multi-source özelliği ile kaç farklı türde veritabanını aynı anda bağlayabilirim?
Theoretically sınırı yok dostum; desteklenen tüm motorları yan yana bağlayabiliyorsun (mesela Azure SQL + Cosmos DB + PostgreSQL), yeter ki her biri için bağlantıyı sağlamış ol!
Ana ve child konfigürasyonlarda çakışan entity tanımları olduğunda ne olur?
Sistem duplicate entity isimlerinde hata verir ya da son okunan geçerli olur; entity adlarına dikkat edin yoksa endpoint kavgasından kurtuluş zor!
MCP Endpoint nedir? Multi-source yapı ile nasıl kullanılabilir?
MCP Endpoint yeni nesil agent uygulamalarına özel tasarlanmış ekstra erişim noktasıdır. Çoklu kaynaktaki datayı birleşik şekilde sorgulayabilir veya AI workflow’una entegre edebilirsin, önü açık yanı (evet, doğru duydunuz)
Sadece JSON yazarak ileri seviye yetkilendirme kontrolleri tanımlamak mümkün mü?
Evet ama advanced policy ihtiyaçlarında sınırlamalar olabilir; RBAC gibi ileri senaryolarda arada elde middleware eklemek gerekebilir hâlâ (ciddiyim)
Kaynaklar ve İleri Okuma
- Dökümantasyonu mutlaka inceleyin, zira sürekli güncelleniyor:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
