Pertanyaan Wawancara Firebase 2026: Auth Flutter, Firestore, dan Aturan Keamanan

Pertanyaan wawancara Firebase untuk posisi Flutter berkisar pada lima topik: tiga stream status autentikasi, pemodelan data Firestore, aturan keamanan, penulisan offline, dan model biaya di balik setiap pembacaan. Firebase tetap menjadi backend default untuk aplikasi Flutter pada 2026, dan sejak Oktober 2026 plugin FlutterFire dirilis sebagai BoM 5.x (firebase_core 5.1.0, firebase_auth 7.0.1, cloud_firestore 7.1.0), dengan minSdk Android yang naik ke 24 dan Firebase Apple SDK 13 di bawahnya.

Pertanyaan Wawancara Firebase: Apa yang Ditanyakan pada 2026

Pewawancara jarang menanyakan hafalan API. Mereka memeriksa apakah kandidat memahami di mana Firebase menegakkan aturan, berapa biaya setiap operasi, dan apa yang terjadi ketika jaringan terputus. Tabel berikut memetakan topik yang sering muncul beserta isi jawaban yang kuat. Setiap topik dijawab secara rinci di bagian pertanyaan wawancara Firebase untuk developer Flutter di bawah.

Menyiapkan Firebase di Proyek Flutter

Sebelum menulis kode Firebase apa pun, proyek memerlukan inisialisasi yang benar. FlutterFire CLI mengotomatiskan registrasi platform dan menghasilkan file konfigurasi untuk Android, iOS, web, dan macOS.

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());
}

File firebase_options.dart dibuat otomatis dengan menjalankan flutterfire configure. File ini berisi kunci API, ID proyek, dan pengenal khusus platform, sehingga tidak ada yang perlu disalin manual dari Firebase console.

Firebase Authentication: Email, Google, dan Multi-Faktor

Firebase Authentication menangani identitas pengguna dengan boilerplate minimal. Paket firebase_auth mendukung email/kata sandi, penyedia OAuth (Google, Apple, GitHub), verifikasi SMS berbasis telepon, dan autentikasi multi-faktor, termasuk TOTP di macOS sejak firebase_auth 6.1.0.

Registrasi Email dan Kata Sandi

Alur paling umum dimulai dengan email/kata sandi. Metode createUserWithEmailAndPassword mengembalikan UserCredential yang berisi objek User yang terautentikasi.

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();
}

Stream authStateChanges() adalah cara yang direkomendasikan untuk melacak status login di seluruh aplikasi. Stream ini memancarkan User saat ini saat berlangganan dan dipicu lagi pada setiap peristiwa masuk atau keluar.

Aturan kata sandi tidak lagi harus berada hanya di klien: API validatePassword (tersedia sejak firebase_auth 6.0.0) memeriksa kata sandi terhadap kebijakan yang dikonfigurasi di Firebase console, yang dapat mewajibkan panjang minimum, huruf besar, huruf kecil, angka, dan karakter khusus.

Integrasi Google Sign-In

Penyedia OAuth memerlukan paket tambahan. Sejak google_sign_in 7.0, plugin ini berupa singleton yang diperoleh melalui GoogleSignIn.instance, harus diinisialisasi tepat satu kali, dan autentikasi dipisahkan dari otorisasi. Panggilan GoogleSignIn().signIn() yang ada di tutorial lama tidak lagi bisa dikompilasi.

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;
  }
}

Pola ini berlaku untuk semua penyedia OAuth: dapatkan token penyedia, bungkus dalam kredensial Firebase, lalu panggil signInWithCredential. Ketika aplikasi juga perlu memanggil API Google (Drive, Calendar), access token kini berasal dari langkah terpisah, authorizationClient.authorizeScopes, seperti dijelaskan dalam panduan migrasi google_sign_in.

Operasi CRUD Firestore dan Pemodelan Data

Cloud Firestore mengatur data ke dalam koleksi dan dokumen. Tidak seperti basis data SQL, Firestore tidak berskema: setiap dokumen dapat berisi field yang berbeda. Fleksibilitas ini cocok untuk aplikasi Flutter, tetapi memerlukan pemodelan data yang disiplin agar terhindar dari masalah performa.

