Firebase: бэкенд для приложений — от документов до пуш-уведомлений

Знакомая сцена. Вы делаете приложение, где данные должны жить сразу на всех устройствах: список задач, который видят оба участника, чат, общая доска. Значит, нужна живая синхронизация — изменил один, у второго обновилось мгновенно. Плюс работа без интернета: в метро человек добавил задачу, а при появлении сети она долетела. Плюс пуш-уведомления. Плюс вход. Написать всё это руками — месяцы: сервер с веб-сокетами, локальный кеш, очередь синхронизации, отдельный сервис пушей.

И каждый кусок легко сделать с ошибкой. Синхронизация ломается на конфликтах правок. Офлайн-режим теряет данные на плохой сети. Пуши не доходят до закрытого приложения. Это не бизнес-логика, а инфраструктура, на которую уходит больше сил, чем на само приложение.

Firebase отдаёт всё это готовым. Данные синхронизируются между устройствами сами и работают без сети. Вход, хранилище файлов и пуш-уведомления — встроенные сервисы. Вы пишете приложение, а живую синхронизацию, офлайн-кеш и доставку пушей берёт на себя платформа. Это разница между «полгода на инфраструктуру» и «сосредоточиться на самом продукте».

Разберём по шагам: что входит в Firebase, как устроена документная база, как работает живая синхронизация, как доступ режут Security Rules и как отправить пуш. В конце соберём realtime-список задач.

Firebase хранит данные в документной NoSQL-базе — той же модели, что и MongoDB. Базы данных и работу с API разбирают на курсах по бэкенду на Хекслете.

Что такое Firebase

Firebase — платформа от Google для быстрой сборки бэкенда приложений. Это BaaS, Backend as a Service: набор готовых сервисов вместо собственного сервера. Исторически Firebase вырос из мобильной разработки, поэтому особенно силён там, где важны живые данные, работа без сети и пуш-уведомления.

Главная идея — приложение работает с данными напрямую, без промежуточного сервера, который вы пишете. Клиентская библиотека общается с Firebase, доступ ограничивают правила, а синхронизация и кеш встроены. Один и тот же бэкенд обслуживает и мобильное приложение, и веб, и планшет — данные везде одни и те же и обновляются разом.

Важно сразу понять модель данных. Firebase хранит не таблицы со строками, как реляционные базы, а документы — записи в свободной структуре, сгруппированные в коллекции. Это документная NoSQL-модель, как у MongoDB. Если вам нужна строгая реляционная база с SQL и связями, ближе подойдёт что-то на PostgreSQL. Firebase выбирают за живую синхронизацию, офлайн и скорость старта, а не за сложные запросы по связанным таблицам.

Что входит в Firebase

Платформа собрана из сервисов, каждый из которых закрывает свой пласт работы.

Сердце платформы — Firestore. Вокруг него и строится приложение: данные лежат в Firestore, доступ к ним даёт Authentication, файлы — в Storage, а уведомления о новых данных шлёт Cloud Messaging. Дальше разберём ключевые сервисы по очереди.

Документная база: коллекции и документы

В реляционной базе данные лежат в таблицах: строки и колонки, всё по строгой схеме. Firestore устроен иначе. Здесь данные — это документы, сгруппированные в коллекции.

Главное отличие от таблицы: документ не обязан повторять структуру соседей. У одной задачи есть поле с датой, у другой нет — это нормально, жёсткой схемы нет. А внутри документа значения бывают вложенными: объекты, массивы и даже целые подколлекции. Структура ближе к JSON, чем к таблице.

tasks (коллекция)
 └── "a1b2c3" (документ)
       title:     "Купить хлеб"
       done:      false
       owner:     "user_42"
       createdAt: 2026-06-24
 └── "d4e5f6" (документ)
       title:     "Позвонить маме"
       done:      true
       owner:     "user_42"

Такая модель быстрее на простых сценариях «достать документ по идентификатору» и удобнее, когда структура данных гибкая. Расплата — сложные запросы по связям между коллекциями делать тяжелее, чем в SQL. Поэтому в Firestore данные часто намеренно дублируют, чтобы читать всё одним запросом — это нормальная практика для документных баз.

Живая синхронизация и работа без сети

Здесь Firebase показывает то, ради чего его и берут. Обычная база отдаёт данные на запрос: спросил — получил ответ один раз. Firestore умеет иначе — вы подписываетесь на данные, и библиотека сама присылает обновление каждый раз, когда они меняются.

