Запрос к бэкенду

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

Типы запросов

Мы предлагаем следующие типы запросов к бэкенду, которые можно настроить для любого виджета или страницы.

• Query Collection or Table: Этот тип запроса используется для получения одной записи или списка записей из коллекции Firestore или таблицы Supabase.
• Document from Reference: Используется для получения деталей из ссылки на документ.
• API Call Query: Используется для запуска вызова API.
• SQLite Query: Используется для выполнения SQL-запросов.
• Algolia Search: Используется для запуска поиска Algolia в коллекции Firestore.

Различия между действиями и запросами к бэкенду

Аспект	Actions	Backend Queries
Триггер	Запускаются взаимодействиями пользователя, такими как нажатия, двойные нажатия или длительные нажатия на виджеты, или могут выполняться автоматически при загрузке страницы.	Автоматически запускаются при переходе пользователя на страницу или виджет, содержащий запрос.
Использование	Могут использоваться для навигации между страницами, отображения сообщений, обновления переменных, выполнения вызовов API и многого другого.	Для приложений, требующих мгновенных обновлений, таких как чат или live-результаты, запросы к бэкенду могут автоматически обновлять UI с учетом последних изменений в базе данных.
Множественность	На одном виджете можно указать несколько действий.	На конкретном виджете или странице можно указать только один запрос к бэкенду.
Условное выполнение	Могут быть условными, то есть выполнять разные действия при определенных условиях.	-
Кэширование	-	Могут включать механизмы кэширования для улучшения производительности приложения за счет снижения количества вызовов сервера и обеспечения оффлайн-доступа к данным.
Обработка состояний	-	Часто включают обработку состояний загрузки и пустых состояний, поскольку процесс получения данных может занимать время и не всегда возвращать результаты.
Получение данных	-	Используются только для получения данных из бэкенда.

Изменение индикатора загрузки

Пока запрос к бэкенду загружает результаты, отображается индикатор загрузки по умолчанию из Project Theme Loading Indicator (который можно изменить в Navigation menu > Theme Settings > Design System > Loading Indicator.) Однако, если вы хотите заменить его на пользовательский индикатор загрузки для конкретного запроса к бэкенду, следуйте инструкциям ниже:

Чтобы изменить индикатор загрузки:

1. Убедитесь, что вы добавили запрос к бэкенду.
2. Откройте раздел Backend Query (справа) и прокрутите вниз до Backend Query Loading Widget. Откройте его, нажав на значок стрелки.
3. Установите Loading Widget Type в Image. Вы также можете выбрать Component, если уже создали компонент загрузки.
4. Включите View in UI Builder. Это позволит увидеть ваш пользовательский индикатор загрузки на холсте (до запуска приложения).
5. Выберите Image Type, добавьте изображение и настройте его Padding и Width.
6. Чтобы отобразить индикатор по центру, включите переключатель Center Image.
7. Запустите приложение, и ваш пользовательский индикатор загрузки появится во время загрузки данных.

Копирование запроса

Иногда может потребоваться отобразить один и тот же список элементов с небольшими изменениями. Например, показать все задачи Todo и только завершенные задачи Todo. В таком случае вы можете скопировать весь запрос к бэкенду, чтобы ускорить процесс сборки. Это особенно полезно при сложных запросах к бэкенду.

Чтобы скопировать запрос:

1. Выберите виджет (например, ListView, GridView и т. д.), к которому уже добавлен запрос к бэкенду.
2. Выберите вкладку Backend Query и нажмите кнопку Copy.
3. Теперь выберите виджет (куда вы хотите добавить запрос), перейдите на вкладку Backend Query и нажмите кнопку Paste Backend Query.
4. Нажмите Confirm.

Перемещение запроса к родительскому виджету

Может потребоваться использовать один и тот же запрос к бэкенду для нескольких виджетов на странице. Но если сделать это, возникнут избыточные вызовы сервера для одних и тех же данных. Вместо копирования на каждый виджет запрос можно переместить к любому родительскому виджету. Существующие виджеты будут использовать сгенерированную переменную, полученную из запроса родительского виджета.

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

Отображение виджета пустого списка

Виджет Empty List используется для отображения сообщения, когда в списке нет элементов. Этот виджет улучшает пользовательский опыт, показывая сообщение вместо пустого экрана.

Чтобы отобразить виджет пустого списка:

1. Убедитесь, что вы добавили запрос к бэкенду к любому прокручиваемому виджету, такому как ListView, GridView, Column, Row, DataTable или StaggeredView.
2. Выберите прокручиваемый виджет (к которому добавлен запрос к бэкенду), перейдите в панель свойств и включите Show Empty List Widget.
3. Установите Widget Type в Image или Component. Дополнительные опции зависят от выбора.
4. Попробуйте переключить View in UI Builder. Это позволит увидеть виджет пустого списка на холсте (до запуска приложения).
5. Вы также можете управлять размером и центрированием виджета с помощью доступных опций.

Кэширование запросов к бэкенду

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

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

Например, в e-commerce-приложении можно кэшировать данные о продуктах, такие как описания, цены и изображения, чтобы избежать ненужных вызовов API при каждой загрузке страницы.

примечание

Кэширование запросов к бэкенду работает для всех типов запросов.

Single time Query

Для запросов Firebase включите Single Time Query, если хотите, чтобы запрос получал данные только один раз. В противном случае запрос работает в реальном времени и автоматически обновляется при изменении данных.

Когда использовать кэширование

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

1. Статичный контент, такой как изображения и видео.
2. Конфигурационные данные, такие как настройки приложения или системные параметры.
3. Данные, требующие значительных вычислений, такие как сложные отчеты или аналитика.

Когда НЕ использовать кэширование

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