Menulis dan Membaca Dokumen

Operasi Firestore sangat mudah dengan paket cloud_firestore. Setiap pembacaan dan penulisan menargetkan path dokumen tertentu.

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() memastikan timestamp yang konsisten di seluruh perangkat dengan menggunakan jam server Firestore alih-alih jam klien. Sejak cloud_firestore 7.1.0, FieldValue.minimum dan FieldValue.maximum bergabung dengan transformasi sisi server: keduanya menyimpan nilai yang lebih kecil atau lebih besar antara nilai tersimpan dan nilai masuk tanpa pembacaan, cocok untuk penghitung seperti skor terbaik.

Stream Real-Time dengan snapshots()

Firestore unggul dengan sinkronisasi real-time. Metode snapshots() mengembalikan Stream yang memancarkan data baru setiap kali dokumen yang mendasarinya berubah, tanpa perlu polling.

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());
  }
}

Di dalam widget Flutter, stream ini terintegrasi langsung dengan StreamBuilder untuk membangun ulang UI pada setiap perubahan basis data. Firestore menangani manajemen koneksi, caching, dan persistensi offline secara otomatis.

Aturan Keamanan Firestore untuk Aplikasi Flutter

Aturan keamanan berjalan di server Firestore dan mengontrol akses baca/tulis di tingkat dokumen. Tanpa aturan yang tepat, pengguna terautentikasi mana pun dapat membaca atau memodifikasi dokumen apa pun.

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;
    }
  }
}

Variabel request.auth.uid berisi ID pengguna terautentikasi dari Firebase Auth. Aturan yang mereferensikan resource.data memeriksa field dokumen yang ada, sedangkan request.resource.data memvalidasi data tulis yang masuk.

Persistensi Offline dan Strategi Caching

Firestore mengaktifkan persistensi offline secara default pada platform seluler. Ketika perangkat kehilangan konektivitas, operasi baca mengembalikan data yang di-cache dan operasi tulis mengantre secara lokal hingga koneksi pulih.

Perilaku ini tidak memerlukan kode Flutter tambahan: panggilan get() dan snapshots() yang sama tetap berfungsi saat offline. Namun, dua hal penting untuk aplikasi produksi:

• Ukuran cache: Firestore menyimpan semua dokumen yang telah dibaca klien. Untuk aplikasi dengan banyak data, konfigurasikan Settings(cacheSizeBytes: Settings.CACHE_SIZE_UNLIMITED) atau tetapkan batas tertentu.
• Indikator penulisan tertunda: Gunakan SnapshotMetadata.hasPendingWrites untuk menunjukkan kepada pengguna kapan perubahan lokal belum tersinkron ke server.

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),
      ],
    );
  },
)

Menyusun Aplikasi Flutter Firebase untuk Produksi

Arsitektur yang skalabel memisahkan logika Firebase dari kode UI. Pola repository menyediakan lapisan abstraksi bersih yang menyederhanakan pengujian dan migrasi backend di masa depan.

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
}

Dengan pola ini, solusi manajemen state seperti Riverpod atau BLoC menggunakan antarmuka repository tanpa mengetahui Firestore. Pengujian unit dapat menggantinya dengan mock repository yang mengembalikan data yang telah ditentukan.

Upgrade ke FlutterFire 5: Apa yang Rusak

Rilis mayor Oktober 2026 (BoM 5.0.0, firebase_auth 7.0.0, cloud_firestore 7.0.0, firebase_core 5.0.0) lebih banyak mengubah persyaratan build daripada API Dart. Poin-poin yang menggagalkan build atau code review:

