#node.js #backbone.js #express #socket.io
#node.js #backbone.js #экспресс #socket.io
Вопрос:
Я уже задавал аналогичный вопрос, но этот немного отличается / специфичен:
Я собираюсь начать разработку сайта социального сообщества (для локальной группы пользователей) с такими функциями, как временная шкала, мгновенные сообщения / чат, форумы, …
Node.js и socket.io (или now.js ) на серверной части. jQuery (и, возможно backbone.js или аналогичный) во внешнем интерфейсе. Содержимое загружается через сокет.ввод-вывод или ajax и навигация через хэш URL.
Есть 2 вещи, по которым я просто не могу решить, каким путем идти. Я надеюсь, что здесь есть люди, которые могут предоставить хороший или плохой опыт.
-
Создание шаблонов на сервере или в браузере? Я не уверен, что лучше загружать полный html-сайт текущие обновления (также в html) для временной шкалы, сообщений на форуме, обмена мгновенными сообщениями / чата … или использовать что-то вроде REST api через ajax или сокет.ввод-вывод и создание шаблонов на клиентском сайте. Я никогда раньше этого не делал. Вам нужно загрузить шаблоны и т.д. и т.п. Есть ли у кого-нибудь опыт в этом? Есть также 2 способа реализовать rest-подобный API: например. запросить сообщение на форуме, затем запросить пользователя, связанного с этим сообщением, и так далее (точно так же, как на стороне сервера MVC) — или запросить сообщение на форуме, и сервер ответит всей необходимой информацией.
-
Загружать содержимое через ajax или socket.io ? Я окончательно использую сокет.Ввод-вывод или now.js для общения в режиме реального времени (мгновенные сообщения, чат) и pubsub (на главной странице -> подписаться на новые обновления временной шкалы, в теме форума -> подписаться на новые сообщения). Но должен ли я также загружать HTML (или предоставлять REST-подобный API, см. Вопрос 1) через сокет? Когда люди открывают сообщения на форуме во вкладках (что я обычно часто делаю), это будет означать множество подключений к сокетам. И я не уверен, сколько времени требуется websocket для установления соединения.
Итак, есть 4 способа сделать это:
- HTML через AJAX — вероятно, самый стабильный способ, которому не требуется много javascript для создания шаблонов — браузер может использовать открытые HTTP-соединения для запроса материалов.
- HTML через socket.io — Для загрузки содержимого должен быть установлен websocket (может быть медленнее)
- API через AJAX — поскольку ему, вероятно, требуется больше запросов, чем HTML через AJAX, могут возникнуть некоторые накладные расходы на заголовок HTTP вам требуется аутентификация в каждом запросе — я не сторонник слишком большого количества запросов ajax.
- API через socket.io — Сокет должен быть аутентифицирован только один раз, и вы можете запрашивать объекты API на лету. Однако я бы все равно загружал шаблоны и js через HTTP для кэширования браузера.
Я знаю, что это огромный пост, но я обсуждаю уже много дней и просто не могу решить, так как было бы много работы по переключению системы после начала разработки. Это не публичный проект, он ограничен ~ 10-15 тыс. местных жителей и, следовательно, не должен быть таким идеальным, хорошая возможность узнать что-то новое, на мой взгляд (я совершенно новичок в node, классический PHP MVC jquery dev здесь).
Ответ №1:
Я думаю, вам следует использовать RESTful api на серверной части, чтобы создание шаблонов происходило только на интерфейсе (возможно, с Backbone) и использовать только сокет.Ввод-вывод для реальных вещей в реальном времени (таких как чат). Нет никакого смысла использовать websockets для чего-то вроде загрузки HTML, потому что он, скорее всего, никогда не меняется.
Итак, мой голос:
1) HTML через AJAX
2) API через AJAX
3) Общение в реальном времени, такое как обмен сообщениями в чате (или другие вещи, которые постоянно меняются) через Socket.IO
Комментарии:
1. Нет статического HTML (полностью основанного на пользовательском контенте), за исключением страницы ввода / указателя, которая загружает весь javascript. Пример форума: Загрузить HTML (список тем, сообщения) и отобразить их, или загрузить json через API (список тем как массив объектов thread, поток как массив объектов post) и отобразить их на интерфейсе. Если я решу использовать API-интерфейс, я думаю, что лучше получить доступ к API через сокет, без заголовков, без файлов cookie.
2. Ну, если этот контент часто меняется, и вы хотите постоянно обновлять пользователя, я бы добился этого 2 способами: 1) Получить последние X сообщений и т.д. Из базы данных с помощью api 2) Обновлять его вторым использованием Socket.IO
Ответ №2:
Хотя на самом деле нет окончательного ответа, поскольку это зависит.
Если вам нужно, чтобы поисковая система могла сканировать, вы можете НЕ полагаться только на обработку на стороне клиента. Если ваши отдельные виды являются легкими и / или вам нужна поддержка мобильных устройств, у вас должен быть начальный рендеринг на стороне сервера.
В настоящее время я бы предложил использовать API, который могут использовать как ваше клиентское приложение, так и серверная часть. Если вы используете node для рендеринга на стороне сервера, вы можете повторно использовать большую часть той же логики, включая клиент API.
Пройдя несколько шагов дальше, если вы начнете с проекта Yahoo flux examples на github, вы сможете использовать одну и ту же логику как на стороне клиента, так и на стороне сервера, включая рендеринг с помощью React views. Это непростое решение, и потребуется некоторая работа.
Для интерактивных элементов рендеринг на стороне сервера может быть минимальным, поскольку ваши магазины запускают подключение событий через sockjs / socket.ввод-вывод при запуске клиента для ваших битов чата / мгновенных сообщений.
У вас возникнут проблемы с масштабируемостью, когда дело доходит до запуска нескольких процессов, и, вероятно, потребуется цепочка пабов / суб, поддерживаемая базой данных, для более длительных циклов повторного подключения или пропущенных сообщений обмена мгновенными сообщениями. Волшебной палочки не существует.
Прямо сейчас мне нравится flux react… Когда выйдет Angular2, у него может быть лучшая история для рендеринга на стороне сервера.