import { collection, onSnapshot } from 'firebase/firestore';

// подписка на коллекцию задач
onSnapshot(collection(db, 'tasks'), (snapshot) => {
  snapshot.forEach((doc) => {
    console.log(doc.id, doc.data());
  });
});

Эта функция срабатывает не один раз, а каждый раз при изменении данных. Кто-то с другого устройства добавил задачу — у вас она появилась мгновенно, без перезапроса. На этом строят чаты, общие доски, совместное редактирование: данные живые по умолчанию.

Вторая встроенная вещь — работа без сети. Библиотека держит локальный кеш. Пропал интернет — приложение продолжает читать данные из кеша и принимать новые записи. Вернулась сеть — всё, что накопилось, само улетает на сервер, а свежие чужие изменения подтягиваются. Пользователь в метро ничего не замечает, а вы не написали ни строчки логики синхронизации.

Аутентификация: вход из коробки

Firebase Authentication берёт на себя регистрацию и вход. Поддерживает много способов, и подключаются они единообразно.

import { getAuth, signInWithEmailAndPassword } from 'firebase/auth';

const auth = getAuth();
await signInWithEmailAndPassword(auth, 'nikita@hexlet.io', 'secret123');

После входа у пользователя появляется идентификатор, который связывает его данные с правилами доступа. Именно по нему правила решают, что человеку можно читать и менять.

Security Rules: доступ через правила

Раз приложение обращается к базе напрямую, встаёт тот же вопрос, что и в любом BaaS: как не дать пользователю прочитать или удалить чужое. Ответ Firebase — Security Rules, отдельный язык правил доступа. Это не SQL: правила пишут на своём декларативном языке и хранят на стороне Firebase.

Правило сопоставляет путь к документу с условием. Вот правило, которое разрешает работать только со своими задачами:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    match /tasks/{taskId} {
      // читать и менять может только владелец
      allow read, write: if request.auth.uid == resource.data.owner;
    }
  }
}

Разберём условие. request.auth.uid — идентификатор вошедшего пользователя. resource.data.owner — поле owner в документе. Доступ есть, только если они совпадают: то есть пользователь работает со своими задачами и не видит чужие. Правила проверяются на сервере Firebase, и обойти их из приложения нельзя.

Главная ошибка — оставить правила в тестовом режиме. При создании базы Firebase предлагает открытый режим, где читать и писать может кто угодно. Удобно на старте, но если так уйти в прод — данные открыты всему интернету. Это причина большинства утечек из приложений на Firebase. Перед публикацией правила обязательно закрывают и проверяют.

Пуш-уведомления: Cloud Messaging

Это сервис, которого нет у многих аналогов и за который Firebase часто и выбирают. Cloud Messaging (FCM) доставляет пуш-уведомления на устройства — даже когда приложение закрыто или телефон в кармане.

Схема такая. Каждое устройство при запуске получает уникальный токен. Ваш сервер или Cloud Function отправляет сообщение в FCM — на конкретный токен или на тему, на которую подписаны устройства. FCM доставляет уведомление, а операционная система показывает его пользователю.

Связка с остальным Firebase получается естественной: Cloud Function срабатывает на новый документ в Firestore — например, новое сообщение в чате — и тут же шлёт через FCM пуш собеседнику. Сервер для этого писать не нужно.

Хранилище и серверные функции

Cloud Storage хранит файлы: аватары, вложения, фото. Доступ к ним режут такие же правила, как и к базе, поэтому свой файл пользователь меняет, а чужой нет. Загрузка устроена просто — указали путь и отдали файл.

Cloud Functions — серверный код, который запускается на события: создан документ, зарегистрировался пользователь, загружен файл. Туда выносят логику, которой нельзя доверять клиенту: начисления, проверки, отправку тех самых пушей. Это мостик на случай, когда прямого доступа к базе не хватает.

Что ещё в платформе

За пределами хранения данных Firebase даёт целый набор инструментов, которые иначе пришлось бы подключать по отдельности. Их редко осваивают сразу, но знать о них полезно.

В сумме это значит, что вокруг данных уже собрана вся обвязка: раздача, аналитика, контроль сбоев и безопасность. Не нужно собирать платформу из десятка отдельных сервисов — большинство задач закрыто внутри одной экосистемы.

Практика: realtime-список задач

Соберём общий список задач, который синхронизируется между устройствами. Серверного кода — ноль.

