Производительность приложений на Bubble. Заметки. Часть 9. Эффективный поиск.
Данная серия статей — это мои заметки по книге The Ultimate Guide to Bubble Performance. Тут изложено только то, что фиксировал я, т.к. посчитал это важным.
Много условий (constraint) - это хорошо.
Bubble ищет инфу путём исключения той, которая не соответствует обозначенным условиям. Поэтому, чем больше условий, которые могут исключить лишнюю инфу — тем быстрее Bubble найдёт нужную.
Повторение поиска
Некоторые разрабы закидывают списки в RG, чтобы в дальнейшем этот список использовать в других местах.
Это делать не обязательно. Bubble выполняет поиск только 1 раз, если условия совпадают. То есть если вы искали пользователей, которые прочитали какую-то определенную статью, то не обязательно этот список сохранять куда-то. Можно выполнить этот поиск ещё раз. И, как понимаю, он будет уже сохранён и выполнится быстрее, т.к. условия поиска не менялись.
Использование :filtered
В предыдущих частях заметок неоднократно упоминалось, что :filtered, добавленный к Do a search, переносит конечную фильтрацию на клиентскую сторону. Это делать нежелательно. Если есть возможность, лучше прописать все условия фильтрации в Do a search, чтобы поиск инфы проходил полностью на серверной стороне.
Bubble подгружает только ту инфу, которую попросили
Если для вывода инфы используем, к примеру, do a search:first item или RG:until item #5, то Bubble подгружает только те элементы, которые попросили, а не кидает весь список клиенту.
В примерах он передаст с сервера первый элемент для Do a search и первые 5 элементов в случае с RG.
Использование сохраненных списков
Иногда будем делать сложные поиски, которые выполняют поиск и на серверной и на клиентской стороне. Дабы сильно не нагружать обе стороны, такие поиски можно делать 1 раз, а затем результат сохранять, к примеру, в RG, чтобы потом обращаться к нему было быстрее.
Вложенные структуры
Вложенные структуры снизят производительность приложения за короткий промежуток времени. Они встречаются в поиске и в RG.
Поиск
В поиске вложенная структура будет применяться каждый раз, когда в качестве условия (constraint) стоит другой поиск.
В этом примере, чтобы найти нужного пользователя, Bubble должен выполнить второй поиск, где должен найти подходящую статью.
На самом деле мы выполняем не два поиска. Мы выполняем первый поиск, а затем выполняем поиск для каждого пользователя, чтобы найти определенную "Article". То есть если у нас 500 пользователей, то Bubble выполнит 501 поиск.
Вложенные структуры в RG
Каждый раз, когда выводим список в RG, можно легко ошибиться в количестве поисков, которое сделали.
В примере ниже мы делаем 1 поиск, чтобы вывести список пользователей в RG:
Во втором примере выводим список пользователей и количество статей, которые прочитал каждый юзер.
Самопроверка: сколько поисков здесь, если пользователя 4?
Если у нас 4 пользователя, то выполняем 5 поисков:
- Первый поиск для вывода пользователей в RG
- Ещё по одному поиску для каждого юзера для вывода количества статей.
Вот так вот одним поиском можно заруинить производительности приложения.
→ Подписывайтесь на мой канал в Телеграме Иван Некодит.