Вопросы по архитектуре для REST-сервисов социальных сетей? - PullRequest
Новая
       16

Вопросы по архитектуре для REST-сервисов социальных сетей?

2 голосов
/ 08 декабря 2010

Мне нужно интегрировать социальные сети, такие как Facebook и т. Д., Чтобы отображать элементы, которые были прочитаны, нажаты или прокомментированы друзьями пользователей. Возникают некоторые архитектурные вопросы:

вопросов: а) я должен кэшировать список друзей пользователя в моей базе данных приложения? Недостатком является то, что список пользователей друзей может измениться. Или я должен получать этот список после каждого входа в систему?

б) Когда пользователь входит в мое приложение (используя oauth), каков наилучший способ получить его / ее список друзей - я должен сделать это в ветке веб-запроса, где я делаю локаты для наша локальная база данных, или я должен создать другое задание / поток / пакетное задание для получения этого списка?

в) миниатюрные изображения пользователя: если пользователь входит в систему, должен ли я кэшировать миниатюру профиля пользователя и показывать ее из своего приложения или просто вставить URL-адрес профиля (указывающий на социальный сайт) на страницу?

1 Ответ

1 голос
/ 09 декабря 2010

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

A) Кэширование

  • Какого рода использование вашей системы вы ожидаете?Это важно, если целевой SN имеет ограничение на количество запросов, которые ваше приложение может сделать за данный период времени.Гипотетический пример: если вы собираетесь получать 100 входов в час, но SN ограничивает вас до 50 запросов в час, то вам придется кэшировать.Плохой пример, кажется, но я уверен, что вы поняли.
  • Как часто данные меняются, и сколько людей волнует, если они ошибочны?Если вы сможете получить свежий набор данных, примерно совпадающий с тем, как часто меняются друзья людей, вы будете максимально эффективны, сохраняя точность.
  • Можете ли вы запросить SN, чтобы проверить, соответствуют ли данныеизменилось до получения нового набора?
  • Если у вас возникли проблемы с производительностью, связанные с получением данных, вам следует рассмотреть возможность кэширования.

B) OAuth

Если вы можете сделать это асинхронно, то это, вероятно, неплохая идея.У вас нет контроля над целевой системой, так что вы делаете, когда дела идут плохо?Возможно, вы захотите сделать это как можно проще;Я не знаю много о работе асинхронно, за исключением использования AJAX (но это звучит так, как будто вы работаете в фоновом режиме?), Поэтому я не уверен в специфике.

C) Миниатюры

  • Проверьте политику целевого SN при обратной ссылке;если они позволяют это, тогда это вариант, в противном случае ...
  • Если SN, из которого вы извлекаете изображение, является основным, вероятно, их системы будут более доступными, чем ваша.Это предполагает, что ссылки на них не будут зависимостью, которая может ухудшить ваше приложение.В качестве альтернативы, если есть подозрение на их доступность, вы предложите согласованное приложение, сохранив все вместе.
  • Если у вашего хостинг-плана есть ограничения пропускной способности или расходы, связанные с пропускной способностью, вы сэкономите $$ с помощью ссылок;но именно поэтому ваш целевой SN может запретить его.
  • Если целевой SN решит изменить политику (и отключит ваши ссылки) - как вы узнаете?
  • Кстати, StackOverflow принимаетсвязывающий подход, но он нацелен на облачный сервис, специально созданный для этого (насколько я знаю).
...