Шаг 1. Подключить Firebase. Создаёте проект в консоли, копируете настройки в приложение и инициализируете:

import { initializeApp } from 'firebase/app';
import { getFirestore } from 'firebase/firestore';

const app = initializeApp(firebaseConfig);
const db = getFirestore(app);

Шаг 2. Закрыть правила. Без этого данные открыты всем:

match /tasks/{taskId} {
  allow read, write: if request.auth.uid == resource.data.owner;
}

Шаг 3. Подписаться на задачи. Список будет обновляться сам при любом изменении:

import { collection, onSnapshot, addDoc } from 'firebase/firestore';

// живой список — перерисовывается при каждом изменении
onSnapshot(collection(db, 'tasks'), (snapshot) => {
  const tasks = snapshot.docs.map((d) => ({ id: d.id, ...d.data() }));
  renderTasks(tasks);
});

// добавить задачу — у всех подписчиков появится мгновенно
await addDoc(collection(db, 'tasks'), {
  title: 'Купить хлеб',
  done: false,
  owner: auth.currentUser.uid,
});

Готово. Добавили задачу на телефоне — она тут же появилась в браузере. Выключили сеть — список остался, новые задачи запомнились и улетели при возвращении интернета. Всё это вы получили бесплатно: живую синхронизацию, офлайн и защиту правилами — без единой строки серверного кода.

Антипаттерны

Оставить правила в тестовом режиме. Самая дорогая ошибка: открытый доступ означает, что любой читает и меняет все данные. Правила закрывают и проверяют до выхода в прод, а не после первой утечки.

Глубокая вложенность документов. Документ внутри документа внутри документа — и чтение превращается в цепочку запросов. В Firestore структуру держат плоской, а связи решают через подколлекции и дублирование, а не через глубокую вложенность.

Читать всю коллекцию ради нескольких записей. Запрос «дай все документы» на большой коллекции — это деньги и медленно, ведь оплата идёт за количество прочитанных документов. Нужные записи отбирают фильтрами и постраничным выводом.

Ждать от Firestore сложных реляционных запросов. Это документная база, а не SQL. Объединений между коллекциями и сложных условий тут нет. Если приложение строится вокруг таких запросов — возможно, нужна реляционная база, а не Firebase.

Не следить за расходом. Оплата зависит от числа чтений, записей и трафика. Живая подписка на большую коллекцию способна тихо набрать много чтений. На растущем проекте лимиты и стоимость планируют заранее.

FAQ

Firebase бесплатный?

Есть бесплатный тариф — его хватает для учёбы, прототипов и небольших приложений. Дальше оплата идёт по факту: за чтения и записи в базе, трафик, отправленные пуши. Модель «платишь за использование» удобна на старте, но требует следить за расходом на росте.

Чем Firebase отличается от Supabase?

Оба — это BaaS, но базы у них разные. Firebase хранит данные в документной NoSQL-базе и силён в живой синхронизации, офлайн-режиме и пушах. Supabase построен на реляционном PostgreSQL с SQL и связями. Для мобильных приложений с живыми данными чаще берут Firebase, для проектов вокруг сложных запросов — Supabase.

Нужно ли знать бэкенд, чтобы начать?

Базовое понимание баз данных обязательно — без него легко наделать ошибок со структурой и правилами. Но серверное программирование на старте не нужно: его роль берут на себя прямой доступ к базе, готовая аутентификация и Security Rules. Сложную логику добавляют позже через Cloud Functions.

Firebase подходит только для мобильных приложений?

Нет, веб тоже полноценно поддерживается, как и десктоп. Firebase вырос из мобильной разработки и силён в её задачах, но его клиентские библиотеки есть для JavaScript, мобильных платформ и других сред. Один бэкенд спокойно обслуживает приложение на всех платформах сразу.

Что выбрать внутри Firebase — Firestore или Realtime Database?

В Firebase две базы. Realtime Database — старая, хранит данные одним большим деревом, проще, но слабее в запросах. Cloud Firestore — современная, с коллекциями, документами и нормальными запросами. Для новых проектов обычно берут Firestore, Realtime Database остаётся в старых приложениях.

Не привязывает ли Firebase к Google?

Привязка ощутимая: данные, правила и сервисы устроены по-своему, и переезд на другую платформу потребует переписать работу с базой и аутентификацией. Это плата за скорость старта и готовую инфраструктуру. Если важна переносимость, на это стоит смотреть до того, как проект вырастет.