• Android minSdk 24: plugin dibangun di atas Firebase Android BoM 35. Proyek yang masih memakai minSdk 21 atau 23 berhenti terkompilasi.
• Apple SDK 13: Firebase Apple SDK naik ke 13.0.0 dengan Swift Package Manager (12.19.0 dengan CocoaPods), dan paket Swift mewajibkan macOS 11.
• App Check: parameter activate berganti nama menjadi providerWeb, providerAndroid, dan providerApple.
• Deprecation: setIndexConfigurationFromJSON berstatus deprecated di cloud_firestore 7.0.0, dan firebase_ml_model_downloader tidak lagi dipublikasikan.
• Sudah dihapus di lini 6.x: fetchSignInMethodsForEmail() dan User.updateEmail(). Kode yang memeriksa penyedia mana yang dipakai sebuah email sebelum login harus dirancang ulang, karena perlindungan email enumeration menyembunyikan informasi tersebut.

Daftar lengkap per paket ada di catatan rilis FlutterFire dan changelog cloud_firestore.

Pertanyaan Wawancara Firebase untuk Developer Flutter

Wawancara menguji pemahaman konseptual sekaligus implementasi praktis layanan Firebase. Pertanyaan berikut muncul secara rutin dalam wawancara developer Flutter pada 2026. Panduan pertanyaan wawancara Flutter yang lebih luas membahas sisi framework.

Bagaimana authStateChanges() berbeda dari idTokenChanges() dan userChanges()?

authStateChanges() dipicu hanya pada peristiwa masuk dan keluar. idTokenChanges() juga dipicu saat token ID disegarkan (kira-kira setiap jam). userChanges() menangkap semua hal di atas ditambah pembaruan profil seperti updateDisplayName(). Untuk sebagian besar navigation guard, authStateChanges() sudah cukup.

Apa yang terjadi ketika penulisan Firestore terjadi saat perangkat offline?

Penulisan disimpan dalam cache lokal dan antrean penulisan tertunda. Listener snapshots() segera menerima data yang diperbarui dengan metadata.hasPendingWrites == true. Ketika konektivitas pulih, Firestore menyinkronkan penulisan tertunda secara otomatis, dan penulisan terakhir yang mencapai server yang berlaku.

Bagaimana data Firestore sebaiknya dimodelkan untuk aplikasi chat?

Koleksi chats di mana setiap dokumen berisi metadata (peserta, timestamp pesan terakhir), dan subkoleksi messages di bawah setiap dokumen chat. Struktur ini memungkinkan kueri daftar chat pengguna secara efisien sekaligus melakukan paginasi pesan dalam setiap percakapan. Denormalisasi pesan terakhir ke dalam dokumen induk untuk menghindari pembacaan subkoleksi pada tampilan daftar.

Mengapa FieldValue.serverTimestamp() sebaiknya lebih dipilih daripada DateTime.now()?

DateTime.now() menggunakan jam perangkat, yang mungkin tidak akurat atau dimanipulasi. FieldValue.serverTimestamp() menggunakan jam server Firestore, yang menjamin urutan konsisten di semua klien. Hal ini penting untuk fitur seperti pengurutan pesan, feed aktivitas, dan log audit.

Bagaimana kueri komposit ditangani di Firestore, dan apa persyaratan indeksnya?

Firestore memerlukan indeks komposit untuk kueri yang menggabungkan beberapa field dengan klausa where dan orderBy. Indeks field tunggal dibuat secara otomatis, tetapi indeks komposit harus didefinisikan secara manual di firestore.indexes.json atau melalui Firebase console. Firestore mencatat tautan langsung untuk membuat indeks yang hilang ketika kueri gagal.

Kapan transaksi sebaiknya dipakai alih-alih batched write?

Transaksi diperlukan ketika penulisan bergantung pada data yang dibaca dalam operasi yang sama, misalnya mengurangi stok hanya jika masih di atas nol. SDK mengulang callback jika dokumen yang dibaca berubah sebelum commit, sehingga callback tidak boleh memiliki efek samping. Batched write melakukan beberapa penulisan secara atomik tanpa pembacaan apa pun, misalnya membuat dokumen dan memperbarui penghitung di tempat lain. Keduanya tidak berperilaku sama saat offline: batch dimasukkan ke antrean, transaksi gagal tanpa koneksi.

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();

Bagaimana peran admin diterapkan dengan Firebase?

