В предыдущих постах был предложен новый подход к модерированию интернет-обсуждений, не требующий назначенного модератора или организации коллективного голосования и позволяющий пользователям с разных сайтов организоваться в своеобразное Сообщество модераторов. Данный подход позволит пользователям самим контролировать культуру общения онлайн, что снизит нагрузку на владельцев веб-сайтов по модерированию комментариев.



Читателям Хабра был предложен небольшой тестовый пример ленты комментариев, в котором можно было попробовать данный подход в действии.

Спасибо всем, кто принимает участие в тестировании! Уже первоначальная статистика позволяет говорить, что читатели уверенно выполняют модерацию. Сейчас пришло время двинутся дальше. В этом посте хочется обсудить простейшее возможное устройство веб-сервиса, реализующего данный подход. К сожалению, опыта для реализации такой задачи маловато, поэтому требуется совет Хабр сообщества.

Какие видятся текущие требования к веб-сервису:

• простое подключение новых сайтов к веб-сервису.
• простые базовые функции API модерирования.
• на первоначальном этапе он должен выдерживать нагрузку хотя бы 40-50
  одновременно модерирующих пользователей.
• в перспективе должен не сложно масштабироваться.

С учетом таких требований пока вырисовывается схема веб-сервиса, представленная на рисунке.



Для того, чтобы подключить свой сайт к веб-сервису владельцу сайта будет нужно:

• установить к себе на сайт js скрипт, инкапсулирующий в себя функции для работы с API.
• Добавить к полю ввода комментария атрибут moderate, на который будет ориентироваться скрипт. После этого при нажатии на поле комментария будет появляться диалог модерирования.
• Добавить к каждому комментарию в ленте атрибут moderate, на который будет ориентироваться скрипт. После этого возле каждого комментария появится кнопка, вызывающая диалог модерирования.

В процессе своей работы скрипт будет использовать следующие функции API модерации (безусловно, функций, которые должны обеспечивать функционирование Сообщества будет больше, но сейчас мы рассматриваем только базовые):

• GetAccessToken, IN: api_key.
  Запрос временного токена для текущей проверки. В таком токене, зашифрованном на серверной стороне, сохраняются все необходимые серверу данные, позволяющие серверу идентифицировать текущую проверку и отличить одну проверку от другой. Токен имеет ограниченное время жизни. Владелец сайта должен зарегистрировать на веб-сервисе уникальный api_key, который включается в токен.
  
• GetChecks, IN: token. OUT:comments_list_for_check,last_comment_check_results
  С помощью этой функции клиент запрашивает у сервиса список комментариев для проверки. Также сервер возвращает список последних, проверенных Сообществом комментариев с данного сайта, на основании которого владелец сайта может изменять статус комментариев на своем сайте.
  
• SetCheck, IN: token, comments_list_with_result, comment_for_check OUT: true/false
  С помощью этой функции клиент возвращает сервису список оцененных пользователем комментариев. Если оценки пользователя совпали с известными сервису оценками, то функция (согласно методу) возвращает клиенту true и также передает полученный от клиента комментарий comment_for_check на проверку в Сообщество.
  

В качестве веб- сервера в настоящее время планируется apache mod_php. Плюсы: работает быстро, требует минимум знаний по настройке. Как минус: скрипты выполняются от одного пользователя apache.

Функции API веб-сервиса планируется выполнить на php. Плюсы: быстрота разработки, кроссплатформенность, приемлемая производительность. Минусы: безопасность (однако, планируется использовать 7 версию, где меньше дыр)

В качестве базы воспользуемся Sphinx. Плюсы: Простая установка, скорость поиска и удобство масштабирования по сравнению с реляционными db. Минус: отсутствие join запросов, но это решается правильной структурой базы.

Пока видится, что первоначально все это можно запустить на рядовом VPS и обеспечить таким образом работу 40—50 модерирующих пользователей одновременно. Если нагрузка увеличится, то в VPS не сложно будет добавить ресурсы (память, процессора, объем дисков), а при увеличении нагрузки на DB Sphinx не сложно будет развернуть еще один экземпляр Sphinx.

Вопросы:

Какие могут быть “подводные камни” в таком варианте реализации? И какие бы Вы использовали технологии для того, чтобы реализовать простейшую версию подобного веб-сервиса?

Спасибо за внимание !