Her mobil uygulamanın bir backend’i vardır; soru backend olup olmayacağı değil, kimin kuracağıdır. Kısa cevap: tek ekibin geliştirdiği, iş kuralı az, veri modeli basit bir MVP için Firebase ya da Supabase gibi hazır backend servisi (BaaS) en hızlı yoldur. Birden fazla istemci (mobil + web paneli + üçüncü taraf), sunucuda çalışması zorunlu iş kuralları, ERP ya da e-fatura gibi entegrasyonlar, ilişkisel raporlama ve verinin nerede duracağı konusunda yükümlülük varsa özel backend gerekir. Çoğu kurumsal projede doğru cevap hibrittir: push bildirimi, çökme raporu ve analitik için Firebase, çekirdek veri ve iş kuralı için kendi API’niz. Bu yazı, mobil uygulama projelerinde bu kararı nasıl verdiğimizi anlatır.
Backend mobil uygulamada ne yapar?
Telefondaki uygulama yalnızca arayüzdür; kalıcı olan her şey bir sunucuda yaşar. Backend şu işleri üstlenir:
- Kimlik doğrulama ve oturum: kullanıcı kimdir, hangi cihazdan girmiştir, oturumu ne zaman biter.
- Veri saklama ve sorgulama: siparişler, mesajlar, profiller; iki kullanıcının aynı kaydı aynı anda değiştirmesi dâhil.
- İş kuralı: fiyat hesaplama, stok düşme, onay akışı, limit kontrolü. Bunların istemcide çalışması güvenlik açığıdır.
- Dosya ve medya: fotoğraf yükleme, boyutlandırma, erişim izni.
- Bildirim ve zamanlanmış iş: push, e-posta, gece çalışan raporlar.
- Entegrasyon: ödeme sağlayıcı, kargo, muhasebe, ERP; bu bağlantıların anahtarları mobil pakete konamaz.
Hazır backend servisi bu listenin ilk iki ve dördüncü maddesini çok iyi, üçüncü ve altıncıyı ise ancak ek kodla karşılar. Karar bu farkın üzerine kurulur.
BaaS (Firebase, Supabase) ne verir, ne vermez?
Firebase, Google’ın barındırdığı bir servis paketidir: Authentication, Firestore (belge veritabanı), Storage, Cloud Functions, Cloud Messaging (push), Crashlytics ve Analytics. Supabase benzer paketi PostgreSQL üstüne kurar ve açık kaynaktır. İkisinde de sunucu yönetmezsiniz; mobil uygulama SDK ile veritabanına doğrudan bağlanır, erişim kuralları servis tarafında tanımlanır. Verdiği şey nettir: ilk sürümü haftalar yerine günler içinde çıkarmak, kimlik doğrulama ve gerçek zamanlı senkronu yazmamak, ölçeklemeyi düşünmemek. Vermediği şeyler ise projede sonradan ortaya çıkar: Firestore’da tablo birleştirme (join) ve toplu raporlama yoktur, veri modeli ekranlara göre kurulur ve her yeni ekran veri yapısını zorlar; çok adımlı iş kuralları için yine Cloud Functions yazarsınız; veriyi başka bir sisteme taşımak mümkündür ama belge yapısından ilişkisel yapıya geçiş ayrı bir projedir. Supabase ilişkisel veritabanı sunduğu için ilk sorunu çözer, ama iş kuralı ve entegrasyon sorusu orada da aynıdır.
Kritik fark: iş kuralı nerede çalışır?
BaaS modelinde uygulama veritabanına doğrudan yazar. Bu, en hızlı ve en tehlikeli özelliktir. Bir sipariş uygulamasında toplam tutarı telefon hesaplıyor ve Firestore’a yazıyorsa, uygulamayı açan herkes bu tutarı değiştirip gönderebilir; güvenlik kuralları alan türünü ve sahipliği denetler, ama “toplam, kalemlerin fiyat çarpı adet toplamına eşit mi” gibi bir kuralı okunabilir biçimde yazmak zordur. Çözüm, yazma işlemini bir sunucu fonksiyonuna taşımaktır:
// Cloud Function: toplam istemciden alınmaz, sunucuda hesaplanır
import { onCall, HttpsError } from 'firebase-functions/v2/https';
import { getFirestore } from 'firebase-admin/firestore';
export const createOrder = onCall(async (req) => {
if (!req.auth) throw new HttpsError('unauthenticated', 'Giriş gerekli');
const db = getFirestore();
const items = req.data.items as { productId: string; qty: number }[];
return db.runTransaction(async (tx) => {
let total = 0;
for (const item of items) {
const snap = await tx.get(db.doc('products/' + item.productId));
if (!snap.exists) throw new HttpsError('not-found', 'Ürün yok');
const product = snap.data()!;
if (product.stock < item.qty) {
throw new HttpsError('failed-precondition', 'Stok yetersiz');
}
total += product.price * item.qty; // fiyat telefondan değil, kayıttan
tx.update(snap.ref, { stock: product.stock - item.qty });
}
const ref = db.collection('orders').doc();
tx.set(ref, { userId: req.auth!.uid, items, total, createdAt: new Date() });
return { orderId: ref.id, total };
});
});Bu fonksiyonu yazdığınız anda bir backend yazıyorsunuz demektir; yalnızca sunucuyu Google barındırıyor. İş kuralı sayısı arttıkça fonksiyonlar çoğalır, aralarındaki ortak kod ve test düzeni bir çatıya ihtiyaç duyar ve proje farkında olmadan özel backend’e dönüşür. Bu yüzden karar “Firebase mi, kendi sunucum mu” değil, “iş kurallarımın kaç tanesi sunucuda çalışmak zorunda” sorusuyla başlar. Mobil tarafın güvenlik ilkelerini mobil uygulama güvenliği yazısında, API tasarımını REST mi GraphQL mi yazısında anlattık.
Hazır backend servisi iş kuralını ortadan kaldırmaz, yalnızca nerede yazılacağını değiştirir. Sunucuda çalışması zorunlu kural sayısı bir elin parmaklarını geçtiğinde, servisin kazandırdığı hız geri alınmaya başlar.
Maliyet neyle büyür?
BaaS fiyatlandırması kullanım başınadır: okuma, yazma, depolama ve fonksiyon çalıştırma sayısı. Özel backend’de ise sabit sunucu ve bakım gideri vardır. Rakam vermiyoruz, çünkü iki modelin faturasını farklı şeyler belirler ve bunu bilmek rakamdan daha önemlidir. BaaS faturası kullanıcı sayısıyla değil veri modeliyle büyür: bir liste ekranı her açılışta yüz belge okuyorsa, kullanıcı başına günlük okuma sayısı o ekranın tasarımına bağlıdır ve bu, uygulama yayına çıktıktan sonra düzeltilmesi en pahalı hatadır. Özel backend’in maliyeti ise işlem hacmiyle değil, onu yazıp bakımını yapacak ekibin zamanıyla büyür. Yıllık giderleri mobil uygulama bakım maliyeti yazısında kalem kalem verdik; ilk geliştirme bütçesi için mobil uygulama yaptırma maliyeti yazısına bakın.
Veri sizin mi? Taşınabilirlik ve konum
BaaS kullanan her proje üç soruyu baştan cevaplamalıdır. Birincisi, veri hangi ülkede duruyor: Firebase projelerinde bölge seçilebilir ama kişisel verinin yurt dışına aktarımı KVKK açısından ayrı bir yükümlülüktür; bunu aydınlatma metni ve gerekirse açık rıza ile karşılamanız gerekir (bu yazı hukuki danışmanlık değildir). İkincisi, veri nasıl dışa aktarılır: belge veritabanından ilişkisel bir yapıya geçişi veri göçü yazısında anlattık; göç yapılabilir, ama ekranlara göre kurulmuş bir veri modeli tablolara dönüşürken yeniden tasarlanır. Üçüncüsü, servis bir özelliği kapatırsa ne olur: Firebase Dynamic Links kapatıldı ve ona bağlı uygulamalar bağlantı altyapısını yeniden kurdu. Bu, servisin kötü olduğunu değil, bir ürün kararının sizin ürününüzü etkileyebildiğini gösterir. Kritik akışları tek sağlayıcıya bağlamadan önce çıkış maliyetini yazılı hâle getirin.
Karar testi: üç soru
Aşağıdaki üç sorudan en az ikisine “evet” diyorsanız çekirdek veriyi özel backend’e alın:
- Uygulamanın verisini mobil dışında başka istemciler de kullanacak mı: web yönetim paneli, bayi portalı, üçüncü taraf API, muhasebe ya da ERP entegrasyonu?
- Sunucuda çalışması zorunlu iş kuralları var mı: fiyat ve indirim hesabı, stok rezervasyonu, onay akışı, limit kontrolü, sıralı işlem?
- İlişkisel raporlama gerekiyor mu: tarih aralığına göre ciro, kullanıcı başına ortalama, birden çok tabloyu birleştiren yönetim raporları?
Dördüncü soru her iki yolda da sorulur: veriyi bugün tek komutla dışa aktarabiliyor musunuz? Cevap hayırsa seçtiğiniz model ne olursa olsun önce bunu çözün. İkiden az “evet” varsa, özellikle ilk sürümü hızla pazara çıkarıp talebi ölçmek istiyorsanız, BaaS doğru başlangıçtır; MVP kapsamını MVP nedir yazısında anlattık. Veritabanı seçimi gerekiyorsa PostgreSQL mi MySQL mi yazısı yardımcı olur.
Hibrit model: ikisini birlikte kullanmak
Pratikte en yaygın kurulum şudur: push bildirimi için Firebase Cloud Messaging, çökme raporu için Crashlytics, kullanım analitiği için Analytics; kimlik, çekirdek veri ve iş kuralı için kendi API’niz. Bu modelde mobil uygulama Firestore’a hiç bağlanmaz; Firebase yalnızca cihaz tarafındaki yardımcı servisleri sağlar. Push kurulumunu push bildirim yazısında, bağlantı koptuğunda çalışmaya devam eden tasarımı çevrimdışı çalışan uygulama yazısında anlattık. Hibrit modelin tek şartı sınırın net olmasıdır: hangi verinin sahibi Firebase, hangisinin API, baştan yazılı olmalıdır; aksi hâlde aynı bilgi iki yerde tutulur ve hangisinin doğru olduğu bilinmez.
Sonuç
Firebase ve benzeri servisler mobil uygulamanın ilk sürümünü hızlandıran gerçek araçlardır; sorun araçta değil, kararın verilmemesinde çıkar. İş kuralı sunucuya taşınmak zorunda kaldığında, ikinci istemci geldiğinde ya da ilk yönetim raporu istendiğinde proje zaten özel backend’e dönüşmüştür ve bunu planlı yapmak plansız yapmaktan ucuzdur. Uygulamanızın hangi verisinin nerede durması gerektiğini birlikte çıkarmak için teklif formundan yazın; ilk görüşmede yukarıdaki üç soruyu birlikte cevaplayalım.