Dengan custom claims yang diatur dari lingkungan tepercaya melalui Admin SDK, tidak pernah dari klien Flutter. Claim ikut di dalam token ID, sehingga aturan membacanya sebagai request.auth.token.admin == true tanpa pencarian dokumen tambahan. Dokumentasi custom claims membatasi payload hingga 1000 byte, dan klien baru melihat claim baru setelah token disegarkan, yang dapat dipaksa dengan currentUser.getIdToken(true).

Apa perbedaan antara aturan keamanan dan App Check?

Aturan keamanan menentukan apakah pengguna tertentu boleh membaca atau menulis dokumen tertentu. App Check membuktikan bahwa permintaan berasal dari aplikasi asli di perangkat asli, yang memblokir skrip yang memakai ulang kunci API publik. Keduanya menjawab pertanyaan yang berbeda, sehingga aplikasi produksi membutuhkan keduanya. Sejak FlutterFire 5, App Check diaktifkan dengan providerAndroid, providerApple, dan providerWeb.

Mengapa layar Firestore bisa menjadi mahal, dan bagaimana paginasi dilakukan?

Firestore menagih per pembacaan, penulisan, dan penghapusan dokumen. Listener pada koleksi tanpa batas membaca setiap dokumen yang cocok saat pemuatan pertama, lalu satu pembacaan per dokumen yang berubah. Paginasi memakai query cursor, bukan offset: limit(20) untuk halaman pertama, lalu startAfterDocument(lastDoc) untuk halaman berikutnya, sehingga setiap halaman hanya menghabiskan biaya dokumen yang dikembalikannya.

Firestore atau Realtime Database: pilih yang mana dan mengapa?

Firestore menyimpan dokumen dalam koleksi, mendukung kueri gabungan dengan indeks, dan menagih per operasi. Realtime Database menyimpan satu pohon JSON, menawarkan kueri dangkal pada satu child key, dan menagih terutama berdasarkan bandwidth dan penyimpanan, yang cocok untuk pembaruan kecil yang sangat sering seperti indikator kehadiran. Sebagian besar aplikasi Flutter baru dimulai dengan Firestore dan menambahkan Realtime Database hanya untuk presence.

Untuk persiapan wawancara Flutter yang lebih lengkap, modul latihan khusus mencakup topik-topik ini dengan kuis interaktif dan tantangan berwaktu.

Sumber

• Catatan rilis Firebase untuk Flutter: isi BoM 5.0.0 dan 5.1.0, minSdk 24, penggantian nama parameter App Check
• Changelog cloud_firestore: Pipelines di 6.3.0, FieldValue.minimum/maximum dan jarak findNearest di 7.1.0
• Changelog firebase_auth: validatePassword di 6.0.0, TOTP di macOS di 6.1.0, penghapusan fetchSignInMethodsForEmail
• Panduan migrasi google_sign_in: singleton, initialize, authenticate, otorisasi terpisah di 7.0
• Custom claims Firebase: batas 1000 byte dan penyegaran token

Poin Penting Flutter Firebase untuk Wawancara

• FlutterFire BoM 5.1.0 menyertakan firebase_auth 7.0.1 dan cloud_firestore 7.1.0, serta mewajibkan minSdk Android 24
• google_sign_in 7 mengganti GoogleSignIn().signIn() dengan GoogleSignIn.instance.initialize() lalu authenticate(), dan Firebase hanya membutuhkan idToken
• authStateChanges() menyediakan stream reaktif untuk mengelola status login di seluruh aplikasi tanpa pemeriksaan manual
• Sinkronisasi real-time melalui snapshots() menghilangkan polling dan terintegrasi langsung dengan StreamBuilder untuk pembaruan UI otomatis
• Aturan keamanan wajib untuk produksi: selalu validasi request.auth.uid terhadap field kepemilikan dokumen, dan gunakan custom claims untuk peran
• Transaksi membaca lalu menulis dengan pengulangan, batched write hanya menulis; paginasi memakai cursor karena setiap pembacaan dokumen ditagih
• Persistensi offline bekerja tanpa kode tambahan di seluler; gunakan hasPendingWrites untuk mengomunikasikan status sinkronisasi kepada pengguna
• Pola repository memisahkan Firebase dari logika bisnis, membuat pengujian dan migrasi di masa depan menjadi mudah