1. Большие объемы данных могут вызвать проблемы с производительностью и не всегда подходят для кэширования.
2. Чувствительные или конфиденциальные данные не следует кэшировать, поскольку это может привести к несанкционированному доступу.
3. Часто изменяющиеся данные, такие как в сценариях реального времени или близких к реальному, не подходят для кэширования, поскольку кэшированные данные быстро устаревают.
4. Критически важное время отклика, когда данные должны быть актуальными и точными в любое время.

Пример

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

Чтобы улучшить производительность, можно кэшировать данные на странице деталей для быстрого получения и отображения пользователям.

Вот как это выглядит:

примечание

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

Чтобы кэшировать запрос к бэкенду:

1. Убедитесь, что вы добавили запрос к бэкенду. В этом примере, чтобы получить данные из документа Firebase, мы добавляем запрос к бэкенду на уровне страницы как Single Time Query. Мы используем ссылку на документ для получения деталей сотрудника.

Запрос деталей сотрудника с использованием ссылки на документ

2. Откройте Query Cache Settings и Enable Query Caching.
3. Определите Scope кэша. Если установить App Level и точно такой же запрос выполняется на любой другой странице приложения, результат будет взят из кэша. Однако если установить Page Level, кэшированный результат будет использоваться только на этой странице при многократном выполнении запроса.
4. Если текущий запрос полностью новый/отличается, создайте Query Name. Если нет, и вы хотите использовать кэшированный результат этого запроса (который мог быть создан где-то еще), выберите имя из списка.

5. Если остановиться на этом примере, возникнут проблемы с неточностью данных. Это значит, что когда данные сотрудника кэшированы, те же данные будут использоваться для всех сотрудников, чего мы не хотим. Мы хотим кэшировать данные для каждого сотрудника индивидуально. Для этого можно установить Unique Key. Здесь уникальным ключом может быть ID сотрудника или ссылка на документ.

Data inaccuracy without Unique Key

Adding Unique Key

6. На этом этапе кэширование включено, но остается одна проблема. Как только запрос кэширован, он будет использоваться вечно, хотя данные в бэкенде обновляются. Это происходит потому, что мы не очищаем или не инвалидируем кэш в нужное время. Чтобы правильно инвалидировать кэш, используйте свойство Should Override Cache или действие Clear Query Cache. Это помогает удалить устаревшие или неточные кэшированные данные.

   1. Свойство Should Override Cache принимает булево значение (True/False). Это значит, что мы можем предоставить переменную (например, переменную App State с именем isCacheOverride), которая знает, когда перезаписывать кэш. Создайте такую и установите здесь.
   2. Создайте еще одну переменную App State, например lastCacheTime, и установите текущее время по умолчанию. Она будет использоваться для сохранения времени получения результатов из бэкенда. Вы лучше поймете ее полезность в логике, которую добавим на следующем шаге.

Установка Should Override Cache на переменную App State

7. Теперь нужно добавить логику, которая определяет, перезаписывать ли кэш (каждый раз при загрузке страницы) и устанавливает переменную isCacheOverride соответственно. Вот как это работает:

   1. Сначала проверьте, установлено ли lastCacheTime. Если нет, установите текущее время.
   2. Затем создайте пользовательское действие, которое проверяет, прошло ли более 30 минут с lastCacheTime. Примечание: 30 минут — это время истечения кэша, и здесь оно минимально для упрощения; важно тщательно выбрать подходящее время истечения кэша в зависимости от характера ваших данных.
   3. Если True:
      1. Обновите lastCacheTime с текущим временем и isCacheOverride на True. Убедитесь, что Update Type установлен в Rebuild Current Page, чтобы запрос к бэкенду выполнился заново, инвалидируя кэш и отображая обновленные данные.
      2. Вы также можете добавить действие для Clear Query Cache.
      3. Продолжая тот же поток действий, подождите 1 секунду и снова обновите isCacheOverride на False, чтобы кэшированный результат не перезаписывался при загрузке страницы в следующие 30 минут.

Note

Примечание: в этом примере мы используем как действие Clear Query Cache, так и свойство Should Override Cache для очистки или инвалидации кэша. Хотя оба выполняют одну задачу, в целом считается лучшей практикой явно очищать Clear Query Cache, а не полагаться на булево значение Should Override Cache. Однако в некоторых случаях вы можете захотеть условно перезаписывать кэш вместо явного действия, поэтому опция доступна.

Вот как выглядит пользовательская функция, если вы хотите проверить:

bool isOverrideCacheAction(DateTime cacheTime) {
  // Add your function code here!
  return DateTime.now().difference(cacheTime).inMinutes > 30;
}

Пользовательская функция для проверки, прошло ли более 30 минут с последнего времени кэша

подсказка

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

{ "id": 1, "lastCacheTime": '2023-03-22T14:30:00+00:00', }

Clear Query Cache [Action]

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

подсказка

Это помогает улучшить производительность приложения и гарантировать, что пользователи видят самую актуальную информацию.

Следуйте шагам ниже, чтобы добавить это действие к любому виджету.

1. Выберите Widget (например, Container, Button и т. д.), к которому хотите добавить действие.
2. Выберите Actions из properties panel (правое меню). Если это первое действие, нажмите кнопку + Add Action. В противном случае нажмите кнопку "+" под плиткой предыдущего действия (в Action Flow Editor) и выберите Add Action.
3. Найдите и выберите действие Clear Query Cache (в разделе State Management).
4. Определите Scope кэша: на уровне App Level или Page Level.
5. Установите Query Name в то имя, которое вы указали при добавлении кэша запроса.
6. Если при кэшировании запроса вы установили Unique Key, добавьте тот же ключ здесь. Это гарантирует, что кэш будет удален только для конкретных данных.