В процессе превращения большей части web-проектов в браузерные приложения, появляется много вопросов. И один из самых весомых из них – обработка прав доступа без лишнего кода. Размышления на эту тему привели нас к большой проблеме: комфортного способа реализовать защиту на уровне полей модели для ActiveRecord просто нет (
Егор, привет! ;). CanCan добавляет ограничения на уровне контроллеров, но это слишком высокий уровень чтобы решить все проблемы.
Немножко пободавшись, мы написали два милых гема. Встречайте,
Heimdallr (Хеймдаль) и его расширение
Heimdallr::Resource. Они принесут в ваши модели мир и безопасность.
С развитием браузерных MVC-фреймворков, Rails очень часто стали упоминать в контексте удобного фреймворка для REST-провайдеров. Мы тоже используем Rails для этой цели и достаточно долго. Есть, однако, очень большая проблема: представления. Вьюшки, которые описывают структуру JSON для ответа.
На первый взгляд, все просто отлично. Ничего кроме
.to_json или
RABL, в некоторых сложных случаях, не требуется. Но затем ситуация выходи из под контроля. И идут бесконечные циклы перебора JSON-билдеров в поисках лучшей жизни.
Проблема
Давайте возьмем для примера банковский сервис. Он состоит из 30 моделей. Каждая модель представлена CRUD-реурсом (в каждом по 3-4 расширяющих метода). В каждой модели 10-12 полей и это обычно длинные строки. И, конечно, все они связаны. Вплоть до 4-5 уровней
belongs_to.
При этом важно помнить, что в реальной жизни JSON ответа – это не просто прямой дамп структуры модели. В нем постоянно встречаются условия (какой атрибут должен попасть в ответ? Зависит от другого атрибута) и кастомные методы.
Проблема представлений заключается в том, что клиенту REST-сервиса нужен уникальный набор полей модели для каждой такой модели и _для каждого метода_ этого REST-ресурса. И не забудьте про вложенные сущности.
Вместе с разработкой
Joosy, AJAX внезапно – но ожидаемо, – заполонил все проекты, за которые мы беремся. Парадигма оказалась крайне удачной во всех аспектах, кроме одного. Того самого классического: «AJAX? Индексация? Пфф...». Пока мы делаем интернет-банки, это нас вполне устраивает. Но как не отказывать себе в этом изысканном удовольствии для открытых Web-ресурсов?
А вот как:
Google AJAX Crawling – это стандарт Google, который позволяет при формировании AJAX-адресов специальным образом (#!) заставить Google магически запрашивать вместо него другой магический адрес. С которого Google будет ждать HTML-дамп этой страницы, который он весело прожует. Добрые люди уже написали
статью про то как это работает. Ну а нам остается научиться эффективно этот дамп формировать. Да так, чтоб без вмешательства в код самого приложения.
Вступление в охоту
Мы верим, что за Open-Source будущее, и стараемся всячески его
приближать. И мы предлагаем вам присоединиться.
Если взглянуть на Open-Source на западе, то за стройными колоннами технологий, которые все мы знаем и любим, будут проглядывать головы коммерческих компаний. Создавая что-то, вы облегчаете жизнь не только коллегам, но и нам. Мы экономим время (а значит деньги) и создаем прекрасное с использованием вашего труда. Мы обязаны уважать это и помогать всем, чем только можем. Мы присоединяемся к нашим западным коллегам и предлагаем гранты для открытых проектов.
С Марта 2012 года мы открываем две программы:
- Программа спонсирования OSS-проектов
- Проект “Охота на Open-Source”
Программа спонсирования существующих проектов будет анонсирована отдельно, а сегодня мы хотим предложить вам поучаствовать в нашей охоте.
Механизм ассетов в 3.1 сильно упростил жизнь большим проектам, но при этом немножко усложнил маленьким. При использовании встроенных генераторов, рельсы как и прежде создают отдельный файл для каждого контроллера, вот только теперь содержимое этих файлов появляется по-умолчанию на абсолютно всех страницах. Если в случае с SCSS это только помогает, навязывая правильное структурирование, то что делать с JS?
Если проект большой и вы используете для массивного JS какой-нибудь клиентский фреймворк вроде Backbone – отлично! Он будет лучше загружаться и сам решит где и как ему работать. Но что если нужно всего-лишь подключать небольшое количество кода для конкретных страниц? То есть даже не controller'ов, а скорее action'ов. И желательно чтобы когда таких кусочков стало больше 5 код не превратился в спагетти. С этим может помочь маленьий гем
Styx.
Поддержка SOAP (как сервера) в Rails ухудшалась от версии к версии. В версии 1.x рельсы комплектовались
AWS. В версии 2.x AWS распался на несколько форков, которые поддерживали энтузиасты. До версии 3.х, в стабильно работающем исполнении, AWS не дожил. Идеологически подобное отношение к SOAP может нравиться или не нравиться, но в реальной жизни мы окружены великим и ужасным Enterpris'ом. И поддержка двустороннего SOAP'а может понадобиться в любой интеграции: от 1С, до автоматизированных банковских систем.
Вместо поддержки еще большего количества (мертворожденных?) форков AWS для 3-ей версии, мы написали
WashOut.