Производительность приложений на Bubble. Заметки. Часть 17. Бэкенд: циклы и триггеры.
Данная серия статей — это мои заметки по книге The Ultimate Guide to Bubble Performance. Тут изложено только то, что фиксировал я, т.к. посчитал это важным.
Backend workflows служат для трёх целей:
- Чтобы планировать рабочие процессы, которые будут выполняться, даже если пользователь закроет приложение
- Интегрировать сервисы через API
- Запускать циклы
Бэкенд с точки зрения воспринимаемой производительности полезен, поскольку мы можем обрабатывать тысячи записей, а пользователь этого не заметит, ибо все действия будут происходить на сервере.
На бэк можем закинуть требовательные процессы, чтобы не нагружать клиентскую сторону.
Schedule workflow on a list vs recursive workflows
Если нам нужно обработать большое количество записей, то мы будем использовать 2 варианта:
- Schedule back-end workflow on a list (WOL). С помощью этого действия настраиваем воркфлоу, который будет запускаться один раз для каждой записи из переданного списка.
- Recursive workflows (RW) (Рекурсивные воркфлоу). Рекурсивные воркфлоу - это такие, которые запускают сами себя. То есть вы единожды его запустили и каждый раз на последнем шаге он будет запускать себя же, но уже с другими вводными данными.
Автор книги топит за использование RW, но нас призывает юзать то, что подходит больше нам.
Вот несколько причин, почему автор предпочитает RW:
- WOL может выбить по time out, а в то время как RW всегда завершается. Как понимаю, время обработки запроса у WOL не бесконечное. Если вдруг сервер Bubble чуть подустал, то можем нарваться на time out и процесс просто завершится, не закончив свою работу. Не очень-то надёжно получается.
- Мы не можем узнать, когда WOL завершает свою работу, но можем настроить RW таким образом, чтобы нам сообщалось о завершении обработки данных.
Например, если нам нужно обработать большой объём данных и сообщить пользователю по email, когда этот объём будет обработан, то через WOL, судя по книге, этого не сделать. А вот через RW это возможно.
Интервал для RW
Для рекурсивных процессов можно гибко настраивать интервал, с которым они будут выполняться. Скажем, если мы поставили 5 секунд и видим, что процесс работает нормально, то можно уменьшать дальше, чтобы понять, как хорошо оно работает, к примеру, при 2 секундах.
Можно использовать для гибкой настройки Option Sets (OS). Разбить процессы по типам на лёгкие, средние и тяжёлые и присвоить для каждого своё время исполнения. Затем использовать это значение при запуске RW.
Backend triggers
Это чрезвычайно мощная штука, которая поможет сделать реально быстрое приложение, поскольку триггеры реагируют на действия пользователей, но при этом не вызывают задержек на пользовательской стороне.
Для понимания всей прелести триггеров на бэке вспомним про 2 принципа:
Удаление комплексных данных
Например, нужно удалить пользователя из системы. Мы удаляем пользователя, после этого нам нужно удалить все записи, которые были с ним связаны: задачи, сообщения, проекты, заметки, контакты и т.д. Таких данных может быть очень много.
Мы можем запустить такой процесс через Schedule API workflow. Однако таким действием мы создадим вф на клиентской стороне, что опять нагрузит страницу. К тому же, прежде чем пользователь удалится, нужно будет удалить все данные, которые к нему относятся. То есть его удаление будет самым последним шагом, и он будет ещё некоторое время (секунды) виден в приложении, что сделает хуже воспринимаемую производительность.
При использовании прайваси рулс и триггеров на бэкенде мы можем создать видимость, что пользователь удаляется из системы немедленно. В то время как сервер Bubble будет обрабатывать удаление столько времени, сколько ему нужно.
Процесс удаления строится следующим образом:
- Добавляем в сущность User поле Deleted с типом yes/no
- Настраиваем прайваси таким образом, чтобы при значении yes, мы скрывали данные из всех списков.
- Создаём триггер на бэке, который будет запускать удаление после изменения значения Deleted с no на yes.
Помните про ответы на действия пользователя?
В данном случае используем тот вариант, когда отвечаем на действия пользователей мгновенно, обрабатывая при этом инфу на сервере столько времени, сколько нужно.
В следующей части продолжим тему триггеров.
→ Подписывайтесь на мой канал в Телеграме Иван Некодит.