Привет,

Javascript и Front-end в целом становятся все сложнее и сложнее. На мой взгляд, стандартная поставка Rails не отвечает современным потребностям Front-end разработчика. К тому же использование Sprockets делает ваш код очень Rails-специфичным, что затрудняет он-бординг новых разработчиков, незнакомых с Rails.

В данном видео, на примере простого React.js приложения, я покажу, как можно мигрировать со Sprockets на Browserify.

Этот подход дает следующие бонусы:

• Управление зависимостями Javascript пакетов через npm;
• Лучший туллинг и интеграция с IDE;
• Уменьшение связности фронтенда и бекенда;
• Возможность выделения фронтенда в отдельное приложение и репозиторий. Что может не являться бонусом на первый взгляд, но довольно удобно, когда вы работаете большой командой над большим приложением.

Код приложения доступен на гитхабе: https://github.com/nLight/tutorial-rails-react-browserify

Этот пост о библиотеке telegram-bot для написания ботов для Telegram. В числе основных целей при её создании были удобство разработки, отладки и тестирования ботов, сохранение интерфейсов минимальными, но с возможностью расширения, простота интеграции с Rails-приложением, и предоставление необходимых инструментов для написания бота. Вот что входит в состав:

• Легковесный клиент для API ботов.
• Базовый класс для контроллера обновлений с парсером сообщений. Сделан на основе AbstractController из ActionDispatch, предоставляет колбэки, сессии, сохранение контекста сообщений и прочее.
• Rack-middleware для продакшена, чтобы принимать update-хуки, и поллер с автоматической загрузкой обновленного кода для удобной разработки.
• Rake таски, хэлперы для рельсовых маршрутов и тестов.

Интересно? Для установки добавьте telegram-bot в Gemfile, подробности под катом.
Читать дальше →

Я только недавно познакомился с миром Rails, и как у каждого первоклассника возникает дюжина вопросов, большинство с которых у бывалого девелопера могут вызвать улыбку на лице. Написав первых три проекта у меня возник банальный вопрос хранения дополнительных конфигурационных данных в файле. То есть, при старте мы читаем данные с пользовательского конфигурационного файла, в ходе работы app можем при необходимости что-то изменить и все аккуратно сохранить в тот же файл. Читать дальше →

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутенфикацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

Понятно, что генерировать токены будет сервис отвечающий за авторизацию, но кто и как будет их проверять? В принципе можно проверку затолкать в каждый микросервис, но это противоречит идеи их максимального разделения. Каждый сервис должен будет содержать логику обработки и проверки токенов да еще и иметь доступ к redis. Нет, наш цель получить архитектуру в которой все запросы приходящие в конечные сервисы уже авторизованы и несут в себе данные о пользователе (например в каком-нибудь специальном заголовке).
Читать дальше →

Решил я недавно на примере одного проекта узнать, насколько сильно влияет на скорость загрузки сайта domain sharding. Напомню, суть этой оптимизации в том, что статические файлы грузятся с разных доменов (которые, впрочем, могут указывать на один и тот же сервер), и это позволяет обходить ограничение браузеров на количество одновременных подключений к одному домену. Интуитивно кажется, что в случае большого количества мелких файлов это должно существенно ускорить загрузку сайта в целом. Проверим, так ли это на самом деле.
Читать дальше →