Как играть с Firebase, сохраняя контроль над пропускной способностью
После нескольких недель работы с Firebase и небольшого количества вопросов «Что, черт возьми?» Я собрал несколько простых советов, которые помогут вам сэкономить трафик.
Сейчас они могут показаться очевидными, но не тогда, когда мы начали работать с Firebase.
Подружитесь с инструментом профилирования базы данных
Инструмент профилировщика базы данных является частью интерфейса командной строки Firebase. Он регистрирует все действия, связанные с вашей базой данных, и предоставляет вам подробные отчеты. Отчет включает в себя часть информации о времени ответа, загруженных и выгруженных байтах и неиндексированных запросах, которые могут повлиять на производительность приложения.
Чем раньше вы его воспользуетесь, тем лучше для вашего приложения (и для вашего душевного спокойствия;)).
Подробнее о профилировщике читайте в официальной документации.
Включить локальное кеширование
Чтобы данные не загружались каждый раз при включении приложения, включите постоянство диска. После этого Firebase сохранит локальную копию базы данных и получит только информацию о новых, измененных или удаленных элементах. Это также позволит вам запрашивать данные в автономном режиме.
Подробнее об офлайн-возможностях читайте в официальной документации.
Индексируйте ваши данные
Если вы часто фильтруете или упорядочиваете данные на основе определенного поля, вам следует подумать о добавлении к нему индекса. Эта простая операция не только улучшит производительность ваших запросов, но и сэкономит полосу пропускания, потому что для неиндексированных запросов клиент загружает все данные для данного узла и только затем выполняет запрос на нем.
Подробнее об индексировании данных читайте в официальной документации.
Убедитесь, что вы используете правильный слушатель, который слушает соответствующий узел
Firebase предоставляет вам два типа слушателей:
- слушатели значений, которые позволяют вам отслеживать изменения в данном узле (и его дочерних элементах)
- дочерние слушатели (дочерний элемент добавлен, дочерний элемент изменен, дочерний элемент удален, дочерний элемент перемещен), что позволяет вам отслеживать изменения в дочерних элементах данного узла
Похоже, они делают то же самое, а? Не совсем.
Так в чем разница?
Слушатель значений запускается каждый раз, когда данные на данном узле изменяются, и он возвращает все данные в этом месте, включая дочерние данные.
Дочерний прослушиватель запускается каждый раз, когда дочерний элемент на данном узле добавляется, изменяется, удаляется или перемещается, и возвращает только данные обработанного дочернего элемента.
Какой вывод?
Слушатель значений следует использовать только для самых глубоких узлов, которые фактически представляют примитивные типы. В противном случае используйте дочерний слушатель.
Подробнее о получении данных читайте в официальной документации.
Избегайте загрузки данных, когда они вам не нужны
Когда вы записываете данные через REST API, Firebase возвращает ответ, содержащий данные, которые вы только что отправили. В большинстве случаев вам, вероятно, не нужно получать эти данные.
Чтобы предотвратить загрузку всего вывода, просто добавьте print = silent в параметры запроса. С этого момента сервер будет возвращать код состояния 204 No Content.
Подробнее о параметре печати читайте в официальной документации.
Последний, но тем не менее важный
Всегда внимательно читайте документацию;)
У вас есть другие советы? Не стесняйтесь оставлять их в комментариях. Будет здорово об этом поговорить :)
