Firebase Mülakat Soruları 2026: Flutter Auth, Firestore ve Güvenlik Kuralları

Flutter pozisyonları için Firebase mülakat soruları beş konu etrafında toplanır: üç kimlik doğrulama durumu akışı, Firestore veri modelleme, güvenlik kuralları, çevrimdışı yazmalar ve her okumanın arkasındaki maliyet modeli. Firebase 2026'da Flutter uygulamalarının varsayılan backend'i olmayı sürdürüyor ve Ekim 2026'dan bu yana FlutterFire eklentileri BoM 5.x olarak yayımlanıyor (firebase_core 5.1.0, firebase_auth 7.0.1, cloud_firestore 7.1.0). Android'de minSdk 24'e yükseltildi, altta ise Firebase Apple SDK 13 çalışıyor.

Firebase Mülakat Soruları: 2026'da Neler Soruluyor

Mülakatçılar nadiren API ayrıntısı sorar. Adayın, Firebase'in kuralları nerede uyguladığını, her işlemin maliyetini ve ağ kesildiğinde ne olduğunu anlayıp anlamadığını kontrol ederler. Aşağıdaki tablo, tekrar eden konuları güçlü bir cevabın içermesi gerekenlerle eşleştirir. Her biri aşağıdaki Flutter geliştiricileri için Firebase mülakat soruları bölümünde ayrıntılı olarak cevaplanır.

Flutter Projesinde Firebase Kurulumu

Herhangi bir Firebase kodu yazmadan önce projenin doğru şekilde başlatılması gerekir. FlutterFire CLI, platform kaydını otomatikleştirir ve Android, iOS, web ve macOS için yapılandırma dosyalarını oluşturur.

import 'package:firebase_core/firebase_core.dart';
import 'package:flutter/material.dart';
import 'firebase_options.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // Initialize Firebase with platform-specific config
  await Firebase.initializeApp(
    options: DefaultFirebaseOptions.currentPlatform,
  );
  runApp(const MyApp());
}

firebase_options.dart dosyası flutterfire configure komutu çalıştırıldığında otomatik olarak oluşturulur. API anahtarlarını, proje kimliklerini ve platforma özel tanımlayıcıları içerir, bu nedenle Firebase konsolundan elle hiçbir şey kopyalanmaz.

Firebase Kimlik Doğrulama: E-posta, Google ve Çok Faktörlü Doğrulama

Firebase Authentication, minimum şablon koduyla kullanıcı kimliğini yönetir. firebase_auth paketi e-posta/parola, OAuth sağlayıcıları (Google, Apple, GitHub), telefon tabanlı SMS doğrulama ve çok faktörlü kimlik doğrulamayı (MFA) destekler; firebase_auth 6.1.0'dan beri buna macOS'ta TOTP da dahildir.

E-posta ve Parola ile Kayıt

En yaygın akış e-posta/parola ile başlar. createUserWithEmailAndPassword metodu, kimlik doğrulanmış User nesnesini içeren bir UserCredential döndürür.

import 'package:firebase_auth/firebase_auth.dart';

class AuthService {
  final FirebaseAuth _auth = FirebaseAuth.instance;

  // Register with email and password
  Future<User?> register(String email, String password) async {
    try {
      final credential = await _auth.createUserWithEmailAndPassword(
        email: email,
        password: password,
      );
      return credential.user;
    } on FirebaseAuthException catch (e) {
      // Handle specific error codes
      switch (e.code) {
        case 'email-already-in-use':
          throw Exception('This email is already registered');
        case 'weak-password':
          throw Exception('Password must be at least 6 characters');
        default:
          throw Exception('Registration failed: ${e.message}');
      }
    }
  }

  // Sign in with existing credentials
  Future<User?> signIn(String email, String password) async {
    final credential = await _auth.signInWithEmailAndPassword(
      email: email,
      password: password,
    );
    return credential.user;
  }

  // Reactive auth state stream
  Stream<User?> get authStateChanges => _auth.authStateChanges();
}

