Рекомендации по архитектуре «одностраничного веб-приложения»


12

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

Существуют ли какие-либо хорошие ресурсы для наилучших подходов к архитектуре для таких приложений. Лучший ресурс, который я нашел на данный момент, это статья об архитектуре trello: http://blog.fogcreek.com/the-trello-tech-stack/

Для меня эта архитектура, хотя и очень привлекательная, вероятно, чрезмерно разработана для моих конкретных потребностей - хотя у меня есть аналогичные требования. Мне интересно, если мне нужно беспокоиться о sub / pub на стороне сервера, могу ли я просто загружать обновления с сервера, когда что-то происходит (например, когда клиент отправляет обновление на сервер, запишите обновление в базу данных, а затем отправить обновление клиентам).

С технической точки зрения, я, вероятно, собираюсь встроить это в Node.JS или, возможно, в Ruby, хотя рекомендации по архитектуре должны в некоторой степени применяться к любым базовым серверным технологиям.

Ответы:


5

Я бы определенно посмотрел в сторону MVC на стороне клиента для такого, как Backbone.js. Он очень легкий, но придаст вашему приложению необходимую структуру. Я очень рекомендую скринкаст Peepcode как самый быстрый способ узнать больше о Backbone.

Хорошим архитектурным преимуществом MVC на стороне клиента, как это, является то, что вы можете легче перейти к обмену данными со своей серверной стороной, например, структурировать JSON поверх REST.

Backbone.js поддерживает это "из коробки" - вы можете сериализовать свои модели между клиентом и сервером как JSON, что может освободить нас от мысли с точки зрения запроса / ответа.

Нечто подобное Node.js на стороне сервера апеллирует к этой модели, где у вас может быть много недолговечных потенциально асинхронных запросов на передачу и извлечение данных.

Одна альтернатива .... Модель, подобная Comet, может быть простым способом достижения веб-публикации / подписки, и есть некоторые серверные инфраструктуры, которые поддерживают это.


Приветствия, я определенно думал об использовании MV * FW для клиентской стороны и изучал Backbone. Хорошие советы.
Мэтт Робертс

1

Я бы, вероятно, пошел с рамкой MV * javascript для внешнего интерфейса. Я сам создаю одностраничное веб-приложение и, изучив ряд решений, в итоге выбрал Backbone.js. Я обнаружил, что хотя это решение не обеспечивало максимальную функциональность из коробки, оно давало мне основную основу для начала и было гораздо более гибким, чем другие решения, на которые я смотрел (что было важно для меня).

Другими популярными решениями являются Ember.js и Knockout.js, которые предоставляют больше готовых функциональных возможностей, однако вы должны следовать их соглашениям, чтобы использовать функциональность thT (которая может работать или не работать для вас).


1

Это легкая задача ИМО. AngularJS для переднего конца, потому что это круто. NodeJS / express / SocketIO для динамичного и сексуального бэкенда с безупречным пабом / сабом и минимумом суеты. И в качестве бонуса вы можете использовать один язык для передней и задней части!

Посмотрите мою реализацию того же https://github.com/hackify/hackify-server для примера

Одно предостережение, некоторые люди рекомендуют альтернативу NodeJS socketio под названием sockjs, но я не проверил это, поэтому я не могу рекомендовать это


0

Похоже, что вы смотрите на это Apache 2.2 с сервером приложений PHP или Tomcat с простым сервлетом, который обрабатывает запросы. Это плотницкий эквивалент молотка и гвоздей. Ничего сложного, но это делает работу. Если вам когда-либо нужно было расширять функциональность, вы всегда можете сделать это, поскольку Tomcat может поддерживать jsp и jsf, если вам это когда-нибудь понадобилось.

Что касается внешнего интерфейса, мне было бы удобно просто использовать jQuery ( $ .post , $ .load , $ .ajax ), поскольку это довольно удобно для удвоения в качестве средства добавления функциональности на вашу страницу в сочетании с jQuery UI.


0

Если вы хотите обновления клиента в режиме реального времени, то вам придется либо реализовать долго блокирующие вызовы «AJAX», или предпочтительно использовать современные веб-сокеты. Они позволяют вам отправлять обновления на подключенный клиент, который будет обрабатываться небольшим количеством JavaScript.

Я понимаю, что текущее состояние (или последнее увлечение) - это AngularJS от Google. Он частично разработан, чтобы облегчить написание SPA.


0

Если вы хотите что-то близкое к среднему стеку (node.js, mongo ...) для создания одностраничного приложения, которое должно реагировать, я бы выбрал meteor . Особенно, если вы создаете прототип и начинаете с нуля.

Рельсы с угловым внешним интерфейсом были бы неплохим выбором, имхо, но вам будет труднее "отправлять обновления клиентам по мере их изменения", так как вам нужно будет установить определенные гемы, связать воедино некоторую библиотеку long-polling или sockjs .. ,

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.