Firebase uygulama geliştirmede modül seçimi
Bir React Native uygulamasına Firebase yalnızca hata izleme için eklenebilir; başka bir üründe kullanıcı girişi ve veri de kapsamda olabilir. Aynı platformu kullanmak bütün projelerin aynı backend’e ihtiyacı olduğu anlamına gelmez. Önce mevcut uygulamanın hangi görevde zorlandığı anlaşılır.
Örneğin saha ekibinin görev listesini gördüğü ürünün mevcut bir API’si varsa bu API’yi taşımadan bildirim eklemek mümkün olabilir. Yeni bir ekip ürünü için kayıt, dosya ve yetki beraber tasarlanır. Bu örnekler teklif kapsamını açıklayan senaryolardır; müşterilere ait sonuç veya referans iddiası değildir.
Modül haritasında hangi verinin mevcut sistemde kaldığı, hangi işlemin Firebase tarafından desteklendiği ve hangi ekibin bakımını yaptığı yer alır. Kimlik, veri, dosya, fonksiyon ve izleme ayrı karar başlıklarıdır. İlk sürüme yalnızca kullanıcının gerçek yolculuğu için gereken parçalar alınabilir.
Firestore veri modeli ve sorgu ihtiyaçları
Firebase ile Supabase geliştirme arasında seçim yapılırken veri kullanım biçimi önemlidir. Firestore’da uygulamanın okuyacağı kayıtlar, filtreler ve güncelleme örüntüsü model kararını etkiler. Karmaşık rapor ihtiyacı olan bir ürünü yalnızca başlangıç demo kolaylığına bakarak tasarlamak sonradan ek iş yaratabilir.
Kayıtlar kullanıcı görevleriyle birlikte ele alınır: liste hangi alanları gösterir, detay açılınca ne okunur, geçmiş hangi aralıkta getirilir? Bütün kayıtları her ekran açılışında okumak yerine sınırlandırılmış liste ve uygun sorgu yaklaşımı belirlenir. Veri tekrarını önlemek her zaman tek amaç değildir; güncellenecek kopyaların sahipliği de açık olmalıdır.
İşletme kayıtlarının silinmesi ve kullanıcı hesabının kapanması ayrı kararlardır. Sipariş veya operasyon geçmişini profil silinince rastgele kaybetmek doğru bir kabul değildir. Saklama politikası, dosyalar ve raporlama ihtiyacı ürünün veri modeline yansıtılır.
OKUMADAN SONRAKİ ADIMA
Firebase’i hangi görevi tamamlamak için kullanacağınızı belirleyelim
Mevcut uygulamanızı, cihazları ve veri/bildirim ihtiyacınızı paylaşın. Gerekli modüller ile yayın sonrası sorumlulukları netleştirelim.
Offline kullanım ve senkronizasyon davranışı
Bir Flutter uygulamasında bağlantı kesildiğinde ekranın ne göstermesi gerektiği açıkça tasarlanmalıdır. Önbellekte bulunan veri ile sunucunun doğruladığı güncel veri aynı şey değildir. Kullanıcıya eski bilgiye baktığını veya değişikliğin gönderilmeyi beklediğini anlatan durumlar gerekir.
Firestore belirli platformlarda offline veri kullanımını destekler; bu, tüm uygulamanın internetsiz çalışacağı anlamına gelmez. Dış API, ödeme, yeni dosya yükleme veya sunucu kararı gerektiren işlemler ayrıca incelenir. Aynı belgeyi birden fazla cihaz değiştiriyorsa standart senkronizasyon davranışı işletmenin kuralını karşılamayabilir.
Örnek olarak bağlantısız saha notu kaydetmek ile son stoktan ürün ayırmak farklıdır. İlk işlem sonradan gönderilebilir; ikincisi güncel merkezi doğrulama gerektirebilir. Kabul senaryoları bağlantı kesilmesi, tekrar bağlanma, ikinci cihaz ve oturum değişimini kapsar.
| Durum | Kullanıcıya gösterilecek davranış |
|---|---|
| Önbellekten okuma | Verinin güncellik sınırını anlaşılır gösterme |
| Bekleyen değişiklik | Gönderim durumu ve tekrar deneme yolu |
| Aynı kayda iki değişiklik | Çakışma kuralı ve geçerli sonuç |
| Sunucu gerektiren işlem | Bağlantı gereksinimini açıklama ve güvenli durdurma |
FCM push bildiriminin ürün akışına bağlanması
Bir Android uygulamasında push bildirimin gönderilmesi ve kullanıcının ilgili görevi tamamlaması ayrı aşamalardır. Bildirim izni, cihaz kaydı, hedef ekran ve oturum durumu birlikte düşünülür. Aynı kullanıcı birden fazla cihaz kullanabilir; eski cihaz kaydı da zamanla geçersiz hale gelebilir.
Mesajın kilit ekranında görünebileceği hesaba katılır. Hassas bir işin ayrıntısını bildirim metnine koymak yerine uygulamada yetkili kullanıcıya göstermek uygun olabilir. İşlemsel mesaj ve pazarlama mesajı farklı tercih ve sıklık ihtiyacı taşır. Bildirim her cihazda anında veya kesin teslim edilir diye vaat edilmez.
İzin ve tercih
Kullanıcıya neden bildirim istendiği açıklanır. Reddederse temel görevin tamamlanma yolu mümkün olduğunca korunur.
Hedef ve kayıt
Kullanıcı, cihaz ve ilgili kayıt eşleştirilir. Geçersiz cihaz kayıtları ve yinelenen mesajlar için davranış belirlenir.
Tıklama sonrası
Uygulama kapalı, açık veya oturum sona ermişken doğru ekrana geçiş kontrol edilir. Bildirim metni erişim kontrolünün yerini tutmaz.
Security Rules ve güvenilir sunucu işlemleri
Firebase bir özel backend ile birlikte kullanılabilir; erişim sorumluluğu iki sistem arasında kaybolmamalıdır. Authentication kullanıcının kimliğini doğrulamaya yardım ederken veri ve dosya kuralları hangi işlemin yapılabileceğini belirler. Üretimde herkese açık demo izinleri bırakılmaz.
Kendi kaydına erişim, başka müşterinin kaydına erişimin reddi ve beklenmeyen alan gönderimi ayrı kontrol edilir. Kritik bir sonuç istemcinin iddiasına göre kesinleşmez. Ödeme, rol atama veya ticari onay gibi işlemler güvenilir sunucu sınırında değerlendirilir; kim hangi alanın sahibi açık yazılır.
İzleme olayları da veri taşır. Hata raporuna parola, belge içeriği veya kişisel ayrıntı eklenmemelidir. İşletmenin veri politikası doğrultusunda log alanları ve analitik olayları seçilir. Platform özellikleri güvenlik incelemesi veya yasal değerlendirme ihtiyacını otomatik ortadan kaldırmaz.
Firebase maliyeti, izleme ve bakım teslimi
Uygulamanın bakım ve destek planı Firebase yapılandırmasını da kapsamalıdır. Hata izleme ekranını açmak çözüm sürecini tek başına oluşturmaz. Hangi hatanın öncelikli olduğu, kimin inceleyeceği ve düzeltmenin hangi sürümle yayımlanacağı belirlenir.
Ürün bazında güncel plan, kota ve kullanım koşulları kontrol edilir. Okuma, yazma, dosya trafiği ve sunucu işlemleri farklı maliyet etkileri taşıyabilir. Bütçe alarmı ile otomatik harcama sınırı aynı değildir; alarm geldiğinde sorumlu kişinin yapacağı işlem açık olmalıdır. Kullanıcı sayısı tek başına işletim maliyetini açıklamaz.
Teslimde hesap sahipliği, ortam ayrımı, veri modeli, erişim kuralları, bildirim örnekleri ve izleme rehberi görünür hale getirilir. Başlangıç görüşmesi için mevcut uygulama, hedef cihazlar ve tamamlanması gereken görevi paylaşın. Her şeyi Firebase’e taşımak yerine gerekçeli bir entegrasyon ya da geliştirme planı oluşturulur.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Mevcut uygulamaya yalnızca Firebase bildirim eklenebilir mi?
İncelemeyle kapsamlandırılabilir. Mevcut backend’i değiştirmek zorunlu değildir. Cihaz kayıtları, izinler, hedef ekran ve oturum davranışı bağlantının parçası olarak planlanmalıdır.
Firebase kullanınca uygulama tamamen offline çalışır mı?
Hayır. Kullanılan hizmet, platform ve görev belirleyicidir. Önbellekte veri okumak ile ödeme veya merkezi stok doğrulaması aynı değildir. Offline görevler ve bağlantı isteyen adımlar ayrı açıklanmalıdır.
Firebase uygulaması ücretsiz olur mu?
Ürünlerin güncel plan ve kotaları kontrol edilir. Kullanım ve seçilen hizmetler ücret doğurabilir. Bildirim, veri ve dosya ihtiyaçlarını birlikte değerlendirmeden sabit işletim maliyeti verilemez.
Push bildirimi kesin teslim edilir mi?
Kesin ve anlık teslim vaat edilmez. Cihaz izinleri, bağlantı, platform ve geçersiz kayıtlar sonucu etkileyebilir. Kritik operasyonlar yalnızca bildirimin ulaştığı varsayımına dayanarak tasarlanmamalıdır.
Firebase Security Rules neden gereklidir?
Kullanıcı ve veri işlemlerinin erişim kurallarını tanımlar. Oturum açmış olmak her kayda erişim hakkı değildir. İzin verilen ve reddedilen örnekler test edilerek üretim davranışı kontrol edilir.
Firebase Studio ile bu hizmet aynı mı?
Hayır. Bu kapsam temel Firebase hizmetlerinin uygulamaya entegrasyonu ve geliştirmesidir. Geliştirme ortamı Firebase Studio ayrı üründür; kullanılıyorsa güncel geçiş koşulları ayrıca incelenir.
KAPSAMI BİRLİKTE BELİRLEYELİM
Firebase’i hangi görevi tamamlamak için kullanacağınızı belirleyelim
Mevcut uygulamanızı, cihazları ve veri/bildirim ihtiyacınızı paylaşın. Gerekli modüller ile yayın sonrası sorumlulukları netleştirelim.
Firebase kapsamını görüş