Что лучше использовать для real time comments, socket.io или Ajax?
Учу node.js хочу сделать такой функционал: создается топик, юзер оставляет свой коммент/мнение под топиком, все должно работать без перезагрузки всей страницы. При помощи чего это лучше всего реализовать в node.js приложении? Спасибо большое за ответы!
И где в том, что вы описали, real-time?:) Обычный AJAX, сокеты тут ни к чему (хотя можно и на них). Хотите с WebSocket потренироваться — попробуйте чатик сделать. Или добавить к комментам фичу как на FB: «К этому посту кто-то еще сейчас печатает комментарий».
У нас все приложения на сокетах работают, http выдают только статику.
Вебсокеты не нагружают сеть лишними заголовками и позволяют вызывать api сервера как локальные функции.
все должно работать без перезагрузки всей страницы
Что именно? Новые комментарии от других пользователей должны ли появляться как в чатах без перезагрузки?
Если нет, то обычный AJAX, если да, то AJAX с Long polling либо WebSocket либо HTML5 SSE.
Спасибо за ответ! Нет не должны, один пользователь просто оставляет комментарий без перезагрузки страницы. Единственный вопрос, не устал ли уже ajax по сравнению с socket.io? В последнее время рекомендации идут в пользу второго
Shrt: socket.io использует несколько транспортов: там, где доступен вебсокет, он использует вебсокет, а если он недоступен или режется прокси-сервером, то использует обыкновенный AJAX.
Единственный вопрос, не устал ли уже ajax по сравнению с socket.io?
Устал, поржавел, на металлолом сдали! Ну, что вы за бред спрашиваете, вы нормальный вообще, может еще его волки скушали или он развратился?
То есть, в использовани socket.io больше плюсов?
Я вам уже сказал, что ощутимых плюсов в вашем случае не будет, да пакеты легче, , добавлю что зато есть минусы, во-первых требования к серверу - поддержка WebSocket, во-вторых затрудняется сетевая отладка так как не все снифферы поддерживают WebSocket, в-третьих под вопрос ставится безопасность данных, особенно при использовании всяких "левых" библиотек поддержки WebSocket на сервере, ведь сам протокол TCP ("сокеты") обрабатывает далеко не все возможные проблемы при неполадках с сетью, в-четвертых для поддержки кода потребуется человек с опытом с WebSocket а таких гораздо меньше чем для AJAX.
Хотя я не думаю, что вы меня услышите и что-то дойдет до вашего еуставшего мозга, я-то сам очень хороший специалист по тому что касается сети, начиная от IP-пакетов и даже глубже, но передача любой информации зависит и от принимающей стороны, то есть от вашего мозга, и если вы дурак и сами не захотите приложить усилия и стать нормальным, то так и будете бредить, а я после таких как вы исправлять "косяки", если конечно хватит мозгов ко мне обратиться, а то ведь у некоторых не хватает и опять я ничем помочь не могу.
Shrt: Плюсов в данном случае никаких, то что пакеты легче, это плюс-минус несколько сотен байт на пакет, у вас есть скорость интернета в Мбит/сек, делите ее на 8, получаете Мбайт/сек, и считаете сколько времени займет передача этих нескольких сотен байт и критична ли она, если конечно умеете считать.
Rou1997: Ахахах, смешно получилось, извините, не УСТАЛ а УСТАРЕЛ конечно-же, опечатка это была) Просто на форумах встретил заявление о том, что вебсокеты созданы для того, чтоб этот самый Ajax и заменить, и потому спросил, извините за недоразумение! :)
Rou1997: Понимаю Вашу экспрессию по поводу усталости мозга и так далее... Не обижаюсь, так как действительно бредовой вопрос получился, сам бы так реагировал наверное, слава Богу это всего лишь опечатка, иначе все плохо было бы у меня) Но я все же адекватный человек, просто еще не достаточно технически подкован, и сейчас работаю усиленно над этим, чтоб вот в дальнейшем не задавать вопросов глупых таких и соотвественно не попадать в такие глупые ситуации. Уже примерно разобрался, что мне надо использовать и как, даже уже сделал прототип на Ajax. Спасибо большое за Ваше время и ответы!
Ахахах, смешно получилось, извините, не УСТАЛ а УСТАРЕЛ
А какая разница, <нечто> устарело, <нечто> устало, <нечто> г..вно, все это одинаковые пустые слова, если вы их где-то услышали и сами-то при этом не осознаете чем он устарел и чемэто плохо для ваших целей, то сделайте два пальца в рот, точнее в мозг, и тем самым удалите из него все эти слова. :)
Постоянно все признавать "устаревшим" это типичная черта Google и его российских "учеников", прежде всего Яндекса, но у этих людей (у Google) в последние 5 лет налицо "синдром вахтера", они и свои собственные проекты закрывают аж пачками, причем и старые и новые, и даже еще не "взлетевшие" но уже успевшие им не понравиться, вообще очень мерзкие эти конторы, Google, Яндекс, туда же всякие ПепсиКо (Вимм-Билль-Данн), достаточно посмотреть на отзывы об их работе с конечным клиентом, например о работе Яндекс.Такси, в итоге выявляется парадокс: с одной стороны эти конторы - чистой воды "ширпотреб" рассчитанные на широчайшую аудиторию, а у нас не СССР и эта самая аудитория не имеет единой цели, очень разношерстная, поэтому и их "короли" не знают на что ориентироваться, с другой стороны - Google это еще и очень популярный и доходный "ширпотреб", им при таких деньгах тяжело осознавать себя "ширпотребом", отсюда и навязчивая идея обеспечить качество, безопасность, а как их обеспечить чтобы людям нравилось они не знают и не могут узнать, что правильные что неправильные решения влияют на их финансы примерно одинаково, финансы как стремились к бесконечности так и стремятся.
Если конкретно про ваше высказывание про то, что вебсокеты новее HTTP, то я вот такие аргументы приведу:
TCP (сокеты) - 1983 год
HTTP (AJAX) - 1992 год
WebSocket - 2010 год, но это же опять сокеты! Он опять реализует старую концепцию TCP, от которой в HTTP отказались. Я точно не знаю есть ли в стандарте WebSocket надлежащие требовния к безопасности данных при неполадках с сетью чтобы не реализовывать все это самому как приходится делать с TCP, и не знаю как с этим именно в Node.js, но вообще реализации WebSocket не отвечающие этим требованиям точно есть.
Словом, WebSocket это примерно как встроенный Ассемблер: иногда используется для конкретных целей, но никогда не заменит более высокоуровневый C++.
Средний
