Производительность приложений на Bubble. Заметки. Часть 8. Список (list) и Поиск.
Данная серия статей — это мои заметки по книге The Ultimate Guide to Bubble Performance. Тут изложено только то, что фиксировал я, т.к. посчитал это важным.
Есть 2 способа получить список чего-либо:
На примере тех же статей: мы можем найти в сущности "Article" всех прочитавших, если будем сохранять их в список (list) "Reader", который положим в сущность "Article".
То есть у нас получится Article — Reader (list of Users)
Или же мы можем выполнить поиск по всем юзерам и посмотреть, кто из них читал какую-то конкретную статью, при условии, что эти статьи тоже будем сохранять к пользователю.
Список (list)
- Максимальное количество записей 10к
- Кладёт болт на прайваси
- Подгружает сразу все записи
- Использует клиентскую сторону для фильтрации
- Список не обновляется автоматически на клиентской стороне. Нужно обновлять ручками.
Количество записей
Список в Bubble может содержать 10к записей (На момент написания книги).
На примере читателей статьи — в список "Reader" сможем сохранить только 10к человек.
Прайваси рулс
Прайваси рулс не скрывают записи по умолчанию. Они служат дополнительным условием, которое применяется при поиске этих записей на уровне сервера.
То есть при поиске Bubble делает следующее:
Поэтому если мы уже стянули этот список сервера и положили в ОЗУ, то он будет нам доступен полностью, вне зависимости от прайваси.
То есть если мы стянули с сервера сами статьи, то прайваси для юзеров из "Reader" не применятся.
Я вот не вдуплил, почему прайваси для списков не отрабатывают нормально, поэтому протестил на примере с "Article". Получилось следующее:
Прайваси поставил только на юзера:
Если стягиваю статью и показываю список "Reader", Bubble выдает вот что:
То есть Bubble пишет, какие поля скрыты и показывает uniq id каждого пользователя из списка. Вероятнее всего инфа о юзерах уже лежит в ОЗУ клиентского устройства и при определенных навыках её можно оттуда достать.
Подгрузка информации и фильтрация
Если мы работаем со списком, то он стягивается сразу весь с сервера, даже если нам нужна только какая-то его часть.
Например, мы хотим отобразить только тех читателей статьи, которые из той же страны, что и текущий юзер.
Если статью прочли 10к человек, то на клиентское устройство прилетят все 10к, а затем на нём отфильтруются до тех, кто соответствует стране. От такой нагрузки клиентское устройство может ахуеть.
Обновление инфы
Список нужно обновлять ручками после каждого добавления инфы, т.к. он не обновляется автоматически. То есть если мы подгрузили статью, у которой 100 прочитавших, а потом её прочитали ещё 10 человек, то список всё равно будет содержать 100 человек, а не 110. Чтобы число обновилось, нужно заново этот список стянуть с сервера.
Поиск
- Нет лимита на количество записей
- Инфа защищена прайваси
- Подгружает только то, что попросили
- Использует сервер для фильтрации
- Инфа обновляется динамически
Количество записей
Нет лимита на количество записей при поиске.
Прайваси рулс
Правила конфиденциальности при поиске применяются на первом шаге. Это значит, в браузер попадёт только та инфа, которую разрешено видеть пользователю.
То есть тут работает то, о чём я писал выше:
- Применяются прайваси
- Применяются другие условия
- Полученный результат улетает на клиентское устройство.
Я протестировал этот момент на тех же статьях и пользователях. Bubble показал мне пустой список, т.к. прайваси ограничивают доступ. Всё верно.
Подгрузка информации и фильтрация
Когда выполняем поиск, вся инфа обрабатывается на сервере и фильтрация в том числе. После обработки инфы она отправляется клиенту.
На нашем примере с читателями:
Bubble на своих серверах сначала поймёт, кто из той же страны, что и текущий пользователь, и затем отправит этот этот список юзеру в браузер. Он не пришлёт все 10к человек.
Обновление инфы
Если мы изменим страну юзера, который прочитал статью, то Bubble сразу уберёт этого человека из списка, т.е. нам не нужно будет обновлять руками.
Что лучше выбрать?
Тут нужно смотреть от ситуации.
Если нам не так важны прайваси и количество элементов у нас небольшое, то можно использовать списки, чтобы приложение работало быстрее.
Рекомендуется юзать метод со списками при записях не больше 100
Например, у статьи есть теги. Мы знаем, что их количество точно не будет больше 100, тогда можно их класть в список Article - Tags (list).
→ Подписывайтесь на мой канал в Телеграме Иван Некодит.