Javascript-форум (https://javascript.ru/forum/)
-   Серверные языки и технологии (https://javascript.ru/forum/server/)
-   -   Node.js (https://javascript.ru/forum/server/6992-node-js.html)

Kolyaj 09.01.2010 23:08

Node.js
 
http://kolyaj.ya.ru/replies.xml?item_no=2953
Цитата:

Покопался с Node.js. Для тех, кто не знает -- это такой серверный асинхронный JavaScript. Все три слова для меня ключевые, я люблю JavaScript, я люблю писать на нём в асинхронном стиле, и я давно, но не активно, ищу замену для PHP на сервере, т.к. после создания кода на JS в промышленных масштабах к PHP вернуться не могу. Так что всё, что будет написано, сильно субъективно, впрочем как и всегда.

Я написал на нём парсер логов достаточно кривого формата, которые после парсинга складываются в CouchDB. Т.к. сам Node.js предоставляет только низкоуровневые функции работы с файлами (что, несомненно, хорошо), то пришлось сначала написать функцию, наподобие PHP-шной file, но которая генерирует события по прочтении очередной строки файла (а логи, кстати, многострочные). Вокруг неё уже реализовался класс, генерирующий событие после прочтения очередной записи лога. А обработчик этих событий уже отсылал записи в CouchDB (тоже несколькими строчками). И всё это асинхронно, т.е. одновременно читается файл, одновременно парсится, одновременно отправляются несколько HTTP-запросов и всё это несколькими функциями без всяких потоков.

Вобщем достаточный минимум для серверных приложений в Node.js есть, осталось написать необходимый в виде пары сотен библиотек на любой вкус. Большинство, к сожалению, кинулось реализовывать никому не нужные в данном случае web-фреймворки, хотя есть несколько достаточно оригинальных решений, как например реализация доступа к sqlite, запускающая в отдельном процессе sqlite3 и парсящая её вывод в консоль.

Из особо бредовых на мой взгляд node-XMLHttpRequest, реализующая интерфейс XMLHttpRequest. Тот самый убогий интерфейс, для которого в браузерных фреймворках создают обёртки не ради кроссбраузерности, а ради удобства. При этом в Node.js нормальный HTTP-клиент из коробки.

Короче от использования его в продакшне меня останавливает только вопрос хостинга, т.к. админ из меня некудышный, линуксоид тоже, поэтому я давно не могу решится взять vds, т.к. не знаю, что с ним делать :).

З.Ы. Ах да, главный минус -- addListener не принимает контекста вызова колбэка, и я даже не знаю, что с этим делать, кроме повсеместного использования func.bind(), что мне не сильно нравится.

Dmitry A. Soshnikov 10.01.2010 00:06

Спасибо, надо будет выделить время, тоже покапаться с серверным JS. Вкратце, конечно, читал обзоры, но не смотрел (и тем более, глубоко).

Основной принцип - они расширили какой-то движок (V8 в данном случае) новым функционалом и запускают этот интерпретатор на серваке?

Какие ещё альтернативы есть (тут, вроде недавно была похожая тема с каким-то другим серверным JS)? Какие лучшие?

Что за фреймворки? Кто пишет? Как их писать? Так же, как и для клиентского JS?

update:

Посмотрел исходники.

Kolyaj 10.01.2010 00:28

Цитата:

Сообщение от Dmitry A. Soshnikov
Основной принцип - они расширили какой-то движок (V8 в данном случае) новым функционалом и запускают этот интерпретатор на серваке?

Он (Ryan Dahl) написал на C++ движок, использующий гугловский v8 для исполнения JS, и предоставляющий в JS объекты для асинхронного ввода/вывода.

Цитата:

Сообщение от Dmitry A. Soshnikov
Какие ещё альтернативы есть (тут, вроде недавно была похожая тема с каким-то другим серверным JS)? Какие лучшие?

Какие лучшие -- это, конечно, будет сильно субъективно. Но в данном случае неоспоримые преимущества: скорость v8 и асинхронность.

Цитата:

Сообщение от Dmitry A. Soshnikov
Что за фреймворки? Кто пишет?

http://wiki.github.com/ry/node

Цитата:

Сообщение от Dmitry A. Soshnikov
Как их писать? Так же, как и для клиентского JS?

Ну вот нет, например, нативного клиента для MySQL. Можно пойти в доки по MySQL, почитать формат общения клиента с сервером по TCP и написать асинхронного клиента на JS. Отличия от клиентского JS в задачах и в предоставляемых хост-объектах.

Dmitry A. Soshnikov 10.01.2010 00:50

Цитата:

Сообщение от Kolyaj
Он (Ryan Dahl) написал на C++ движок, использующий гугловский v8 для исполнения JS, и предоставляющий в JS объекты для асинхронного ввода/вывода.

Да, я посмотрел уже исходники, ядро (основное расширение для V8) - на С++, базовая библиотека - на JS.

Цитата:

Сообщение от Kolyaj
скорость v8 и асинхронность

В смысле, асинхронность? Мульти-треды, мульти-процессы? Или тот же setTimeout?

Цитата:

Сообщение от Kolyaj
http://wiki.github.com/ry/node

Угу, спасибо, полистаю.

Я вот эту тему имел в виду: http://javascript.ru/forum/project/6...zhenijj-2.html Там тоже наподобие - какой-то движок расширен (возможно, Rhino, т.к. там фигурирует Java тоже; хотя, это лучше в той теме интересоваться)?

Node.js тоже как-то с облачной платформой связан? А в чём принципиальное отличие этой облачной платформы от этого Node.js?

Kolyaj 10.01.2010 01:05

Цитата:

Сообщение от Dmitry A. Soshnikov
В смысле, асинхронность? Мульти-треды, мульти-процессы? Или тот же setTimeout?

Например: написан у нас веб-сервер на Node.js, приходит запрос, нам нужно прочитать с диска файл. В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения, поэтому там создаётся много процессов для обработки многих запросов. В случае с Node.js оставляется колбэк, который будет вызван, когда файл будет считан с диска, а за то время пока он читается, текущий процесс обрабатывает остальные http-запросы. Т.е. как с XMLHttpRequest в браузере. Так что скорее setTimeout.

Цитата:

Сообщение от Dmitry A. Soshnikov
Я вот эту тему имел в виду: Облачная платформа для разработки javascript приложений Там тоже наподобие - какой-то движок расширен (возможно, Rhino, т.к. там фигурирует Java тоже; хотя, это лучше в той теме интересоваться)?

Node.js тоже как-то с облачной платформой связан? А в чём принципиальное отличие этой облачной платформы от этого Node.js?

Я вот, честно говоря, не понял, зачем эта облачная платформа мне лично могла бы пригодиться, а более подробно разбираться было лень. Но там Rhino, а это очень медленно. Вот тут человек говорит
Цитата:

Предварительные результаты: для Node в виртуальной машине и Rhino на обычной разница примерно в 6-7 раз, но это для единовременного выполнения скрипта. В случае обработки серии запросов Rhino будет ещё больше отставать из-за времени, необходимого на запуск JVM.

Dmitry A. Soshnikov 10.01.2010 01:51

Цитата:

Сообщение от Kolyaj
Например: написан у нас веб-сервер на Node.js, приходит запрос, нам нужно прочитать с диска файл. В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения, поэтому там создаётся много процессов для обработки многих запросов. В случае с Node.js оставляется колбэк, который будет вызван, когда файл будет считан с диска, а за то время пока он читается, текущий процесс обрабатывает остальные http-запросы. Т.е. как с XMLHttpRequest в браузере. Так что скорее setTimeout.

Угу, но на уровне реализации, файл-то, получается, читается в другом треде этого "текущего" процесса. Возможно, так же создаётся несколько процессов с несколькими тредами. Но, я только предполагаю.

Но с точки зрения JS-кода - это просто событийное программирование, где всё разруливается коллбэками и для JS это всё подаётся, как "один" поток?

Ок, будет время, поизучаю глубже.

Вообще, ECMAScript-у ничего не мешает дописать стандартную библиотеку (до уровня Ruby, Python) и расширить сферу использования, включая серверное программирование. Имею в виду, официально, по стандарту (хотя, в ближайшее время это вряд ли будет) + чтобы появилась пара-тройка признанных фреймворков - тогда JS с лёгкостью будет отличной альтернативой PHP/Python/Ruby на сервере.

kurokikaze 15.01.2010 13:52

Цитата:

Сообщение от Dmitry A. Soshnikov (Сообщение 40111)
Вообще, ECMAScript-у ничего не мешает дописать стандартную библиотеку (до уровня Ruby, Python) и расширить сферу использования, включая серверное программирование. Имею в виду, официально, по стандарту (хотя, в ближайшее время это вряд ли будет) + чтобы появилась пара-тройка признанных фреймворков - тогда JS с лёгкостью будет отличной альтернативой PHP/Python/Ruby на сервере.

Имхо стандарт должен определять синтаксис и модель языка, а не список доступных модулей. Так что библиотека может быть и внешней - главное чтобы основные модули были доступны сразу с Node, а дополнительные - по требованию. Кстати, работа над package manager для Ноды уже идёт.

А насчёт реализации - там Global interpreter lock, как в Питоне. Впрочем, если сравнивать side-by-side, Нода по производительности делает питоновский асинхронный Торнадо.

Gvozd 15.01.2010 13:59

Цитата:

Сообщение от Kolyaj
В случае с тем же PHP чтение файла будет синхронным и весь процесс заблокируется на время чтения

в PHP также доступна асинхронность при работе с потоками
используя неблокируемые сокеты, вы можете достаточно сносно работать со многими вещами, используя асинхронность: файлы, сеть, процессы
проблема в том, что эта облать документации слабо документирована, и работает не всегда стабильно.
примеров в сети также не сильно много. но, это возможно

Kolyaj 15.01.2010 14:12

Цитата:

Сообщение от kurokikaze
Кстати, работа над package manager для Ноды уже идёт.

А чем текущий require не устраивает?

Цитата:

Сообщение от Gvozd
в PHP также доступна асинхронность при работе с потоками

Вот только язык не предрасполагает писать в таком стиле.

kurokikaze 15.01.2010 14:14

Цитата:

Сообщение от Kolyaj (Сообщение 40672)
А чем текущий require не устраивает?

Require это способ подключения файлов. А kiwi - способ инсталляции пакетов (с учётом версий и зависимостей) типа apt или rubygems. Или PEAR, если хотите.


Часовой пояс GMT +3, время: 16:38.