Интерфейс Backbone.js с бэкэндом RESTful Rails? - PullRequest
Новая
       11

Интерфейс Backbone.js с бэкэндом RESTful Rails?

13 голосов
/ 29 февраля 2012

Я начал в мире веб-разработки с PHP, а затем с Rails в последние несколько лет.С тех пор я занимаюсь всеми своими веб-проектами в Rails.

В последнее время, похоже, наблюдается движение к тому, чтобы сделать Rails чистым бэкэнд-сервисом RESTful и использовать инфраструктуру внешнего интерфейса, такую ​​как Backbone.js, для всех взаимодействий внешнего интерфейса.Мне интересно, что вы, ребята, возьмете на себя?Будет ли это возможным будущим?

Кроме того, кроме Backbone.js, какие еще есть альтернативы для инфраструктуры веб-интерфейса для этой цели?

Также при условии, что я захочу поддерживать как настольную версию, так и мобильную версию моего приложения, будет ли это правильный путь?То есть у меня будет один бэкэнд-сервис с разными сервисами фронтэнда?Таким образом, мне не нужно управлять всеми представлениями на стороне Rails?

Спасибо!

Ответы [ 3 ]

19 голосов
/ 29 февраля 2012

Для клиентских фреймворков в этой статье есть список из 20 с за и против: http://net.tutsplus.com/articles/web-roundups/20-javascript-frameworks-worth-checking-out/

Вот список:

  1. Backbone.js
  2. Knockout.js
  3. Асана Луна
  4. Капучино
  5. Sproutcore
  6. BatmanJS
  7. corMVC
  8. TrimJunction
  9. pureMVC
  10. Джамал
  11. шоколад
  12. sammyjs
  13. extJS
  14. agilityJS
  15. глазные яблоки
  16. activejs
  17. spinejs
  18. qooxdoo

Это примерно все, что касается создания клиентских, основанных на ajax, инфраструктур MVC JavaScript.

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

Это новый метод, который включает модульность вашего клиентского кода, передачу MVC клиенту и позволяет бизнес-логике жить на платформе. Многие приложения Software-as-a-Service используют их, и с ростом изощренности библиотек и структур javascript, а также возможностей браузера с HTML5, CSS3 и т. Д. Будет все больше усложняться в представлении на стороне клиента. .

Так что выучи это.

Каковы преимущества?

Перефразируя Linked In: для использования кэширования в браузере, отсоединения вашей клиентской презентации, асинхронной загрузки, прогрессивного рендеринга (для некоторых платформ), производительности, ajax-взаимодействия и многого другого.

Несколько замечательных фреймворков:

  1. усы
  2. dust.js
  3. рули
  4. Шаблоны закрытия Google
  5. Nun
  6. Mu
  7. кайт

Я настоятельно рекомендую посмотреть, как Linked In отходит от JSP в сторону клиентских шаблонов и почему они выбирают dust.js в Выпадающие вниз шаблоны клиентских интерфейсов Linked In для сравнение. Они углубляются в детали и исследуют, почему они изменили свой стек для поддержки этого (в нем задействовано 3 серверных технологии), а также сравнили все фреймворки, которые могли найти.

2 голосов
/ 19 ноября 2012

По моему мнению, современные веб-приложения движутся к этой модели, имеющей бэкэнд RESTful и все взаимодействия представлений, закодированные во фронтэнде.Эти бесплатные видеоуроки от Джо Зима:

http://www.joezimjs.com/javascript/introduction-to-backbone-js-part-1-models-video-tutorial/

помогли мне понять основу и как она может упростить создание шаблонов и просмотр рендеров.

2 голосов
/ 01 октября 2012

Я сделал что-то подобное несколько лет назад в .net.Это было не через .NET MVC и не использовало новые JS-фреймворки, но принцип был тот же;серверный код возвращает JSON в javascript, который создает страницу, взаимодействует и т. д.

В результате получился прекрасный адаптивный веб-сайт, но обслуживание стало кошмаром.Будьте очень осторожны, чтобы ваш JS-код был хорошо организован.

Лично мне проще поддерживать серверный код (на любом языке), чем javascript, поэтому я бы больше не пошел по этому пути.

(ИМХО)

Фрэн

...