Я думаю, что ваша структура может быть проще, чем вы изначально разработали, и быть ближе к тому, что вы упоминаете в нижней части своего сообщения. Я также рекомендую вам прочитать http://blog.getstream.io/best-practices-for-instagram-style-feeds/, который похож на то, что вы хотите сделать здесь.
Для упрощенного пробое наших типов кормов:
- Notification каналы предназначены для создателей контента («15 человек понравился ваш пост»).
- Агрегированные корма предназначены для подписчиков («добавлено 12 сообщений»).
- Плоские каналы были бы прекрасными местами для добавления основных действий («сущности» в вашем случае?), Но вы также можете сохранить дополнительные копии этих действий в другие агрегированные и фиды уведомлений, используя поле «Кому» в модели деятельности , аналогично CC'ing по электронной почте
Любой тип подачи может следовать за плоской подачей, но мы обычно рекомендуем, чтобы только плоские подачи и агрегированные каналы соответствовали другим плоским каналам. Каналы уведомлений обычно автономны, о чем я расскажу ниже.
Давайте сделаем следующие предположения:
- Там же пользователя с правами администратора под названием «Silverthorne» с идентификатором
12
- организации ID
56 является «Acme Inc»
- Ян является постоянным пользователем с ID
74
- Silverthorne подготавливает контент Entity, который при сохранении в вашей собственной базе данных имеет идентификатор
63
Давайте создадим плоский канал под названием org, где будет объектная деятельность, и агрегированный канал называется org_aggregated для агрегированных данных, питающее уведомление называется notifications, плоский канал для пользователей называется timeline. Если ваши пользователи могли видеть фид всего, созданного другим пользователем (а не организацией), я бы рекомендовал другой плоский канал под названием usercontent.
Для Силверторна размещать эту деятельность GetStream, деятельность актер будет "user:12", глагол может быть "post", объект будет "entity:63"
Для pseduocode это, так как я не знаю, какой SDK вы используя, было бы что-то вроде:
# acme inc gets created as an organization, and so its aggregated feed
# should follow the org's flat feed
acme_org_feed = getstreamClient->feed('org', '56')
acme_org_agg_feed = getstreamClient->feed('org_aggregated', '56')
acme_org_agg_feed->follow(acme_org_feed)
на данный момент, каждый объект, который добавляется к org плоской подачи Acme будет также получить агрегированные. Вы можете установить, как они будут свернуты на панели инструментов GetStream.
Теперь давайте Ян следовать Acme:
# ian is a member of Acme Inc, so follow their entity feed
ian_feed = getstreamClient->feed('timeline', '74')
ian_feed->follow(acme_org_feed)
Если Ян новая регистрация, вы можете отправить активность на подачу уведомлений Acme как это:
acme_notif_feed = getstreamClient->feed('org_notification', '56')
acme_notif_feed->addActivity({
'actor': 'user:74',
'verb': 'registration',
'object': 'user:74'
})
При получении этого уведомления позже, он сгруппирует все глаголы вместе, а затем разбивает действия уведомления, поэтому ваш пользовательский интерфейс может сообщить об этом по-разному, если вы выберете.
Теперь давайте Silverthorne добавить, что Entity к GetStream: # Силверторн добавляет активности на Acme Инк объекта подачи # мы будем «куб.см» активность в агрегированном корма acme_org_feed-> AddActivity ({ «актер» : 'user: 12', 'verb': 'post', 'объект': 'entity: 63', 'to': ['usercontent: 12'], ...любые другие метаданные вы хотите отслеживать })
При этом сохраняется, вот что GetStream бы:
- он сохраняет активность в
org плоской корма для Acme (org:56)
- экономит копия на шкале времени Яна, так как
user:74 следует за плоской подачей для org:56
- он также сохраняет копию в фидер Silverthorne (
usercontent:12) из поля «Кому»; это совершенно не обязательно
- он сохраняет копию в агрегированный корм для Acme (
org_aggregated:56), так как агрегированный корм следует плоскому каналу
Когда Ян входит в системе, приложение теперь имеет несколько возможных каналов и варианты, чтобы показать , и это полностью зависит от вашего приложения:
- если Ян должен увидеть хронологию все, что следует, вы бы принести
timeline:74 корм, который будет иметь копию Entity # 63
- если Ян должен см. список всех его организаций, вы можете получить
ian_feed->followed(), чтобы получить список всех кормов, что Ян следует
- для каждого из тех, кто кормит Ян следующим образом, вы могли бы принести агрегированный канал, который ORG для Ян, чтобы увидеть резюме (то есть, принесите
org_aggregated:56 и Ян мог видеть one new entity added in the past day, если это как вы агрегировать контент)
ключевым моментом здесь является то, что Ян не имеют следовать фид, чтобы увидеть содержание, ваше приложение может потянуть любой канал, чтобы отобразить любому пользователю.
Если Ian должен был «поделиться» или «понравиться» этому сущности, которую отправил Silverthorne, вы добавили бы новую активность в фид «org_notification: 56» с «пользователем: 74» в качестве Актера »: entity: 63 '- это объект, а глагол - любая строка, которую вы хотите (до 20 символов). Если вы хотите, чтобы ваше приложение увидело, как другие пользователи взаимодействуют с сообщениями организации, вы можете получить org_notification:56, и все пользователи могут увидеть «любимый объект Ian 63» или, тем не менее, ваш пользовательский интерфейс должен представить это.
Надеюсь, что поможет прояснить ситуацию и дать вам дополнительные сведения. Свяжитесь с нашей службой поддержки по электронной почте, если вы хотите получить дополнительную помощь или идеи.
Как последнее замечание, я не думаю, что сделаю $userId-$orgId ... некоторые из наших SDK (т. Е. Rails и Django) будут автоматически пытаться «обогатить» эти значения в вашей базе данных, так что вы нужна дополнительная логика, чтобы попытаться разделить эти значения позже. Мы рекомендуем использовать UUID для идентификатора без конфликтов, но это полностью зависит от вас. Если пользователь действительно может быть частью нескольких организаций, вы можете просто заставить этого пользователя «следить» за кормом организации.