Использование правил для защиты определенных пар ключ = val в качестве публичной или частной VS, имеющих отдельные публичные и приватные пути

Question

Я пытаюсь определить, как мне организовать некоторые пользовательские данные, которые могут быть как публичными, так и частными. Рассматриваемые сущности являются событиями Stream Stream. Подписчики пользователя могут видеть свои события Activity Stream - однако пользователь может пометить определенные категории событий как «публичные» или «частные» и поэтому не делиться ими со своими подписчиками.

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

"rules": {
    "activity_streams_settings": {
        "$userID": {
            "read": "auth.uid == $userID",
            "write": "auth.uid == $userID"
        }
    },
    "activity_streams_private": {
        // Users only write Activity Stream events here.
        "$userID": {
            "read": "auth.uid == $userID",
            "write": "auth.uid == $userID"
        }
    },
    "activity_streams_public": {
        "$userID": {
            // Every user can read public activity stream data
            "read": "auth.uid != null",

            // Only Cloud Functions can update what appears in
            // a user's public activity stream by determining
            // if an activity added to activity_streams_private
            // is public or private using the
            // activity_stream_settings data. Every settings
            // change would cause the Cloud Function to read
            // this entire subtree of data and write/delete a lot.
            "write": false,
        }
    }
}

В качестве альтернативы, вы можете хранить все публичные и частные события Activity Stream пользователя в пути, подобном activity_streams, а затем иметь правила безопасности на основе запросов, которые позволяют подписчику запрашивать события Activity Stream только с помощью свойства public=true. Для этого по-прежнему требуется, чтобы пользовательское устройство (или облачная функция) обновляло все элементы в activity_streams, чтобы включать / исключать свойство public=true при каждом изменении параметра конфиденциальности.

"rules": {
    "activity_streams_settings": {
        "$userID": {
            "read": "auth.uid == $userID",
            "write": "auth.uid == $userID"
        }
    },
    "activity_streams": {
        "$userID": {
            // Only children with the 'visibility=public' property
            // can be read (or the owner of the activity stream).
            // This method will mean that the ID of each Activity
            // Stream event will be in the form of:
            // timestampDescending_eventUUID so that the events
            // are automatically sorted by newest first.
            "read": "auth.uid == $userID || (auth.uid != null && query.orderBy = 'visibility' && query.equalTo = 'public')",

            // Users can append Activity Stream events with a
            // preset visibility property (public or private)
            // but a Cloud Function will change the visibility
            // property on events if a user changes their settings.
            "write": "auth.uid == $userID",
        }
    }
}

Наверное, я спрашиваю, каковы недостатки и преимущества каждого метода. Замедляют ли правила безопасности на основе запросов скорость чтения? Является ли любое решение более масштабируемым по мере роста пользовательской базы? В течение короткого ~ 5-минутного сеанса пользователь генерирует от 25 до 75 событий потока активности.

Мое беспокойство по поводу выполнения activity_streams_public заключается в том, что записи могут вызвать проблемы с масштабируемостью у пользователей ~ 1M даже при нечастых изменениях настроек конфиденциальности. Мысли?