authStateChanges() akışı, uygulama genelinde oturum durumunu izlemenin önerilen yoludur. Abone olunduğunda mevcut User nesnesini yayar ve her giriş veya çıkış olayında tekrar tetiklenir.

Parola kuralları artık yalnızca istemcide tutulmak zorunda değil: validatePassword API'si (firebase_auth 6.0.0'dan beri mevcut) bir parolayı Firebase konsolunda yapılandırılan politikaya göre kontrol eder. Bu politika minimum uzunluk, büyük harf, küçük harf, rakam ve özel karakter şartı koyabilir.

Google ile Giriş Entegrasyonu

OAuth sağlayıcıları ek bir paket gerektirir. google_sign_in 7.0'dan beri eklenti GoogleSignIn.instance ile alınan bir singleton'dır, tam olarak bir kez başlatılmalıdır ve kimlik doğrulama yetkilendirmeden ayrılmıştır. Eski eğitimlerde görülen GoogleSignIn().signIn() çağrısı artık derlenmez.

import 'package:firebase_auth/firebase_auth.dart';
import 'package:google_sign_in/google_sign_in.dart';

// Call once at startup, before any other GoogleSignIn method
Future<void> initGoogleSignIn() => GoogleSignIn.instance.initialize();

Future<UserCredential> signInWithGoogle() async {
  try {
    // Shows the native account picker; throws if the user cancels
    final googleUser = await GoogleSignIn.instance.authenticate();

    // Synchronous getter since v7: only the ID token is exposed here
    final googleAuth = googleUser.authentication;

    // Firebase only needs the ID token to create the credential
    final credential = GoogleAuthProvider.credential(
      idToken: googleAuth.idToken,
    );
    return FirebaseAuth.instance.signInWithCredential(credential);
  } on GoogleSignInException catch (e) {
    if (e.code == GoogleSignInExceptionCode.canceled) {
      throw Exception('Sign-in cancelled');
    }
    rethrow;
  }
}

Bu kalıp tüm OAuth sağlayıcıları için geçerlidir: sağlayıcı jetonunu elde etmek, Firebase kimlik bilgisi içine sarmak ve ardından signInWithCredential çağırmak. Uygulamanın bir Google API'sini (Drive, Calendar) de çağırması gerekiyorsa erişim jetonu artık ayrı bir adımdan, authorizationClient.authorizeScopes çağrısından gelir; ayrıntılar google_sign_in geçiş kılavuzunda yer alır.

Firestore CRUD İşlemleri ve Veri Modelleme

Cloud Firestore, verileri koleksiyonlar ve belgeler halinde düzenler. SQL veritabanlarının aksine Firestore şemasızdır: her belge farklı alanlar içerebilir. Bu esneklik Flutter uygulamalarına iyi uyar, ancak performans sorunlarından kaçınmak için disiplinli veri modelleme gerektirir.

Belge Yazma ve Okuma

