Şimdi yükleniyor

Seçtiklerimiz

Geliştirici Araçları Veri & Analitik , , , , , , ,

Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder’ın Multi-Source Sihri

Birden Fazla Veritabanını Tek API ile Bağlamak: Data API Builder Multi-Source
⏱️ 6 dk okuma📅 26 Mart 2026

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 halde 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 yani! İ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ğı haline 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… yazımıza da göz atmanızı tavsiye ederim.

💡 Bilgi: Multi-source kurulum sayesinde merkezi authentication & cache politikalarını net biçimde kurabildik — eskiden saatler süren kabus senaryosu şimdi beş dakikalık iş oldu.
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… Tabii connection pooling ayarı çok kritik onu 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? Ya… 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:

    💡 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!

İçeriği paylaş:

İlgili Yazılar

Etiket

Yorum gönder

A.KILIÇ

Microsoft Azure & Office 365 Çözüm Uzmanı | Logosoft Bilişim'de Azure Danışmanı. 20+ yıl BT deneyimi, 6+ Azure sertifikası (AZ-305, AZ-104, AZ-500, AZ-400). Kurumsal bulut göçleri, güvenlik mimarisi, FinOps ve DevOps dönüşümü konularında stratejik danışmanlık sunuyorum. Bu blogda Azure, yapay zeka, Kubernetes ve modern bulut teknolojileri hakkında güncel içerikler paylaşıyorum.

view all posts

İlginizi Çekebilir

SİZİN İÇİN DERLEDİK