Склонировать репозиторий:
git clone git@github.com:AlekseyRykov/nanoservice.git
Используя bundler установить все зависимости:
bundle install
Запустить миграцию:
rake db:migrate
Запустить redis:
- Под windows - https://github.com/ServiceStack/redis-windows
redis-server.exe redis.windows.conf
- Под linux - https://redis.io/topics/quickstart
redis-server
Запустить rails в режиме development:
bundle exec rails s
Запустить sidekiq:
bundle exec sidekiq
Пройти по адресу:
http://localhost:3000
Аутентификация:
gem 'devise'
Для работы с очередями использовался Active Job, а в качестве бэкенд адаптера:
gem 'sidekiq'
По моему мнению Active Job ограничивает функционал sidekiq в плане настроек повторной отправки или отмены неудачных заданий. Но дает преимущества в быстром переключении между адаптерами. Sidekiq был выбран на основе популярности среди сообщества и рекомендаций от разработчиков rails.
Весь ход работы над проектом отражен в коммитах, в самом коде добавлены комментарии.
Представим, что наш сайт является новостным агрегатором или блогом, где пользователи могут наряду с администрацией создавать посты на разные тематики. После публикации поста происходит отправка сообщения в каналы мессенджеров с информацией о новом посте. Сообщение содержит заголовок с ссылкой, урезанное тело поста и автора.
Примечание:
Большая часть функционала (к примеру, разделение администраторов и пользователей) ограничена/упрощена и сделана для демонстрации процесса отправки сообщений.
После первого захода на сайт необходимо зарегистрироваться Sign up и войти под зарегистрированным пользователем. Для аутентификации используется Devise. Был расширен функционал, поле username и индекс username, для вывода имени автора и переменная verification со значение false по умолчанию, т.к. предполагаем, что посты новых пользователей сайта должны пройти первичную модерацию. Т.е. пользователи увидят пост на сайте и сообщения в мессенджерах только после проверки. После одобрения контента администрация меняет значение аккаунта verification на true. Последующие посты верифицированного пользователя будут сразу публиковаться на сайте и сообщения будут рассылаться в мессенджеры.
Примечание:
Как упоминалось выше, модерация носит демонстрационный характер и после регистрации появляется статус верификации
Verification: false. Перейдя по ссылкеVerificationможно изменять статус сколько угодно раз и проверить то, как происходит отправка сообщений. После публикации поста, в данном случае он публикуется сразу же в нашем блоге/новостном агрегаторе.
Далее на главной странице Main page (вынесена в шапку) необходимо создать новый пост New article. Ввести имя заголовка Title, текст статьи Description, по умолчанию включена доставка с помощью checkboxes во все мессенджеры Hipchat, Slack, Telegram.
Доставка в мессенджеры производится только если аккаунт пользователя имеет статус Verification: true. Если мы хотим отправить сообщение о новом посте только в определенные мессенджеры, то необходимо снять выбор с ненужных.
Эмуляция доставки сообщений в мессенджеры происходит на странице Messengers (вынесена в шапку). В итоге можно увидеть разное количество постов в каналах, если при создании таковых сделать рассылку в разные мессенджеры с помощью checkboxes.
Добавлена валидация на уровне модели article.rb для Title и Description, поля не могут быть пустыми. Т.е на этапе публикации делаем проверку, далее при отправке сообщения в мессенджеры проведем повторную валидацию.
В \nanoservice\app\views\articles\_form.html.erb реализована форма, классифицирующая отправку поста в нужные нам мессенджеры.
Добавлен метод колбэка на уровне модели article.rb. После внесения поста в базу данных происходит передача идентификатора поста в
созданную задачу \nanoservice\app\jobs\send_messages_job.rb и задача помещается в очередь, задача будет выполнена, как только освободится система очередей, т.е. отправка сообщений не будет мешать входящим запросам. Можно реализовать отправку по более точному расписанию, к примеру раз в 10 минут SendMessagesJob.set(wait: 10.minute).perform_later(article_id).
Изначально рассматривал выполнение заданий по расписанию с помощью gem 'whenever', но решил использовать имеющийся планировщик Active Job.
Также реализован WEB UI http://localhost:3000/sidekiq/ с помощью которого мы можем работать с задачами.
Переходим к выполнению самой задачи \nanoservice\app\jobs\send_messages_job.rb
Комментарии в коде дадут более детальную информацию.
- Сервис понимает, что запрос приходит от верифицированного или неверифицированного отправителя;
- Обязательные поля
TitleиDescriptionпроходят дополнительную валидацию и при ошибке отправляют сообщение в лог, через который их можно отследить; - Сервис умеет классифицировать запросы по типу мессенджера;
- Сервис имеет возможность отправки одного сообщения нескольким получателям на несколько мессенджеров в рамках одного входящего запроса;
- Сервис учитывает вероятность неудачных попыток доставки сообщений конечному получателю - иногда наши задачи будут давать сбой, но active job и sidekiq обладают функционалом по отлову исключений, которые будут помещаться повторно в очередь, в общей сложности будет 25 повторений на протяжении 21 дня. Этого времени достаточно для того, чтобы с
http://localhost:3000/sidekiq/отловить ошибку и пофиксить ее и далее повторить или удалить задачу. Так же мы ввели кастомные сообщения с уведомлениями о провальной валидации заголовка или тела сообщения и проверку верификации пользователя, которые можно отслеживать через лог sidekiq.
Также мы реализовали проверку доставки сообщений после выполнения задачи. Код нуждается в рефакторинге, т.к. слишком сложный и повторяющийся. На странице созданного поста, к примеру, http://localhost:3000/articles/1 можно увидеть, что в тот или иной чат сообщение доставлено delivered, отправка в чат пропущена skipped или сообщение не доставлено not delivered, по каким-то причинам, которые можно будет отследить через логи.