Firestore işlemleri cloud_firestore paketiyle basittir. Her okuma ve yazma işlemi belirli bir belge yolunu hedefler.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskService {
  final _db = FirebaseFirestore.instance;
  final String _collection = 'tasks';

  // Create a new document with auto-generated ID
  Future<String> createTask(String userId, String title) async {
    final doc = await _db.collection(_collection).add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  // Read a single document by ID
  Future<Map<String, dynamic>?> getTask(String taskId) async {
    final snapshot = await _db.collection(_collection).doc(taskId).get();
    return snapshot.data();
  }

  // Update specific fields without overwriting the entire document
  Future<void> toggleComplete(String taskId, bool completed) async {
    await _db.collection(_collection).doc(taskId).update({
      'completed': completed,
      'updatedAt': FieldValue.serverTimestamp(),
    });
  }

  // Delete a document
  Future<void> deleteTask(String taskId) async {
    await _db.collection(_collection).doc(taskId).delete();
  }
}

FieldValue.serverTimestamp(), istemci saati yerine Firestore sunucu saatini kullanarak tüm cihazlarda tutarlı zaman damgaları sağlar. cloud_firestore 7.1.0'dan beri sunucu tarafı dönüşümlere FieldValue.minimum ve FieldValue.maximum da katıldı: okuma yapmadan saklanan ve gelen değerden küçük ya da büyük olanı tutarlar, bu da en iyi skor gibi sayaçlara uyar.

snapshots() ile Gerçek Zamanlı Akışlar

Firestore, gerçek zamanlı senkronizasyon konusunda öne çıkar. snapshots() metodu, temel belgeler değiştiğinde yeni verileri yayan bir Stream döndürür ve yoklama gerektirmez.

import 'package:cloud_firestore/cloud_firestore.dart';

class TaskStream {
  final _db = FirebaseFirestore.instance;

  // Stream all tasks for a specific user, ordered by creation date
  Stream<List<Map<String, dynamic>>> userTasks(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((snapshot) => snapshot.docs.map((doc) {
              final data = doc.data();
              data['id'] = doc.id; // Include document ID
              return data;
            }).toList());
  }
}

Bir Flutter widget'ında bu akış, her veritabanı değişikliğinde arayüzü yeniden oluşturmak için doğrudan StreamBuilder ile entegre olur. Firestore bağlantı yönetimi, önbellekleme ve çevrimdışı kalıcılık işlemlerini otomatik olarak yönetir.

Flutter Uygulamaları için Firestore Güvenlik Kuralları

Güvenlik kuralları Firestore sunucusunda çalışır ve belge düzeyinde okuma/yazma erişimini kontrol eder. Uygun kurallar olmadan, kimlik doğrulanmış herhangi bir kullanıcı herhangi bir belgeyi okuyabilir veya değiştirebilir.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Users can only access their own profile
    match /users/{userId} {
      allow read, update: if request.auth != null
                          && request.auth.uid == userId;
      allow create: if request.auth != null;
      allow delete: if false; // Prevent self-deletion
    }

    // Tasks belong to the user who created them
    match /tasks/{taskId} {
      allow read, write: if request.auth != null
                         && resource.data.userId == request.auth.uid;
      allow create: if request.auth != null
                    && request.resource.data.userId == request.auth.uid;
    }
  }
}

request.auth.uid değişkeni, Firebase Auth'tan kimlik doğrulanmış kullanıcının kimliğini içerir. resource.data'ya referans veren kurallar mevcut belge alanlarını kontrol ederken, request.resource.data gelen yazma verilerini doğrular.

Çevrimdışı Kalıcılık ve Önbellekleme Stratejisi

Firestore, mobil platformlarda varsayılan olarak çevrimdışı kalıcılığı etkinleştirir. Cihaz bağlantı kaybettiğinde, okuma işlemleri önbellekteki verileri döndürür ve yazma işlemleri bağlantı yeniden kurulana kadar yerel olarak kuyruğa alınır.

Bu davranış ek Flutter kodu gerektirmez: aynı get() ve snapshots() çağrıları çevrimdışı çalışır. Ancak üretim uygulamaları için iki husus önemlidir:

• Önbellek boyutu: Firestore, istemcinin okuduğu tüm belgeleri önbelleğe alır. Veri yoğun uygulamalar için Settings(cacheSizeBytes: Settings.CACHE_SIZE_UNLIMITED) yapılandırılabilir veya belirli bir sınır belirlenebilir.
• Bekleyen yazma göstergesi: SnapshotMetadata.hasPendingWrites kullanılarak yerel değişikliklerin henüz sunucuya senkronize edilmediği kullanıcılara gösterilebilir.

StreamBuilder<DocumentSnapshot>(
  stream: FirebaseFirestore.instance
      .collection('tasks')
      .doc(taskId)
      .snapshots(),
  builder: (context, snapshot) {
    if (!snapshot.hasData) return const CircularProgressIndicator();

    final data = snapshot.data!;
    final isPending = data.metadata.hasPendingWrites;

    return Row(
      children: [
        Text(data['title']),
        if (isPending) const Icon(Icons.cloud_upload, size: 16),
      ],
    );
  },
)

Üretim Flutter Firebase Uygulama Mimarisi

