niranar.com Entegrasyonları: Harita, Takvim ve Ödeme

Bir platform inşa etmenin görünmez maliyetleri arasında belki de en az tartışılanı şudur: her entegrasyon bir bağımlılık yaratır. Bir ödeme servisi bağladığınızda yalnızca kart işleme kapasitesi kazanmıyorsunuz — API değişikliklerinden etkileniyorsunuz, kesinti riskini paylaşıyorsunuz, faturalandırma değişikliklerine maruz kalıyorsunuz. Bir harita servisi eklediğinizde bağımsız bir kullanıcı deneyimi öğesi kazanmıyorsunuz — o servisin fiyatlandırma kararlarına, istek limitlerinden hesap durumuna kadar her şeye bağımlı hale geliyorsunuz.

niranar.com, Türkiye'nin Akdeniz bölgesini kapsayan 300.000'i aşkın ilanı olan bir tatil kiralama platformudur. Bu yazı, platformun üçüncü parti entegrasyon kararlarını inceliyor: neyi entegre etti, neyi bilinçli olarak dışarıda bıraktı ve bu kararlar platformun genel mimarisini nasıl şekillendirdi. Kararların tamamını teknik mimari açısından değerlendirmek için, bu serinin önceki yazısı olan niranar.com Teknik Mimarisi iyi bir başlangıç noktası sunar.

Entegrasyon Kararları Mimari Kararlardır

Bir geliştirici belirli bir kütüphane veya servisi seçtiğinde bu yalnızca teknik bir tercih değildir. Aynı zamanda şu sorulara verilen bir yanıttır: Hangi sorumlulukları kendi sistemimizde tutuyoruz? Hangi sorunları dışarıya devrediyoruz? Devrettiğimiz sorunlar için hangi bağımlılıkları kabul etmeye hazırız?

Bu soruların yanlış yanıtlanması, özellikle tek geliştirici sistemlerde, uzun vadeli bakım yükünü katlar. Doğru yanıtlanması ise sınırlı kapasiteyle maksimum ürün kalitesi üretebilmenin temelini oluşturur.

niranar.com'un entegrasyon haritası üç farklı kategoriyi içeriyor: aktif olarak entegre edilen sistemler, kasıtlı olarak ertelenenler ve hiç dahil edilmeyenler. Her kategori bir karar sonucu.

Harita Entegrasyonu: Leaflet Seçimi

niranar.com'da harita işlevselliği Leaflet ile sağlanıyor. Leaflet, açık kaynaklı bir JavaScript harita kütüphanesidir. API anahtarı gerektirmiyor, istek başına ücret ödenmesi gerekmiyor ve herhangi bir platformla bağlantıya gerek kalmaksızın kullanılabiliyor.

Bu tercihin alternatifi açık: Google Maps Platform. Google'ın harita servisi, daha zengin özellik seti ve daha kapsamlı yer verileriyle pek çok geliştiricinin ilk tercihi. Ancak Google Maps Platform'un fiyatlandırma yapısı, gelir öncesi aşamada olan bir platform için ciddi bir baskı unsuru oluşturuyor.

Google Maps'in dinamik harita yüklemeleri belirli bir ücretsiz kullanım kotasına sahip ve bu kota aşıldığında her 1.000 istek için maliyet başlıyor. 300.000 ilan barındıran, listeler arası gezinmenin yoğun map etkileşimini tetikleyeceği bir platformda bu eşiğin hızla aşılacağını öngörmek güç değil. Üstelik platform henüz gelir üretmiyor. Kullanıcılar ilanları görüntülüyor, haritada geziniyor, bölgeler arasında geçiş yapıyor — tüm bu etkileşimler istek sayısını artırıyor ve gelir eşiğine ulaşılmadan önce birikerek ciddi bir maliyet kalemini oluşturabiliyor.

Leaflet bu denklemin tamamen dışına çıkıyor. Harita yükleme sayısına bakılmaksızın sıfır maliyet. Herhangi bir istek limiti yok. Kütüphane doğrudan projeye dahil ediliyor ve operasyonun devamı için harici bir servise bağımlılık yok. Tile sunucu seçimi esnekliği de var: açık kaynak tile sağlayıcıları ile çalışmak veya kendi tile altyapısını oluşturmak mümkün.

Bu tercih bir uzlaşma değil. Leaflet, tatil kiralama platformlarının haritadan beklediği temel özellikleri karşılıyor: mülklerin coğrafi konumunu görselleştirme, kullanıcının bölge içinde gezinmesine izin verme, liste görünümüyle senkronize çalışma, marker tabanlı mülk gösterimi. Antalya'dan Fethiye'ye, Bodrum'dan Kuşadası'na Türkiye'nin Akdeniz kıyısındaki mülkleri haritada konumlandırmak için Google'ın ek özelliklerine ihtiyaç yok. Haritanın işi coğrafi bağlamı görselleştirmek ve "bu mülk tam olarak nerede?" sorusunu yanıtlamak — Leaflet bunu eksiksiz yapıyor.

