Бэкэнд-архитектура для приложения backbone.js с поддержкой API REST?

Question

Мы стремимся разработать внутреннее приложение для повышения производительности, которое довольно JS-heavy (думаю: редактируемые поля, которые превращаются в выпадающие списки, много динамического добавления и удаления разделов на текущей странице и т. Д.), И подкрепляется отдельной существующий API JSON REST вместо локальной базы данных.

Имея плохой опыт создания динамических страниц с запасом Rails + jQuery в прошлом, backbone.js кажется более подходящим инструментом. Вопрос: Что такое хороший способ структурирования бэкэнда? Рельсы, похоже, вводят излишнюю сложность, поскольку мы не будем использовать модели баз данных ActiveRecord. В верхней части моей головы некоторые другие идеи должны использовать Sinatra, Node.js или просто HTML. Вот еще несколько соображений:

• Это ни в коем случае не приложение для одной страницы. Будет, по крайней мере, 3 разных раздела «не-хэш» URL, поэтому механизм маршрутизации будет полезен.
• Мы являемся магазином Ruby, чтобы все, что было основано на Ruby, было проще в обслуживании.
• Это приложение уникально в том смысле, что динамическое сохранение данных на сервере будет незначительным. Перезагрузите страницы после отправки данных. Однако, как упоминалось выше, до этого будет много операций на стороне клиента.

Answer 1

Backbone.js довольно гибкий; там не так много, что сложно. Тем не менее, по умолчанию он ищет бэкэнд-услуги, которые возвращают модели, отформатированные как JSON. Так что если у вас есть модель с собственностью обув, то ваш сервис должен вернуть это:

{ "foo": "bar" } 

Или для коллекции:

[ { "foo": "bar1" }, { "foo": "bar2" } ] 

Помимо этого, вы можете указать, что URL выглядит путь определения UrlRoot свойства для каждого типа модели, то URL функции, которая возвращает URL для извлечения модели с учетом UrlRoot и в модели ИДСА (идентификатор клиента).

Итак, если вы реализуете стандартный REST API, который может работать с сырым JSON, тогда вы должны быть в порядке.

Answer 2

Проблема заключается в том, чтобы построить бэкэнд как чистый двигатель api. Затем используйте стек MVC, как вы планируете, на клиентских компьютерах.

Даниэль Дубровкин является техническим директором в Art.sy. Он использует Grape, который едет на стойке.

Grape - это DSL для создания API-интерфейсов на стойке. In включает тестируемость и обрабатывает проблемы с несколькими версиями, аутентификацией, контролем доступа и документацией.

Его presentation об этом. Его blog post о последней версии Grape.

Answer 3

Вы хотите знать, что использовать под Магистраль на клиенте?

Просмотрите marionette. Tutorial. Blogging about it.

Answer 4

Поскольку вы говорите, что имеете опыт работы с Ruby, я бы предложил вам взглянуть на Sinatra. Это выглядит как самый простой способ сделать REST-сервер, особенно для разработчиков Ruby.

Answer 5

Я видел это успешно with Middleman.

В основном Middleman компилирует ваши статические активы, которые затем можно отправить на CDN или базовый веб-сервер (например, Apache или Nginx). 3 разных страницы, которые вам нужны, обрабатываются, когда Middleman генерирует 3 отдельных файла HTML.