Ölçeklenebilir bir mimari, Firebase mantığını kullanıcı arayüzü kodundan ayırır. Repository deseni, test etmeyi ve gelecekteki backend geçişlerini kolaylaştıran temiz bir soyutlama katmanı sağlar.

abstract class TaskRepository {
  Future<String> create(String userId, String title);
  Stream<List<Task>> watchAll(String userId);
  Future<void> update(String id, Map<String, dynamic> fields);
  Future<void> delete(String id);
}

// firebase_task_repository.dart
class FirebaseTaskRepository implements TaskRepository {
  final _db = FirebaseFirestore.instance;

  @override
  Future<String> create(String userId, String title) async {
    final doc = await _db.collection('tasks').add({
      'userId': userId,
      'title': title,
      'completed': false,
      'createdAt': FieldValue.serverTimestamp(),
    });
    return doc.id;
  }

  @override
  Stream<List<Task>> watchAll(String userId) {
    return _db
        .collection('tasks')
        .where('userId', isEqualTo: userId)
        .orderBy('createdAt', descending: true)
        .snapshots()
        .map((s) => s.docs.map(Task.fromFirestore).toList());
  }

  // ... update and delete implementations
}

Bu desenle Riverpod veya BLoC gibi durum yönetimi çözümleri, Firestore hakkında bilgi sahibi olmadan repository arayüzünü tüketir. Birim testleri, önceden tanımlanmış veriler döndüren sahte bir repository'yi ikame edebilir.

FlutterFire 5'e Geçiş: Neler Bozuluyor

Ekim 2026 ana sürümü (BoM 5.0.0, firebase_auth 7.0.0, cloud_firestore 7.0.0, firebase_core 5.0.0), Dart API'lerinden çok derleme gereksinimlerini değiştirir. Bir derlemeyi veya kod incelemesini başarısız kılan noktalar:

• Android minSdk 24: eklentiler Firebase Android BoM 35 üzerine kuruludur. Hâlâ minSdk 21 veya 23 kullanan bir proje derlenmez.
• Apple SDK 13: Firebase Apple SDK, Swift Package Manager ile 13.0.0'a geçer (CocoaPods ile 12.19.0) ve Swift paketleri macOS 11 gerektirir.
• App Check: activate parametrelerinin adları providerWeb, providerAndroid ve providerApple olarak değişir.
• Kullanımdan kaldırmalar: setIndexConfigurationFromJSON, cloud_firestore 7.0.0'da deprecated olarak işaretlenmiştir ve firebase_ml_model_downloader artık yayımlanmıyor.
• 6.x serisinde zaten kaldırılanlar: fetchSignInMethodsForEmail() ve User.updateEmail(). Girişten önce bir e-posta adresinin hangi sağlayıcıyı kullandığını kontrol eden kod yeniden tasarlanmalıdır, çünkü e-posta numaralandırma koruması bu bilgiyi gizler.

Paket bazında tam liste FlutterFire sürüm notlarında ve cloud_firestore değişiklik günlüğünde yer alır.

Flutter Geliştiricileri için Firebase Mülakat Soruları

Mülakatlar sıklıkla hem kavramsal anlayışı hem de Firebase hizmetlerinin pratik uygulamasını test eder. Aşağıdaki sorular 2026 yılında Flutter geliştirici mülakatlarında düzenli olarak ortaya çıkar. Framework tarafını daha kapsamlı Flutter mülakat soruları rehberi ele alır.

authStateChanges() ile idTokenChanges() ve userChanges() arasındaki fark nedir?

authStateChanges() yalnızca giriş ve çıkış olaylarında tetiklenir. idTokenChanges() ayrıca kimlik jetonunun yenilenmesinde (yaklaşık her 60 dakikada) tetiklenir. userChanges() yukarıdakilerin tümünü ve updateDisplayName() gibi profil güncellemelerini yakalar. Çoğu navigasyon koruması için authStateChanges() yeterlidir.

Cihaz çevrimdışıyken bir Firestore yazma işlemi gerçekleştiğinde ne olur?