Tek Geliştirici Bağlamında Maliyet Mühendisliği

Bu kararı daha geniş bir perspektiften değerlendirmek gerekiyor. Büyük bir geliştirme ekibine ve yatırım finansmanına sahip bir şirket için Google Maps faturası yönetilebilir bir operasyonel gider. Ancak tek geliştirici, öz sermayeli, gelir öncesi bir platform için bu tür bağımlılıklar farklı anlam taşıyor.

Her API faturası, sistemin kârlılığa ulaşmadan önce taşıması gereken operasyonel bir yük. Leaflet gibi açık kaynaklı alternatiflerin yeterliliği sağladığı durumlarda bu yükü sıfıra indirmek, başka kararlar için alan açıyor. Haritanın her kullanımında para ödemek yerine geliştirici zamanı ve dikkatinin asıl ürün sorunlarına yönlendirilmesi mümkün oluyor.

Takvim ve Müsaitlik Yönetimi: Kendi Sistemini Kurmak

niranar.com'un takvim ve müsaitlik sistemi üçüncü parti bir takvim servisiyle değil, kendi geliştirilen bir implementasyonla çalışıyor.

Bu tercih yüzeysel olarak şaşırtıcı görünebilir. Piyasada tatil kiralama platformları için tasarlanmış takvim API'leri mevcut. Bu servisleri entegre etmek, sıfırdan bir uygulama geliştirmeye kıyasla daha az başlangıç çalışması gerektirebilir. Bazı platformlar iCal entegrasyonu, doluluğu senkronize eden iş mantığı ve birden fazla kaynaktan rezervasyonları birleştiren çözümler sunuyor.

Ancak takvim, niranar.com için sıradan bir yardımcı özellik değil. Müsaitlik bilgisi, arama işlevinin çekirdeğinde yer alıyor. Tarih bazlı filtreleme, platforma giren her kullanıcı için temel bir arama boyutu. Bir kullanıcı Bodrum'da Ağustos ayı için villa arıyor — tarih filtresi bu aramanın en doğal ve kaçınılmaz boyutu. Bu bağlamda takvim mantığını dışarıya devretmek şu demek: platformun en kritik veri noktalarından birini başka bir servisin güvenilirliğine ve API sözleşmesine bağlamak.

Bağımlılık Yüzeyini Küçültmek

Bir özellik ne kadar merkezi konumdaysa, o özelliğin dış bağımlılığı o kadar riskli. Bir takvim servisi API değişikliği yaptığında, kesinti yaşadığında veya fiyatlandırmasını artırdığında arama deneyiminin kalbi sekteye uğruyor.

Özelleştirilmiş bir implementasyon bu risk profilini değiştiriyor. Takvim mantığı platform içinde yaşıyor; harici kesintilerden izole. API sözleşme değişikliği riski yok. Müsaitlik veri modeli, platformun kendi gereksinimleri etrafında serbestçe şekillenebiliyor.

Evet, bu kendi geliştirilen bir sistemin bakımını gerektiriyor. Ancak tek bir bakım yükü, bir harici bağımlılığın belirsiz operasyonel risklerinden genellikle daha öngörülebilir.

Supabase: Tek Entegrasyon, Üç Kapasite

niranar.com'da backend altyapısı Supabase üzerine kurulu. Supabase bir Backend as a Service (BaaS) platformu olup PostgreSQL veritabanı, API katmanı ve serverless fonksiyonları tek bir servis altında sunuyor.

Entegrasyon açısından bu tercihin önemi büyük. Ayrı ayrı yönetilecek servisler şöyle düşünülebilirdi: veritabanı için bağımsız bir PostgreSQL instance, API katmanı için ayrı bir çözüm, serverless hesaplama için farklı bir platform. Bu üç problemi ayrı kaynaklara devretmek üç bağımlılık, üç ayrı API sözleşmesi, üç ayrı faturalandırma ilişkisi ve üç ayrı operasyonel izleme noktası anlamına geliyor.

Supabase bu üçünü tek bir entegrasyona indirgiyor. Bu konsolidasyon sadece başlangıç kurulum kolaylığını değil, uzun vadeli operasyonel yükü de etkiliyor.

API Katmanı Olarak Supabase

