Size bir şey söyleyeyim, Bir REST API yazıp da “ben bunu bir kere kurayım, sonra yıllarca el sürmeyeyim” diye düşünen herkesin başına aynı şey geliyor. Veri modeli değişiyor. İlişkiler büyüyor, endpoint’ler şişiyor. Bir bakıyorsunuz asıl iş kod yazmak falan değil, bağlantıları tekrar tekrar yamamak olmuş — hani tam anlamıyla yama üstüne yama (bizzat test ettim). İşin aslı şu ki, bazı projelerde asıl yorucu olan CRUD değil; o CRUD’ın etrafındaki yön bulma işi,. “bu veri nereden geliyor, şu tablo buna nasıl bağlı, şu link neden kırıldı?” soruları. LinkLab tam burada sahneye çıkıyor.
Geçen sene, 2024’ün Kasım ayında İstanbul’daki küçük bir SaaS ekibiyle konuşurken benzer bir dert duymuştum. Ekip PostgreSQL’den MongoDB’ye geçmeyi düşünüyordu; çünkü ilk sürümde JSON rahat gelmişti. Sonra raporlama isteği artınca Postgres’e dönme fikri çıktı. Klasik hikâye. Şema değiştikçe join’ler de değişiyor, route’lar da, hatta bazen frontend’deki link yapısı bile — yani tek bir değişiklik zincirleme reaksiyona dönüşüyor. LinkLab’ın beni meraklandıran tarafı biraz da bu oldu açıkçası.
Çünkü ortada bildiğimiz anlamda bir ORM yok (şaşırtıcı ama gerçek). Bu önemli. ORM dediğiniz şey çoğu zaman iyi niyetle başlıyor ama sonra sizi gizli sorgulara, fazla soyutlamaya. “bu SQL aslında ne yapıyor, neden bu kadar yavaş?” sorusuna götürüyor — oradan çıkmak da cabası. LinkLab ise başka bir yerden yaklaşıyor: var olan şemayı alıp üstünde gezinilebilir bir ilişki grafiği çıkarıyor. Yani veriyi saklamıyor gibi görünmek yerine, verinin yollarını görünür kılıyor. Fark var.
LinkLab neyi çözüyor, neyi çözmüyor?
Küçük bir detay: Bakın şimdi, bu araç için en doğru cümle şu olabilir: “Her şeyi halletmez. Bazı can sıkıcı işleri ciddi biçimde azaltır.” Mesela tablo-tablo ilişkisinin bol olduğu sistemlerde manuel join yazmak artık refleks hâline geliyor — kimse sorgulamıyor bile, otomatik yazıyorsunuz. Sonra biri küçük bir kolon adı değiştiriyor ve zincir bozuluyor. Ben bunu 2023 baharında Ankara’da çalışan bir e-ticaret projesinde bizzat yaşamıştım; tek bir foreign key güncellemesi yüzünden üç ayrı servis yeniden test edilmişti. Yorucu muydu? Evet, çok.
Çok konuştum, örnekle göstereyim.
Yani, LinkLab burada tabelanın üstüne dev bir ok çizmek gibi çalışıyor diyebiliriz. Ama abartmayalım. Bu sihir değil. Migrations yönetmiyor, tabloyu nesneye çevirmiyor, SQL’i perde arkasına itip “güven bana” demiyor. Tam tersine ürettiği sorguları canlı görüyorsunuz. Bu bence fena değil, hatta baya işe yarayan bir tavır — özellikle debug sırasında.
Gel gelelim eksik tarafı da var tabi. Eğer veri modeliniz çok gevşekse ya da ilişkileriniz zaten düzensizse, otomatik keşif size beklediğiniz kadar temiz sonuç vermeyebilir. Yani küçük startup için hızlı keşif sağlar; enterprise tarafta ise disiplinli şema şart olur. Aksi hâlde grafik güzel görünür. Pratikte yol tarif etmeyebilir — haritası olan ama sokakları eksik bir şehir gibi düşünün.
LinkLab’ın sağlam yani “soyutlama” kelimesini yanlış anlamaması. Veriyi saklamıyor; ilişkileri okunur hâle getiriyor.
Klasik yaklaşım neden yoruyor?
Vallahi, Şöyle bir düşünün. REST API geliştirirken çoğu ekip önce JSON ile başlıyor… sonra MongoDB deniyor… ardından Postgres’e dönüyor… ve her geçişte neredeyse aynı işleri yeniden yapıyor: sorgular, route’lar, resource linkleri, testler, seed verileri. Hepsini. Yeniden. Bu durum biraz taşınırken her seferinde aynı kutuları yeniden etiketlemek gibi — kutu aynı kutu, içindeki düzen sürekli dağılıyor, siz de sürekli toparlamaya çalışıyorsunuz.
Durun, bir saniye.
Bunu özellikle ekip büyüdüğünde hissediyorsunuz. Tek geliştirici olduğunuzda “ben bilirim” diyorsunuz; beş kişi olunca herkesin bildiği farklı oluyor, herkesin anladığı farklı oluyor. Bir arkadaşımın Köln’deki ürün ekibinde 2024 Mart’ında yaşadığı olay aklıma geliyor: yeni gelen geliştirici eski join mantığını yanlış yorumlayınca rapor servisi tam iki gün yanlış veri üretmişti. Kimse kötü niyetli değildi. Sistem sadece fazla kırılgandı. Bu konuyla ilgili Ddev’e Aljibe Eklemek: Kurulu Projede Sürprizler yazımıza da göz atmanızı tavsiye ederim.
Aslında, İşte bu yüzden araçların amacı bazen kod yazdırmak değil, kodun etrafındaki belirsizliği azaltmak oluyor. Hmm, nasıl desem… LinkLab’ın iddiası da burada netleşiyor: mevcut projeye sıfırdan müdahale etmeden ilişki haritası çıkarabiliyorsan, değerlendirme maliyeti düşer — ve bu küçük ama gerçek bir kazanım. Bu konuyla ilgili Deutsche Börse’nin Kraken Hamlesi: Kriptonun Yeni Gerçeği yazımıza da göz atmanızı tavsiye ederim.
Evet, doğru duydunuz.
Dvdrental örneğinde iş nasıl ilerliyor?
Orijinal yazıda PostgreSQL’in meşhur dvdrental örneği üzerinden gidiliyor ve açıkçası bu iyi seçim olmuş. Neden? Çünkü ortada yapay olarak hazırlanmış oyuncak veri yok; ilişkiler gerçek hayata daha yakın duruyor. Ben de böyle örnekleri seviyorum — rafine demo ile prod ortamının arasındaki uçurum bazen Everest kadar oluyor, bunu yaşayan bilir. Amazon’un Uydu Hamlesi: Globalstar İçin 11,57 Milyar Dolar yazımızda bu konuya da değinmiştik.
Süreç kabaca üç adımda ilerliyor gibi düşünebilirsiniz: başlatıyorsunuz, bağlantıyı tanımlıyorsunuz, sonra build alıyorsunuz ve REPL’e giriyorsunuz (inanın bana). Buradaki hoş nokta — ki bu tartışılır — şu — manuel join tanımı yazmadan grafiğin oluşması insanı önce şaşırtıyor, sonra rahatlatıyor. İlk çalıştırdığımda “bu kadar mı?” diye iki kere baktım doğrusu.
linklab init dvdrental
# bağlantı ayarlarını yap
linklab build dvdrental
linklab repl dvdrentalBu akışın güzelliği basitlikte yatıyor ama biraz da sınırlarında gizli zayıflık var tabi. Eğer veri sözlüğünüz karışıksa ya da isimlendirme standartlarınız yoksa otomatik çıkarım her şeyi mucize gibi çözemiyor. Araç güçlü ama sihirbaz değnek değil — bunu baştan kabul etmek gerekiyor.
| Konu | Klasik yöntem | LinkLab yaklaşımı |
|---|---|---|
| Sorgu yazımı | Elle join ve route kurulur | Grafikten yol çözülür |
| Schemanın değişmesi | Pek çok dosya etkilenir | Etkisi daha kontrollü olur |
| Görünürlük | Sorguyu takip etmek zorlaşabilir | Üretilen SQL görülebilir kalır |
| Ekip adaptasyonu | Daha fazla dokümantasyon ister | Kavramsal olarak daha okunaklıdır |
Kime uygun, kime pek değil?
Küçük bir startup için LinkLab baya ilginç olabilir. Ekip hızlı hareket etmek isterken sürekli altyapı borcu ödemek istemez — kim ister ki? Mesela ürün henüz şekilleniyorsa ve tablolar sık değişiyorsa ilişki katmanını otomatik görmek ciddi vakit kazandırıyor.
İşin garibi, E tabi enterprise tarafta tablo değişir. Orada güvenlik politikaları, gözlemleme ihtiyaçları. Sert uyumluluk kuralları devreye girer; her soyutlama ekstra inceleme ister — haklı olarak da öyle olmalı zaten. Yani araç değerli olabilir ama süreçlere uydurulması gerekir, yoksa kurumsal güvenlik ekibi sizi durdurur.
Eh, Bana göre en iyi kullanım senaryosu şu olurdu: mevcut PostgreSQL tablosu olan ama API navigasyonunu elle sürdüren ekipler. Hele bir de veri odaklı dashboard projeleri veya iç araçlar için baya mantıklı duruyor — orada şema genelde daha stabil, ilişkiler daha net — bence çok yerinde bir karar —
Artıları kısa kısa söyleyelim
- Sıfırdan pek çok uygulamayı yeniden yazma baskısını azaltıyor.
- Aynı şemadan okunabilir rota grafiği üretiyor.
- Sorgular görünür kaldığı için debug süreci körleşmiyor. (bu kritik)
- Denenmesi kolay; küçük kapsamda test edip büyütebiliyorsunuz.
Peki eksileri?
Bence en hayati risk beklenti yönetimiyle ilgili. Eğer bunu “ORM’nin yeni versiyonu” sanarsanız hayal kırıklığı yaşayabilirsiniz — çünkü o rolü oynamıyor, zaten oynamak da istemiyor gibi davranıyor (ve iyi ki de öyle, bence bu bilinçli bir tercih). İkinci mesele ise veri modelinin kalitesi. Kötü modelden iyi rota çıkarmak kolay değil, bu araçla da kolay değil — bence çok yerinde bir karar —
Neden dikkat çekici buldum?
Editör masasında bu konuyu ilk gördüğümde aklıma direkt güvenlik projelerinde yaşadığımız eski bir problem geldi: sistem iyi çalışıyordu ama kimse hangi parçanın nereden beslendiğini tam bilmiyordu. Kimse. İşte bu tarz navigasyon katmanları aslında biraz harita işi yapıyor — “sen şurasındayken, şuraya gitmek için şu yolu kullan” diyor.
Benzer şekilde kendi yan projemde de 2024 Ağustos’unda SQLite’tan Postgres’e geçerken aynı acıyı yaşadım; linkler yeniden kuruldu, endpoint isimleri elden geçti ve birkaç saatlik iş iki güne uzadı. Maalesef. Ve o iki günün büyük kısmı kod yazmakla değil, “bu neden kırıldı?” sorusunu yanıtlamakla geçti.
Böyle anlarda insan şunu düşünüyor, açık konuşayım: “Ben gerçekten ürün mü geliştiriyorum yoksa altyapının ayakta kalmasını mı sağlıyorum?” İşte LinkLab’ın cevabı ikinci kısmı hafifletmek gibi görünüyor. Ha, burada kritik fark şu — araç sizin yerinize karar vermiyor; sadece karar vermeyi kolaylaştıracak görünürlüğü veriyor. Bu küçük ama önemli bir ayrım.
Aman ha, unutmayın: noktalar
Bi saniye — Birinci nokta şu: otomatik keşif çıktısını kutsallaştırmayın! Grafik güzel görünebilir ama gerçek dünya verisinde kenar durumlar çıkar; boş alanlar olur, isimlendirme tutmaz ya da beklenmedik pivot tablolar sizi saatlerce uğraştırır. Görsel güzellik her zaman işlevsel doğruluğu garantilemiyor (en azından benim deneyimim böyle)
İkinci nokta performans tarafı olabilir. Build aşamasında analiz yapılması normaldir. Büyük şemalarda bunun maliyeti artabilir — yani küçük demo ile büyük prod aynı hissi vermez, bunu test etmeden üretime almayın (buna dikkat edin)
Kullanmadan önce kendinize sorun:
- Tablolarınız düzenli mi? (bu kritik)
- İlişkileriniz açıkça tanımlı mı?
- Aynı kaynağı kaç servis tüketiyor? — ciddi fark yaratıyor
- Sorguları görmek mi istiyorsunuz yoksa tamamen soyutlamak mı?
Sıkça Sorulan Sorular
LinkLab ORM mi?
Hayır, ORM değil. Tabloyu nesneye çevirip ilişkileri gizlemiyor; mevcut şema üzerinden gezinilebilir yollar çıkarıyor. Üretilen SQL’i görünür bırakıyor (inanın bana)
Sadece yeni projelerde mi kullanılır?Hayır, mevcut projeye de uygulanabiliyor incelediğim kadarıyla en sevdiğim taraflarından biri de bu oldu zaten sıfırdan taşıma dayatmaması.
Büyük ekiplerde işe yarar mı?Evet ama disiplin şartıyla yararından söz edilebilir.; özellikle temiz şema ve net isimlendirme varsa faydası artar aksi durumda otomatik grafik kafa karıştırabilir.
Kendi verimle test edebilir miyim?Evet tam da önerilen şey bu kendi data’nızla denemeniz çünkü demo üzerinde iyi görünen şey gerçek tabloda bambaşka davranabiliyor.
Kaynaklar ve İleri Okuma
Kısacası mesele yalnızca hız değil… okunabilirlik de önemli.
Hız gelir geçer ama ilişki haritasını kaybederseniz bakım maliyeti kalıcı olur.
Kaynaklar ve İleri Okuma
Kısacası mesele yalnızca hız değil… okunabilirlik de önemli.
Hız gelir geçer ama ilişki haritasını kaybederseniz bakım maliyeti kalıcı olur.
Docker Compose İçin 7 Şablon: Kurulum Kafası Karışmasın!
Laravel API’de Lead Toplama: DTO, Action ve JSON:API!
Ddev’e Aljibe Eklemek Duygularda Sürprizler!
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.