Yazma işlemi yerel önbellekte ve bekleyen yazmalar kuyruğunda saklanır. snapshots() dinleyicileri güncellenmiş verileri metadata.hasPendingWrites == true ile hemen alır. Bağlantı yeniden kurulduğunda Firestore bekleyen yazmaları otomatik olarak senkronize eder ve sunucuya en son ulaşan yazma kazanır.

Bir sohbet uygulaması için Firestore veri modeli nasıl tasarlanmalıdır?

Yaygın bir yaklaşım: her belgenin meta veri içerdiği (katılımcılar, son mesaj zaman damgası) bir chats koleksiyonu ve her sohbet belgesi altında bir messages alt koleksiyonu. Bu yapı, her konuşmadaki mesajları sayfalandırırken bir kullanıcının sohbet listesinin verimli bir şekilde sorgulanmasına olanak tanır. Liste görünümü için alt koleksiyonu okumaktan kaçınmak için son mesaj üst belgeye denormalize edilmelidir.

FieldValue.serverTimestamp() neden DateTime.now() yerine tercih edilmelidir?

DateTime.now() cihaz saatini kullanır ve bu saat yanlış veya manipüle edilmiş olabilir. FieldValue.serverTimestamp() Firestore sunucu saatini kullanarak tüm istemcilerde tutarlı sıralama garantiler. Bu, mesaj sıralama, etkinlik akışları ve denetim günlükleri gibi özellikler için önemlidir.

Firestore'da bileşik sorgular nasıl işlenir ve dizin gereksinimleri nelerdir?

Firestore, birden fazla alanı where ve orderBy yan tümceleriyle birleştiren sorgular için bileşik dizin gerektirir. Tek alanlı dizinler otomatik olarak oluşturulur, ancak bileşik dizinler firestore.indexes.json dosyasında veya Firebase konsolu aracılığıyla manuel olarak tanımlanmalıdır. Bir sorgu başarısız olduğunda, Firestore eksik dizini oluşturmak için doğrudan bir bağlantı kaydeder.

Batched write yerine ne zaman transaction kullanılmalıdır?

Yazma, aynı işlemde okunan verilere bağlıysa transaction gerekir; örneğin stok yalnızca sıfırın üzerindeyse azaltılacaksa. Okunan bir belge commit'ten önce değişirse SDK callback'i yeniden çalıştırır, bu yüzden callback'in yan etkisi olmamalıdır. Batched write ise hiçbir okuma yapmadan birden fazla yazmayı atomik olarak gerçekleştirir; örneğin bir belge oluşturup başka bir yerdeki sayacı güncellemek. Çevrimdışı davranışları da farklıdır: batch kuyruğa alınır, transaction bağlantı olmadan başarısız olur.

final db = FirebaseFirestore.instance;

// Transaction: read then write, retried on contention
await db.runTransaction((tx) async {
  final ref = db.collection('products').doc(id);
  final snap = await tx.get(ref);
  final stock = snap.get('stock') as int;
  if (stock <= 0) throw Exception('Out of stock');
  tx.update(ref, {'stock': stock - 1});
});

// Batched write: atomic writes, no reads
final batch = db.batch();
batch.set(db.collection('orders').doc(), {'productId': id});
batch.update(db.collection('stats').doc('orders'), {
  'count': FieldValue.increment(1),
});
await batch.commit();

Firebase ile admin rolü nasıl uygulanır?

Flutter istemcisinden değil, güvenilir bir ortamdan Admin SDK ile atanan custom claims ile. Claim ID jetonunun içinde taşınır, böylece kurallar ek bir belge okuması yapmadan onu request.auth.token.admin == true olarak okur. Custom claims dokümantasyonu yükü 1000 baytla sınırlar ve istemci yeni bir claim'i ancak jeton yenilendikten sonra görür; yenilemeyi currentUser.getIdToken(true) zorlar.

Güvenlik kuralları ile App Check arasındaki fark nedir?

