Рельсы и магистраль работают вместе

Ответ 1

Прежде всего я хотел бы взглянуть на книгу Backbone.js on Rails, которая является отличной отправной точкой, хотя и нацелена на промежуточной и продвинутой аудитории. Я купил эту книгу, уже работая с рельсами, но в качестве базового новичков backbone.js, и она мне очень понравилась.

Помимо этого, есть некоторые фундаментальные проблемы с объединением этих структур, которые выходят за рамки деталей, описанных в этой книге и других книгах. Ниже приведены некоторые вещи, которые я предлагаю вам подумать, исходя из моего собственного опыта, связанного с RoR и backbone.js. Это длинный ответ и немного отличается от специфики вашего вопроса, но я надеюсь, что это может помочь вам понять "большую картину" понимания проблемы, с которой вы сталкиваетесь.

Rails: веб-Framework vs API

Первое, с чем вам приходится столкнуться при использовании backbone.js поверх приложения rails, - это то, что нужно делать с представлениями, но это на самом деле просто поверхность гораздо более глубокой проблемы. Проблема заключается в том, что означает создание веб-службы RESTful.

Rails настроен из коробки, чтобы побудить своих пользователей создавать сервисы RESTful, структурируя маршрутизацию с точки зрения набора ресурсов, доступных в унифицированных URI (определенных в вашем файле routes.rb) с помощью стандартных действий HTTP. Поэтому, если у вас есть модель Post, вы можете:

• Получить все сообщения, отправив GET запрос на /posts
• Создайте новое сообщение, отправив запрос GET на /posts/new, заполнив форму и отправив ее (запрос Post) на /posts
• Обновите сообщение с id 123, отправив запрос GET на /posts/123/edit, заполнив форму и отправив ее (запрос PUT) на posts/123
• Уничтожьте сообщение с id 123, отправив запрос DELETE на /posts/123

Ключевым моментом, который следует помнить об этом аспекте Rails, является то, что он принципиально без гражданства: независимо от того, что я делал ранее, я могу создать новый Post, просто отправив запрос Post с действительными данными формы правильный URI, скажем /posts. Конечно, есть предостережения: мне может потребоваться войти в систему (иметь идентификатор сеанса cookie, который идентифицирует меня), но по существу Rails действительно не заботится о том, что я делал, прежде чем отправил этот запрос. Я мог бы следить за ним, обновляя другое сообщение или отправляя действительное действие на любые другие ресурсы, доступные мне.

Этот аспект создания Rails упрощает превращение веб-приложения Rails в Javascript-light в API: ресурсы будут похожи или одинаковы, веб-фреймворк возвращает HTML-страницы, в то время как API (обычно) возвращает данные в формате JSON или XML.

Backbone.js: новый слой с состоянием

Магистраль также основана на ресурсах RESTful. Всякий раз, когда вы создаете, обновляете или уничтожаете модель backbone.js, вы делаете это посредством стандартных HTTP-действий, отправленных в URI, которые предполагают архитектуру RESTful, описанную выше. Это делает его идеальным для интеграции с сервисами RESTful, такими как RoR.

Но здесь следует подчеркнуть тонкую точку: backbone.js легко интегрируется с Rails как API. То есть, если вы отмените представления HTML и просто используйте Rails для обслуживания ресурсов RESTful, интегрируясь с базой данных, выполняя управление сеансом и т.д., Тогда он очень хорошо интегрируется со структурой, которую backbone.js предоставляет для клиентской стороны код. Многие люди утверждают, что нет ничего плохого в использовании рельсов таким образом, и я думаю, что во многих отношениях они правы.

Сложности возникают из-за вопроса о том, что делать с той частью Rails, которую мы только что выбросили: представления и то, что они представляют.

Люди с государственным статусом, машины без гражданства

Это действительно более важно, чем может показаться на первый взгляд. Представления HTML представляют собой интерфейс без состояния, который люди используют для доступа к ресурсам RESTful, предоставляемым вашим сервисом. Уход с ними оставляет вас с двумя точками доступа:

• Для людей: богатый клиентский интерфейс, предоставляемый слоем backbone.js(stateful)
• Для машин: ресурсо-ориентированный API RESTful, предоставляемый слоем рельсов (безстоящий)

Обратите внимание, что для людей уже нет интерфейса без гражданства (RESTful). Напротив, в традиционном приложении rails с API нам было что-то ближе к этому:

• Ресурсы HTML для людей (без гражданства)
• Ресурсы JSON/XML (API) для машин (безстоящие)

Последние два интерфейса для доступа к ресурсам гораздо ближе по своей природе друг к другу, чем предыдущие два. Просто подумайте, например, о рельсах respond_with, в котором используется сходство для обертывания различных респондентов RESTful в унифицированном методе.

Совместная работа

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

• Создайте веб-сервис с богатым опытом на стороне клиента, используя backbone.js, с рельсами в качестве сторонних сервисов в формате JSON.
• Используйте pushState, чтобы дать каждой странице в приложении URL-адрес (например, /posts/123), к которому можно получить доступ напрямую (путем ввода его в панель браузера).
• Для каждого из этих URL-адресов также служит страница HTML для клиентов без javascript.

Это не необычные требования к современному веб-сервису, но они создают сложную задачу. Короче говоря, теперь вам нужно создать два "ориентированных на человека" слоев:

• Пользовательский клиентский интерфейс (шаблоны и представления backbone.js)
• Неактивные HTML-ресурсы (Rails HTML-представления)

Сложность фактического выполнения этого приводит многих к тому, чтобы отказаться от последнего из этих двух и просто предложить богатый клиентский интерфейс. То, что вы решите сделать, зависит от ваших целей и того, чего вы хотите достичь, но стоит тщательно обдумать эту проблему.

В качестве еще одной возможной ссылки для этого, я бы предложил взглянуть на O'Reilly RESTful Web Services. Может показаться странным рекомендовать книгу о REST в вопросе о Rails и Backbone.js, но на самом деле я думаю, что это ключевая часть, которая подходит для этих очень разных фреймворков, и понимание ее более полно поможет вам воспользоваться преимуществами сильные стороны обоих.

Ответ 2

Да, вы можете использовать обе бок о бок. Магистраль предназначена для хранения и обработки данных в клиентском браузере. Обычно требуется сервер для обмена данными от. Здесь появляется Rails. У вас может быть веб-приложение без тяжелого клиентского кода. Магистраль предназначена для создания сайтов, которые больше похожи на приложения - подумайте о Gmail или Pandora.

Я советую сначала изучить Rails. После того, как вы можете получить статические страницы загрузки и стиль, как вы хотите, то понимание Backbone место будет иметь больше смысла

Ответ 3

Я использовал рельсы в качестве серверного сервера для работы на довольно большом веб-сайте, который включал несколько одностраничных приложений (встроенных в магистраль).

Я бы предложил камень backbone-on-rails. Идея заключается в том, что ваш сервер rails будет обслуживать базовое приложение в качестве тега script в одном из ваших представлений. Вы сохраняете свое базовое приложение в папке rails app/assets.

Магистраль понимает соглашения о маршрутизации рельсов, и вам просто нужно дать ей путь к json api, который рельсы могут почти сгенерировать для вас с помощью rails generate resource.

Помимо синхронизации между моделями, ваши базовые приложения и приложения с рельсами довольно раздельны. Магистральные и Rails не имеют одинаковой модели MVC, но заставить их сотрудничать довольно легко.