Дублирование данных Firestore с использованием облачных функций - PullRequest
0 голосов
/ 15 апреля 2020

Я создаю мобильное приложение, используя React-Native. Firestore используется в качестве серверной базы данных, а облачные функции Google используются для запуска дублирования данных между пользователями.

Мне нужны ваши советы относительно наилучшего способа реализации бизнес-логики c (ниже) с точки зрения «структуры базы данных» и «потока данных». Я предложил определенный подход ниже. Буду очень признателен за ваше мнение. Если вы «согласны» с моим подходом, пожалуйста, укажите это в комментарии. Если у вас есть «альтернативный подход», пожалуйста, дайте мне знать в ответе на этот вопрос.

Business Logi c:

User-A «предлагает» список из 5 контактов (Пользователь-1, Пользователь-2, Пользователь-3, Пользователь-4 и Пользователь-5), чтобы присоединиться к нему в игре. Ему (User-A) нужно играть только с 2 пользователями. Некоторые или все 5 контактов могут «принять» приглашение. Допустим, 3 из них принимают приглашение к игре (Пользователь-1, Пользователь-2 и Пользователь-3). Пользователь-А должен «подтвердить» двум из них, что он будет играть с ними. Допустим, он подтвердил (Пользователь-1 и Пользователь-2), что он будет играть с ними.

Примечание: в примерах (ниже) кажется, что одни пользователи могут быть приглашены только для игры, в то время как другие могут только приглашать других. Это не вариант. В реальном приложении любой пользователь может пригласить любого другого пользователя. Демонстрация этого в примере ниже сделала бы это очень сложным! Более того, в реальной жизни имена двух полей (Status-A) и (Status-B) ниже будут одинаковыми (Status). Я использовал разные имена ниже, чтобы мне было проще объяснить поток данных.

Рабочая нагрузка:

Это приложение для запуска. В случае успеха рабочая нагрузка может достичь следующих значений (через несколько месяцев или лет): 1. Количество ПОЛЬЗОВАТЕЛЕЙ может быть 100 000 2. Количество ИГР для каждого ПОЛЬЗОВАТЕЛЯ может быть 1000 3. Количество КОНТАКТОВ для каждой ИГРЫ может быть 1 000 4. Количество приглашений (транзакций), отправленных разными пользователями, может быть 100 одновременно

Структура базы данных:

  1. A Коллекция для пользователей. Каждый пользователь представлен документом, например «Пользователь-А». В этом документе есть подколлекция для «ИГР», в которую он хочет сыграть. Подколлекция «ИГРЫ» имеет документы, по одному на каждую игру, например «Игра-1». В каждой игре есть подборка для контактов, которые были приглашены играть, т.е. «КОНТАКТЫ-приглашены». Каждый документ в этой коллекции представляет собой приглашенный контакт. Каждый документ имеет поле «Статус-А» для хранения статуса приглашения (приглашение, принять или подтвердить), например, Пользователь-1: {Статус-А: Подтвердить}. Пожалуйста, посмотрите графическое (более или менее) представление структуры данных ниже.
  > Document: User-A
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-invited
          > Document: User-1 {Status-A: Confirm}
          > Document: User-2 {Status-A: Confirm}
          > Document: User-3 {Status-A: accept}
          > Document: User-4 {Status-A: invite} 
          > Document: User-5 {Status-A: invite}
      > Document: Game-2 
        > SUBCOLLECTION: CONTACTS-invited
          > Document: User-2 {Status-A: invite}
          > Document: User-7 {Status-A: Confirm}
          > Document: User-9 {Status-A: accept}
Как и выше, когда контакт получает приглашение, соответствующая информация сохраняется в структуре, аналогичной приведенной выше. Однако подколлекция для полученных приглашений называется «ПРИГЛАШЕНИЕ КОНТАКТОВ» ниже, а не «Приглашение КОНТАКТОВ» выше. Я буду называть структуру данных ниже «зеркальными данными». Пожалуйста, посмотрите графическое (более или менее) представление зеркальных данных ниже.
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: Confirm}
      > Document: Game-2 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: invite}
      > Document: Game-3 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-B {Status-B: accept}

  > Document: User-2
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: Confirm}
      > Document: Game-3 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-B {Status-B: confirm}

  > Document: User-3
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: accept}

  > Document: User-4
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: invite}

  > Document: User-5
    > SUBCOLLECTION: GAMES 
      > Document: Game-1 
        > SUBCOLLECTION: CONTACTS-INVITING
          > Document: User-A {Status-B: invite}

Поток данных / Процессы:

  1. Когда «Пользователь-А» отправляет приглашение (нажав на кнопку на экране) подколлекция «ИГРА-1» и все ее дочерние элементы (как показано выше) создаются с использованием кода Firestore, который является частью мобильного приложения (код клиента). Эта вложенная коллекция является дочерней по отношению к документу этого пользователя (Пользователь-A).

  2. Облачная функция Google создает «зеркальные данные», которые представляют собой вложенную коллекцию для приглашенного пользователя, например «Пользователь-1». Я не уверен, должна ли эта функция запускаться автоматически (на основании изменений данных в документах во вложенной коллекции КОНТАКТЫ-ПРИГЛАШЕНИЯ) или вручную с помощью клиентского кода!

  3. Когда приглашенный пользователь, например «Пользователь-1» принимает приглашение (нажав на кнопку на экране), статус (Status-B) обновляется - с «пригласить» до «принять». Это делается с помощью кода, который является частью мобильного приложения (код клиента).

  4. Облачная функция Google обновляет статус (Status-A) для приглашающего пользователя, например, «User-A». Я не уверен, должна ли эта функция запускаться автоматически (на основании изменений данных в документах во вложенной коллекции КОНТАКТЫ-ПРИГЛАШЕНИЯ) или вручную с помощью клиентского кода!

  5. Когда «Пользователь-А» «подтверждает», будут выполнены шаги, аналогичные (1 и 2 выше).

Примечание:

Это упрощенная версия бизнес-логики c. Бизнес-логика c мобильного приложения не имеет ничего общего с играми! Более того, слово «он» (выше) должно читаться как «он / она», а слово «его» должно читаться как «его / ее» и т. Д. c.

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