Güvenlik kuralları, belirli bir kullanıcının belirli bir belgeyi okuyup yazamayacağına karar verir. App Check ise isteğin gerçek bir cihazdaki orijinal uygulamadan geldiğini doğrular ve herkese açık API anahtarını yeniden kullanan betikleri engeller. Farklı sorulara cevap verdikleri için üretimdeki bir uygulamanın ikisine de ihtiyacı vardır. FlutterFire 5'ten beri App Check providerAndroid, providerApple ve providerWeb ile etkinleştirilir.

Bir Firestore ekranı neden pahalı hale gelebilir ve sayfalama nasıl yapılır?

Firestore her belge okuma, yazma ve silme işlemi için ücret alır. Sınırsız bir koleksiyon üzerindeki dinleyici ilk yüklemede eşleşen her belgeyi okur, ardından değişen her belge için bir okuma yapar. Sayfalama offset yerine sorgu imleçleriyle yapılır: ilk sayfa için limit(20), sonraki için startAfterDocument(lastDoc). Böylece her sayfa yalnızca döndürdüğü belgeler kadar maliyet çıkarır.

Firestore mu Realtime Database mi: hangisi ve neden?

Firestore belgeleri koleksiyonlarda saklar, dizinlerle bileşik sorguları destekler ve işlem başına faturalandırır. Realtime Database tek bir JSON ağacı saklar, tek bir alt anahtar üzerinde sığ sorgular sunar ve ağırlıklı olarak bant genişliği ve depolama üzerinden faturalandırır; bu da çevrimiçi durum göstergeleri gibi küçük ve çok sık güncellemelere uyar. Yeni Flutter uygulamalarının çoğu Firestore ile başlar ve Realtime Database'i yalnızca çevrimiçi durum için ekler.

Flutter ve Firebase mülakat hazırlığı için daha fazla pratik malzemesi, bu konuları interaktif quizler ve süreli alıştırmalarla kapsayan modüllerde mevcuttur.

Kaynaklar

• Flutter için Firebase sürüm notları: BoM 5.0.0 ve 5.1.0 içeriği, minSdk 24, App Check parametrelerinin yeniden adlandırılması
• cloud_firestore değişiklik günlüğü: 6.3.0'da Pipelines, 7.1.0'da FieldValue.minimum/maximum ve findNearest mesafesi
• firebase_auth değişiklik günlüğü: 6.0.0'da validatePassword, 6.1.0'da macOS'ta TOTP, kaldırılan fetchSignInMethodsForEmail
• google_sign_in geçiş kılavuzu: singleton, initialize, authenticate, 7.0'da ayrı yetkilendirme
• Firebase custom claims: 1000 bayt sınırı ve jeton yenileme

Mülakat İçin Flutter Firebase'de Akılda Tutulması Gerekenler

• FlutterFire BoM 5.1.0, firebase_auth 7.0.1 ve cloud_firestore 7.1.0 içerir ve Android'de minSdk 24 gerektirir
• google_sign_in 7, GoogleSignIn().signIn() yerine önce GoogleSignIn.instance.initialize(), ardından authenticate() kullanır; Firebase yalnızca idToken'a ihtiyaç duyar
• authStateChanges(), manuel kontrol gerektirmeden tüm uygulamada oturum durumunu yönetmek için reaktif bir akış sağlar
• snapshots() ile gerçek zamanlı senkronizasyon yoklamayı ortadan kaldırır ve otomatik arayüz güncellemeleri için doğrudan StreamBuilder ile çalışır
• Güvenlik kuralları üretimde zorunludur: request.auth.uid her zaman belge sahipliği alanlarıyla doğrulanmalı, roller için custom claims kullanılmalıdır
• Transaction önce okur sonra yazar ve yeniden dener, batched write yalnızca yazar; her belge okuması faturalandığı için sayfalama imleçlerle yapılır
• Çevrimdışı kalıcılık mobilde ek kod olmadan çalışır; hasPendingWrites senkronizasyon durumunu kullanıcılara göstermeyi sağlar
• Repository deseni Firebase'i iş mantığından ayırır ve testi ve gelecekteki geçişleri kolaylaştırır