Отправка push-уведомления об изменении поля в пожарном депо

Question

У меня есть приложение Flutter, которое позволяет пользователям арендовать предметы друг у друга с помощью Firestore RTDB. В моем документе об аренде у меня есть поле status, которое определяет статус аренды (под этим подразумевается отправка товара, где товары могут иметь статус «заказано», «отправлено», «доставлено» и т. Д.). Моя переменная status - это число от 0 до 5, и каждое число представляет отдельную фазу. Когда переменная status изменится, я хочу уведомить другого пользователя в прокате с помощью push-уведомления. Но я не знаю, какой из следующих методов лучше.

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

   exports.notify = functions.firestore.document('rentals/{rentalId}')
   .onUpdate(async (snapshot, context) => {
       const oldSnap = snapshot.before.data(); // previous document        
       const newSnap = snapshot.after.data(); // current document       
   
       // status changes from 0 to 1
       if (oldSnap.status === 0 && newSnap.status === 1) {
           // do something
       }
   })
   

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

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

   Firestore.instance
       .collection('rentals')
       .document(rentalId)
       .updateData({'status': newStatus});
   
   Firestore.instance.collection('notifications').add({
     'title': title,
     'body': body,
     'pushToken': <TOKEN HERE>,
   });
   

   По сравнению со способом 1, это делает дополнительную запись вместо чтения.

Какой метод лучше?

Answer 1

Оба подхода технически могут работать и являются действительными. Какой из них вы выберете, зависит от варианта использования и (учитывая, что оба могут работать здесь) от личных предпочтений. Вот почему я просто выделю несколько ключевых отличий ниже и объясню, когда лично я решу использовать какой.

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

Второй подход обрабатывает базу данных как очередь , где наличие данных указывает на то, что должно произойти. Таким образом, Cloud Functions затем запускает простое присутствие документа.

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

В модели данных с переходом состояния гораздо сложнее легко увидеть эту информацию. Фактически вам нужно добавить дополнительные поля в документ, чтобы иметь возможность получить этот список «ожидающих уведомлений». Например: аренда с ожидающим уведомлением - это аренда, где отметка времени, когда статус изменился с 0 на 1 (поле, которое вам нужно добавить, например, status_1_timestamp), меньше отметки времени, когда было отправлено последнее уведомление (поле, подобное notification_timestamp).

Но я иногда тоже использую подход с переходом между состояниями. Обычно, когда я хочу преобразовать существующий документ, или потому что это просто классный вариант использования для показа (как в большинстве случаев Firebase / Firestore SDK не будут выставлять как старое, так и новое состояние).

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