Supabase'in sağladığı otomatik API katmanı, ayrı bir API sunucu katmanı geliştirme ihtiyacını ortadan kaldırıyor. Veritabanı şeması tanımlandığında, Supabase bu tablolara karşılık gelen REST ve GraphQL endpoint'lerini otomatik olarak oluşturuyor. Ayrı bir Express ya da Fastify sunucusu kurma, koruma, versiyonlama gerekliliği yok.

Bu mimarinin pratik sonucu şu: geliştiricinin zamanını API altyapısı yönetimine değil, ürün özelliklerine harcaması mümkün. 300.000'i aşkın ilan için sorgu optimizasyonu, filtre mantığı ve müsaitlik hesaplamaları Supabase'in PostgreSQL katmanında yürütülüyor. Konum bazlı arama, tarih filtresi, misafir kapasitesi eşleşmesi — bunların tamamı Supabase üzerinden çalışıyor ve ayrı bir query katmanı gerektirmiyor.

Supabase aynı zamanda serverless fonksiyon kapasitesi de sunuyor. Platform gelişip ek iş mantığı gerektirdikçe bu kapasite devreye girebilir — yeni bir servis eklemek olmaksızın, mevcut entegrasyon içinde.

Henüz Kullanılmayan Kapasite: Supabase Auth

Supabase'in kimlik doğrulama modülü niranar.com'da şu an aktif değil. Bu, özelliğin mevcut olmadığı anlamına gelmiyor — Supabase Auth sistemin içinde, kullanıma hazır.

Bu ayrım önemli. Supabase platformuna dahil olan auth modülü, ihtiyaç duyulduğunda etkinleştirilebilir bir kapasite. Email/şifre kimlik doğrulama, sosyal login, magic link — bunların hepsi Supabase Auth kapsamında. Yeni bir servis entegre etmek, yeni bir bağımlılık eklemek veya yeni bir API sözleşmesi öğrenmek gerekmiyor. Auth ihtiyacı doğduğunda yapılacak iş yeni bir entegrasyon değil, mevcut sistemin bir modülünü devreye almak.

Bilinçli Ertelemeler: Ödeme ve Kimlik Doğrulama

niranar.com beta aşamasında iki büyük entegrasyon kategorisini bilinçli olarak dışarıda bırakmış. Bu "yokluklar" aslında en ilgi çekici entegrasyon kararları — neyin entegre edilmediğini ve neden o kararın verildiğini anlamak, platformun önceliklendirme mantığını en net biçimde ortaya koyuyor.

Ödeme Entegrasyonu Yok — Beta Kapsamı Dışında

niranar.com'da şu an herhangi bir ödeme altyapısı bulunmuyor. Kredi kartı işleme, banka transferi yönetimi, kur dönüşümü, para iadesi yönetimi — bunların hiçbiri mevcut sistemde yer almıyor.

Bu bir eksiklik değil, kasıtlı bir kapsam kararı.

Ödeme entegrasyonu teknik karmaşıklığın ötesinde güvenlik ve uyum gereksinimleri taşıyor. PCI DSS standartlarına uygunluk, dolandırıcılık yönetimi, farklı para birimleri arasında işlem yönetimi, yasal sözleşme gereksinimleri, iade politikaları ve anlaşmazlık çözümü... Bunların tamamı, temel ürün deneyimi (keşif) henüz validasyona açılmadan önce üstlenilmesi güç bir sorumluluk kümesi.

Platform keşif deneyimini doğrulamadan önce bu sorumlulukları üstlenmek, karmaşıklığı doğrulanmamış bir çekirdek üzerine inşa etmek anlamına gelirdi. Ödeme sistemi hazır ama tatilciler platforma gelip aramıyorsa, yüksek operasyonel yük taşıyan bir ödeme altyapısı boşta durmuş olur.

Önce 300.000 ilan katalogunu oluştur, keşif deneyiminin gerçekten çalıştığını doğrula, ardından ödeme akışını ekle. Bu sıralama, keşfin işe yarayıp yaramadığı bilinmeden önce yüksek karmaşıklığa taahhüt etmekten kaçınıyor. Nisan 2026 lansmanıyla birlikte ödeme ve rezervasyon akışları devreye girecek — o zamana kadar platform keşif deneyimine odaklanıyor.

Kullanıcı Kimlik Doğrulama Yok — Beta Kapsamı Dışında

Benzer mantıkla, kullanıcı hesapları ve kimlik doğrulama sistemi beta kapsamında yer almıyor. Misafirler oturum açmadan arama yapabiliyor, ilanları görüntüleyebiliyor, harita üzerinde gezinebiliyor.

