Стол сообщений социальной сети Firestore

Question

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

цель - создать новостную ленту "facebook".

каждый пользователь будет иметь список друзей, и каждый пользователь сможет создавать сообщения.

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

также пользователи могут "сохранять" понравившиеся им сообщения в новостной ленте. (Подколлекция LikedPosts)

USERS (collection)
    DocumentID - userId gathered from Authentication uid
        firstName: String
        lastName:  String
        username:  String
        birthdate: Timestamp
        accountCreationDate: Timestamp
        FRIENDS (subcollection)
            DocumentID - userId of the friend
                username:  String
        LikedPosts (subcollection)
            authorUserId:   String
            authorUsername: String
            text:  String   
            imagePath: String

POSTS (collection)
    DocumentID - postId randomly generated
        authorUserId:   String
        authorUsername: String
        text:  String   
        imagePath: String
        likesCount: Number
        forFriendsOnly:yes
        LIKES (subcollection)
            DocumentID - userID of the liker
                username:  String

теперь в ленте новостей для пользователя - Как я могу запросить все видимые сообщения (forFriendsOnly: no), а также все сообщения только для друзей, которые текущий пользователь находится в подколлекции друзей автора.

также, если пользователь меняет свое имя, как я могу соответственно изменить его имя для всех его предыдущих сообщений и всех сохраненных сообщений, относящихся к пользователю? (Находится в подколлекции likepost пользователя)

Answer 1

Не обязательно относится к вашему первоначальному вопросу, но ваша подколлекция LikedPosts, вероятно, нуждается в реструктуризации. Если вы можете гарантировать уникальность вашего postId, то это должно быть что-то вроде:

LikedPosts (subcollection)
  postId: Unique identifier for liked post
    authorUserId: String
    authorUsername: String
    text: String
    imagePath: String

Текущая структура допускает только одну понравившуюся запись, поэтому вам нужно изменить ее на один документ на понравившуюся запись или документ, содержащий список всех понравившихся идентификаторов публикации.

Answer 2

Полагаю, вы задавали 2 вопроса.

Во-первых, Firestore рекомендует дублировать данные, а не объединять запросы между коллекциями. То, как вы создали пост и пользователя, должно опираться на концепцию запросов в SQL.

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

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

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

Однако оба вышеупомянутых решения не идеальны, если вы беспокоитесь о точности, реальном времени, стоимости и т. Д. Я полагаю, что с этим недостатком мы должны столкнуться. Если вам нужно добиться того же, что и в SQL, я думаю, что единственный вариант - использовать другие решения для части запроса, такие как упругий поиск, mysql, neo4j и т. Д. PS: Вы все еще можете обернуть его облачными функциями.

Что касается вашего второго вопроса, один из способов - не дублировать имя пользователя, если вы думаете, что ваш пользователь будет часто менять свое имя. И всегда запрашивать имя пользователя по идентификатору пользователя из коллекции пользователей. Другой способ - использовать функцию триггера для обновления дублированного имени пользователя, когда пользователь меняет свои имена. Я бы порекомендовал второй способ, так как пользователь не будет часто менять свои имена.