Конструкция системы функций Firebase - Триггер облачного пожарного хранилища или триггер HTTP - PullRequest
0 голосов
/ 25 марта 2020

В настоящее время я работаю над проектом, в котором я использую возможности полнотекстового поиска Algolia вместе с моей коллекцией пользователей Firestore. Цель состоит в том, чтобы Алголия служила почти идеальным представлением моей коллекции пользователей за вычетом любой личной информации. У меня есть рабочее решение, но я не уверен, что моя реализация настолько чиста, насколько это возможно.

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

Когда пользователь регистрируется, он предоставляет свое полное имя. Затем их данные отправляются в коллекцию пользователей, где срабатывает триггер Firestore.onCreate, разделяет это fullName на firstName и lastName и обновляет документ. Затем у меня есть триггер Firestore.onUpdate, который удаляет все PII и отправляет эту версию в Algolia. Проблема (я думаю?) В том, что я теперь отправил две операции в Algolia для одного пользовательского действия, хотя мы знали, что первое действие (fullName) будет иметь второе (firstName & lastName) через несколько мгновений. (Давайте предположим, что это происходит в масштабе, а стоимость вызывает беспокойство)

Есть ли рекомендуемый способ справиться с этими типами сценариев ios: обновление имеет побочные эффекты, которые также должны отправлять обновления? Первое, что приходит на ум, - это наличие логики c в триггере onUpdate, который решает, стоит ли отправлять изменения в Algolia или нет, но быстро превращает простую операцию в мусорную. Я полагаю, что лучшим подходом было бы преобразование триггера Firestore.onChange в базовый HTTP-триггер c, который я запускаю только тогда, когда действительно хочу изменить данные, но не знаю, является ли это ошибкой из-за моего непонимания. Любое руководство по этому вопросу с благодарностью!

1 Ответ

1 голос
/ 25 марта 2020

Первое, что приходит на ум, - это наличие логики c в триггере onUpdate, который решает, стоит ли отправлять изменения в Algolia или нет, но быстро превращает простую операцию в мусорную.

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

Я думаю, что лучшим подходом было бы преобразуйте триггер Firestore.onChange в базовый HTTP-триггер c, который я запускаю, только когда мне действительно нужно изменить данные

Это также часто встречается.

То, что у вас действительно есть здесь дело предпочтения. Ни один из подходов не является правильным. Выберите тот, который наилучшим образом соответствует вашим потребностям и предпочтениям.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...