Я создаю мобильное приложение, используя 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 одновременно
Структура базы данных:
- 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» и все ее дочерние элементы (как показано выше) создаются с использованием кода Firestore, который является частью мобильного приложения (код клиента). Эта вложенная коллекция является дочерней по отношению к документу этого пользователя (Пользователь-A).
Облачная функция Google создает «зеркальные данные», которые представляют собой вложенную коллекцию для приглашенного пользователя, например «Пользователь-1». Я не уверен, должна ли эта функция запускаться автоматически (на основании изменений данных в документах во вложенной коллекции КОНТАКТЫ-ПРИГЛАШЕНИЯ) или вручную с помощью клиентского кода!
Когда приглашенный пользователь, например «Пользователь-1» принимает приглашение (нажав на кнопку на экране), статус (Status-B) обновляется - с «пригласить» до «принять». Это делается с помощью кода, который является частью мобильного приложения (код клиента).
Облачная функция Google обновляет статус (Status-A) для приглашающего пользователя, например, «User-A». Я не уверен, должна ли эта функция запускаться автоматически (на основании изменений данных в документах во вложенной коллекции КОНТАКТЫ-ПРИГЛАШЕНИЯ) или вручную с помощью клиентского кода!
Когда «Пользователь-А» «подтверждает», будут выполнены шаги, аналогичные (1 и 2 выше).
Примечание:
Это упрощенная версия бизнес-логики c. Бизнес-логика c мобильного приложения не имеет ничего общего с играми! Более того, слово «он» (выше) должно читаться как «он / она», а слово «его» должно читаться как «его / ее» и т. Д. c.