В настоящее время я создаю своего рода приложение для социальных сетей, и, как и любое приложение для социальных сетей, очень важно отображать какую-то информацию от друзей.
Я пробовал различные способы показывать пользователям сообщения, опубликованные их друзьями, но это может быть медленным, и я сомневаюсь, что это самый эффективный способ.
Сначала я структурировал свою базу данных следующим образом:
пользователи -> (uid) -> друзья (массив uid) сообщения (массив идентификаторов сообщений) Дополнительная информация...
сообщений -> (идентификатор сообщения) -> image_url Дополнительная информация...
С этой настройкой я: 1. Я взял текущий uid вошедшего в систему пользователя и получил документ, который принадлежит этому пользователю в разделе «Пользователи».
Затем я получил список друзей пользователей в виде массива и просмотрел их.
Затем для каждого uid я снова запросил "пользователей" и нашел документ принадлежащий этому пользователю.
Затем я взял первый "идентификатор сообщения" в их массиве "сообщений", если он был
Я взял идентификатор сообщения, нашел соответствующий пост в коллекции "сообщений" и скачал его.
Повторяйте шаги 3–5 для каждого идентификатора пользователя, пока не закончится публикация сообщений или пока я не загрузу 10 из них.
Это был мой первый подход, однако с ним есть несколько проблем, которые я могу определить, и, скорее всего, еще несколько, о которых я еще не подумал.
На шагах 2 и 4. На этих двух шагах я загружаю весь массив из-за того, что firestore не позволит вам загрузить определенный индекс в массиве. Это замедляет процесс, изображение, если есть где
Допустим, пользователь прокручивает страницу вниз, чтобы обновить новые сообщения, тогда было бы трудно загрузить больше сообщений, потому что даже если я начну скачивать с того места, откуда я ушел, за это время может быть добавлено еще одно сообщение, что выбрасывает всю систему.
Я также экспериментирую с просто прикрепленными к каждому пользователю коллекционными сообщениями с почтовыми документами.
Есть другие идеи?
Если я правильно понимаю вашу проблему, вы пытаетесь облегчить joins
между user
и posts
(т.е. вы хотите, чтобы все posts
, которые user
мог видеть, упорядочены по времени или релевантности). Я бы предложил создать функцию Firebase, которая записывает запись в коллекцию каналов пользователей, когда один из их друзей создает сообщение. Запись будет содержать Reference
для публикации и необходимую информацию для ранжирования / упорядочивания публикации. Затем вы можете просто сделать два запроса (первый относительно быстрый и доступный для страниц), чтобы облегчить пользователю доступ к каналу. Если у пользователя появляется новый друг, у него просто есть еще одна функция Firebase, чтобы вытащить несколько недавних (вероятно, не с самого начала) сообщений от этого друга.
единственная проблема с этим заключается в том, что это может занять несколько запросов на сервере функций, изображение у кого-то есть 100 последователей, вам нужно будет запросить каждого друга, а затем вставить ссылку
Как я уже сказал, вы пытаетесь выполнить joins
(что невозможно при использовании Firestore); так что в любом случае он не будет хорошо масштабироваться. Итак, вы должны ответить на следующие вопросы: хочу ли я, чтобы пользователь видел дорогостоящую часть, и хочу ли я проявлять инициативу в отношении работы, которую необходимо выполнить. С вашим текущим решением вам придется повторять дорогостоящую часть при каждом чтении. С помощью этого решения вы делаете это один раз, и пользователь не видит дорогостоящего выполнения.
Хорошо, спасибо за ваше предложение, я попробую
извините, я только что заметил одну проблему с этим решением. Не то чтобы я выглядел дерзко или что-то в этом роде, и я понимаю, что мое приложение, скорее всего, никогда не доживет до того дня, когда оно достигнет миллионов пользователей. Однако в маловероятном случае, если там, где человек, скажем, с 1 миллионом «подписчиков», не будет писать в пользовательский канал неэффективно для 1 сообщения, это будет означать, что вам придется сделать это миллион раз.
Да, это дорого, но, как бы то ни было, вы пытаетесь позволить это дорого обходиться. Вот статья о том, как Facebook и Twitter используют разветвленное чтение и запись: ссылка на сайт. Надеюсь, поможет.
Большое спасибо
есть ли другие решения?