Bu yokluğun iki pratikal etkisi var. Birincisi, kayıt/giriş akışı tasarımı ve geliştirmesi, bu akışı gerektiren bir rezervasyon sistemi hazır olana kadar erteleniyor. İkincisi, kullanıcının karşısındaki sürtünme noktaları azalıyor: arama yapmak için hesap oluşturma, doğrulama e-postası bekleme veya parola belirleme gerekmiyor.

Bir keşif deneyimini test etmek için kullanıcı kimliği doğrulaması çoğu zaman gereksiz karmaşıklık ekler. İnsanlar mülklere bakabiliyorsa platforma değer sağlıyor — henüz rezervasyon tamamlayamasalar bile.

Supabase'in auth modülü — tüm özellik seti, kullanıcı yönetimi, oturum yönetimi dahil — ihtiyaç duyulduğunda etkinleştirilebilir. Yeni bir servis eklemek değil, var olan bir kapasitenin anahtarını çevirmek.

Entegrasyon Felsefesi: Bağımlılık Yüzeyini Minimize Etmek

niranar.com'un entegrasyon kararları tutarlı bir felsefeyi yansıtıyor: bağımlılık yüzeyini mümkün olduğunca küçük tut, ancak temel gereksinimleri karşılamaktan vazgeçme.

Bu felsefenin pratik çıktıları şöyle sıralanabilir:

Leaflet'in seçilmesi Google Maps bağımlılığını ve değişken API maliyetini ortadan kaldırıyor. Takvim mantığının kendi sistemde tutulması platformun en kritik özelliğini dışarıya devretmekten kaçınıyor. Supabase'in konsolidasyonu üç ayrı bağımlılığı tek bir entegrasyona indirgiyor. Ödeme ve kimlik doğrulamanın ertelenmesi, geliştirme bant genişliğini bu sistemleri gerçekten ihtiyaç duyulacağı zamana kadar koruyor.

Tek Geliştirici Sistemleri İçin Özel Önemi

Bu felsefeye herhangi bir ölçekte katılmak mümkün. Ancak tek geliştirici sistemleri için bu değerlendirme özellikle keskin.

Her harici bağımlılık gürültü üretiyor: API güncellemeleri takip edilmeli, yeni versiyonlara adaptasyon yapılmalı, beklenmedik kesintilerde aksiyon alınmalı, fatura süprizlerine karşı hazırlıklı olunmalı. Bu gürültünün bir ekipte beş kişiye dağıtılması ile tek bir kişi tarafından yönetilmesi arasında köklü bir fark var.

Bağımlılık yüzeyini küçük tutmak, bu gürültü düzeyini kontrol altında tutar. Supabase tek bir entegrasyon noktası. Leaflet harici bir API sözleşmesi olmaksızın çalışıyor. Kendi geliştirilen takvim sistemi yalnızca kendi koduna bağımlı. Bu yapı, tek geliştiriciyle sürdürülebilir bir platform için kritik.

Bu Kararlar Ne Gösteriyor?

niranar.com'un entegrasyon haritası üçüncü parti bağımlılıklara karşı temkinli ama bilinçli bir yaklaşımı yansıtıyor. Her karar şu soruya yanıt veriyor: Hangi sorunları kendi sistemimizde tutmak zorundayız, hangilerini güvenle dışarıya devredebiliriz?

Leaflet'in seçilmesi harita işlevselliğinin araçsallaştırıldığını gösteriyor — amaç özellik seti zenginliği değil, sıfır maliyetle yeterli coğrafi görselleştirme. Takvim mantığının içeride tutulması, platformun en kritik veri özelliğinin harici güvenilirliğe bırakılmadığını gösteriyor. Supabase konsolidasyonu, karmaşıklık yönetimini üç bağımlılık yerine birine indirgeyerek bakım yükünü optimize ediyor. Ödeme ve auth'un ertelenmesi, kompleksite taahhüdünün ihtiyaç doğrulamasından önce gelmediğini gösteriyor.

Bir platform için entegrasyon stratejisi çoğu zaman bu netlikte belgelenmez. Seçimler genellikle anlık kararların birikimi olarak şekillenir ve ilerleyen dönemlerde hangi bağımlılıkların hangi sonuçları doğurduğu izlenemez hale gelir. niranar.com'un yaklaşımı bu örüntünün dışına çıkıyor: entegrasyon kararları ölçülü, bilinçli ve tek geliştirici bağlamına uygun.

Bu vaka çalışması serisinin devam yazıları niranar.com'un SEO mimarisini ve beta stratejisini ayrıntılı biçimde ele alıyor. Entegrasyonların platform genelindeki mühendislik tercihlerine nasıl uyduğunu daha geniş çerçevede değerlendirmek için bkz. niranar.com Teknik Mimarisi.