Comments 81
Отлично! Спасибо, Лео.
Я все равно не понял, почему собственно выбрали NodeJS
По сути единственное приемущество которое я вижу — возможность писать клиентский и серверный код на одном языке.
Все остальное(event driven processing) вполне себе реализуемо на любом адекватном языке программирования и к фреймворку отношения не имеет.
С другой стороны, для того что бы писать клиентский и серверный код на одном языке можно использовать например GWT, либо еще какой-нибудь компилятор в javascript.
А главное, JS — язык без строгой типизации, что на мой взгляд — минус, причем существенный, для серверных языков программирования.
По сути единственное приемущество которое я вижу — возможность писать клиентский и серверный код на одном языке.
Все остальное(event driven processing) вполне себе реализуемо на любом адекватном языке программирования и к фреймворку отношения не имеет.
С другой стороны, для того что бы писать клиентский и серверный код на одном языке можно использовать например GWT, либо еще какой-нибудь компилятор в javascript.
А главное, JS — язык без строгой типизации, что на мой взгляд — минус, причем существенный, для серверных языков программирования.
Обычно серверная логика WebSockets реализуется на Java/Python/Ruby/Erlang, если не брать в расчет JS. При выборе любой технологии из этого списка, нам бы пришлось нанимать отдельно человека, что получилось бы существенно дороже. Также мы бы получили размытие стэка технологий, что есть не хорошо.
Погодите, что такое «обычно»?)
Про размытие стека технологий — вы до этого использовали NodeJS? Если да, тогда понятно, но тогда ответ на мой вопрос — «потому что уже было».
Если нет, то стек технологий все равно размысля за счет добавления NodeJS.
По сути мне кажеться язык вещь второстепенная. В том смысле, что если у вас везде single thread assumed CRUD код, а надо добавить что-то хитрое(для чего вам потребовался event driven processing), то все равно надо потратить усилия на изучение тонкостей. И в этом смысле изучения нового языка — о(прочих усилий).
Про размытие стека технологий — вы до этого использовали NodeJS? Если да, тогда понятно, но тогда ответ на мой вопрос — «потому что уже было».
Если нет, то стек технологий все равно размысля за счет добавления NodeJS.
По сути мне кажеться язык вещь второстепенная. В том смысле, что если у вас везде single thread assumed CRUD код, а надо добавить что-то хитрое(для чего вам потребовался event driven processing), то все равно надо потратить усилия на изучение тонкостей. И в этом смысле изучения нового языка — о(прочих усилий).
Код Node.js сможет понять любой наш JS'ер, в отличии от Erlang'а или Scala, поэтому размытия почти нет ;-)
А ведь вы правы.
Я как раз хотел поспорить на тему того, что челове знающий Erlang скорее всего уже знает JS и еще с десяток языков (в эрланг просто так с улицы не приходят). Но как-то совсем забыл о том, что в обратную сторону не работает.
Я как раз хотел поспорить на тему того, что челове знающий Erlang скорее всего уже знает JS и еще с десяток языков (в эрланг просто так с улицы не приходят). Но как-то совсем забыл о том, что в обратную сторону не работает.
Я вот одного не понимаю — неужели для вас другой язык(не считая erlang, давайте возьмем python/java/perl vs javasscript) это большее препятствие, чем другая концепция(single threaded environment на клиенте vs async event processing на сервере)?
Знание языка(js) не делает из человека специлиста по бекенду ) Мягко говоря. Шаг в сторону и ваш специалист читает тонны документации об элементарных вещах, так что мечта утопична имхо. И Размытие тут больше похоже на разделение обязностей.
Когда появится поддержка планшетов в приложении для android?
в течение 2-х недель
Отличная новость! Жду с нетерпением
Тоже интересует приложение для планшетов. Надеюсь вы не сдвините дедлайны для своих разработчиков.
А можно подписаться на какой-нибудь закрытый бета-тест?
А можно подписаться на какой-нибудь закрытый бета-тест?
Покупал планшет на Android специально для изучения английского в Lingualeo. Уже полгода жду приложения и все никак! Надеюсь что это правда, что через две недели будет.
Вы что-нибудь с виджетом уже сделайте а, им же нереально пользоваться из-за тормозов!
Почему выбор отграничивался MongoDB и DynamoDB? В чем была проблема с обычными реляционками?
Захотелось поэкспериментировать :-)
По максимальной нагрузке тестировали? Сколько соединений одновременно держит? Какая максимальная скорость записи?
Есть же и другие, CouchDB, например. И код бы понимал каждый JS-ер :) (там есть возможность выбора JS или Erlang использовать для представлений, фильтров и т. п.)
Кауч или Риак — классные. Но у Монги есть псевдоSQLный язык запросов. Многим гораздо удобнее писать на SQL, чем функции map-reduce. С последними, в общем-то, нет проблем — это скорее дело опыта и привычки, но раз многие SQL и так знают, то и хватаются прежде всего за Mongo.
Для Couch должны были разрабатывать свой язык запросов, но они скучковались с дядей, который пишет SQLite. Он крутой и доктор наук и все такое, но чего-то у них все зависло. Может быть, было бы лучше наизобретать какой-то — пусть кривой, но рабочий -велосипед, чем ждать, пока мудрейший доизобретет все «как надо».
Для Couch должны были разрабатывать свой язык запросов, но они скучковались с дядей, который пишет SQLite. Он крутой и доктор наук и все такое, но чего-то у них все зависло. Может быть, было бы лучше наизобретать какой-то — пусть кривой, но рабочий -велосипед, чем ждать, пока мудрейший доизобретет все «как надо».
Runa Capital тебя сейчас поэкспериментирует )
А как вы оцениваете стоимость использования DynamoDB, она же до недавнего времени была дорогая ужасно!
А какая нагрузка достается NodeJS? И сколько памяти при этом она потребляет?
UFO just landed and posted this here
Для решения проблемы кросс-платформенности нами была выбрана библиотека Sock.JS. Во-первых, из-за соответствия стандартам W3C для WS, а во-вторых, Sock.JS отлично подходит для наших потребностей.
Socket.IO рассматривался? Если да, то интересно чем не устроил?
Обе библиотеки очень хороши. У Sock.js несколько кошернее реализованы fallback'и.
А можно поподробнее про разницу?
Порядок выбора транспортов:
Socket.io 0.x:
— websocket, если не получилось, то
— flash socket,
— long polling,
— ajax,
— JSONp
Основной минус: если не открылся вебсоккет, открывается флешсоккет, у которого время соединения до 5 секунд. Плюс в том, что пробует соединяться по самым быстрым транспортам в первую очередь, и значит, первые сообщения между узлами будут идти с максимальной скоростью.
Socket.io 1.x (и engine.io):
— тот же, что сверху, но в обратном порядке, но я не уверен в том, что flash sockets идут де websockets
Плюс в том, что коннекшен открывается быстро и гарантированно, а потом уже идет наращивание скорости. Минус в том, что переход до оптимального транспорта долгий. Первое время обмен сообщениями будет идти медленно.
Socks:
— websocket
— HTTP long polling,
— ajax,
— jsonp
Плюс в том, что нет задержки на flash socket, как у Socket.IO 0.x, минус в том, что если с вебсоккетами не судьба, то будут использоваться только медленные способы отправки по HTTP.
Общая рекомендация по вебсоккет-соединениям — юзать TLS. В этом случае все прокси видят зашифрованый трафик и вряд ли будут резать переход на другой протокол.
Socket.io 0.x:
— websocket, если не получилось, то
— flash socket,
— long polling,
— ajax,
— JSONp
Основной минус: если не открылся вебсоккет, открывается флешсоккет, у которого время соединения до 5 секунд. Плюс в том, что пробует соединяться по самым быстрым транспортам в первую очередь, и значит, первые сообщения между узлами будут идти с максимальной скоростью.
Socket.io 1.x (и engine.io):
— тот же, что сверху, но в обратном порядке, но я не уверен в том, что flash sockets идут де websockets
Плюс в том, что коннекшен открывается быстро и гарантированно, а потом уже идет наращивание скорости. Минус в том, что переход до оптимального транспорта долгий. Первое время обмен сообщениями будет идти медленно.
Socks:
— websocket
— HTTP long polling,
— ajax,
— jsonp
Плюс в том, что нет задержки на flash socket, как у Socket.IO 0.x, минус в том, что если с вебсоккетами не судьба, то будут использоваться только медленные способы отправки по HTTP.
Общая рекомендация по вебсоккет-соединениям — юзать TLS. В этом случае все прокси видят зашифрованый трафик и вряд ли будут резать переход на другой протокол.
А чем node адекватен в работе со streamами?
Адекватен чуть более, чем полностью.
Есть хорошее видео www.youtube.com/watch?v=lQAV3bPOYHo
Хотя докладчик в лучшем случае под гинко билоба)
Хотя докладчик в лучшем случае под гинко билоба)
Вообще очень радует, что вы выбрали эту технологию. Компании, использующие открытую технологию, делают вклад в нее.
Расскажите о недостатках? Ранее вы на чем писали подобные вещи? Или это первый опыт? С node.js до этого имели дело?
Хотелось бы так-же больше узнать про оптимизацию. Спасибо ;)
Расскажите о недостатках? Ранее вы на чем писали подобные вещи? Или это первый опыт? С node.js до этого имели дело?
Хотелось бы так-же больше узнать про оптимизацию. Спасибо ;)
Можно я тоже поделюсь, как недавний конверт в ноде? Недостатки:
- яваскрипт неплохой язык, но синтаксис удручает. Лечится кофискриптом.
- асинхронно-событийная модель ноде не всегда легко ложится в мозг. Надо всегда заботиться о том, как бы не заблокировать единственный тред, и любая (даже простая, типа чтения директории) операция выполняется не линейно, а с колбэком. Лечится звёздным модулем
async.js,и некоторым опытом. - нету HAML/SLIM. Лечение: node-blade.
отсутствие флагшип-фреймворков, типа Ruby on Rails. Пока не излечено, но как-то и не особо мешает. Голый REST не так уж часто подходит.
Преимущества: скорость! Более резвого я ничего не видел. Продуманность: потоки просто рулят. Интегрированная крипто-библиотека высокого качества (из OpenSSL). Поддержка сообщества, модули, значительное количество перешедших из рельсов, и взявших с собой лучшие практики. Отсутствие шизокодии: сервер и клиент пишутся на одном языке.
Молодцы! Еще бы прекратили тихушные обновления сайта (без уведомления пользователей, что вообще происходит). А то постоянные бета-тесты на пользователях расстраивают. То одно сломается, то другое. Народ ругается.
А обещанную среднюю и долгую память когда доделаете?
А обещанную среднюю и долгую память когда доделаете?
Если не секрет — какая сейчас нагрузка у сервиса в rps?
Не совсем в тему, но как-то странно у вас скидочная политика работает: например, я хочу купить Золотой статус на год и Программу для начинающих. Если я это делаю на свой аккаунт у меня получается, с учетом скидок, 990 + 690 (вместо полных 2400 + 1485), а если я хочу купить в подарок, то скидка только на годовой статус (990 + 1485). Это баг или фича?:)
Кстати, несовсем корректно работает переключалка языков, при самом первом заходе на сайт язык стоит английский (видимо, из локали), но переключатель в позиции Русский язык. (Version 26.0.1410.63 Chrome)
Кстати, несовсем корректно работает переключалка языков, при самом первом заходе на сайт язык стоит английский (видимо, из локали), но переключатель в позиции Русский язык. (Version 26.0.1410.63 Chrome)
>Кстати, несовсем корректно работает переключалка языков, при самом первом заходе на сайт язык стоит английский (видимо, из локали), но переключатель в позиции Русский язык. (Version 26.0.1410.63 Chrome)
Это потому внутри есть два понятия «языка»
1) язык интерфейса
2) родной язык пользовтеля
а переключатель один =)
у вас в хроме выставлен английский интерфейс (английская локаль), поэтому отображается на Английском
но при этом вы из России и пришли на lingualeo.ru поэтому скорее всего ваш родной язык русский
переключатель отображает «родной язык»
в настройках профиля можно выбрать и настроить тот который захочется
Это потому внутри есть два понятия «языка»
1) язык интерфейса
2) родной язык пользовтеля
а переключатель один =)
у вас в хроме выставлен английский интерфейс (английская локаль), поэтому отображается на Английском
но при этом вы из России и пришли на lingualeo.ru поэтому скорее всего ваш родной язык русский
переключатель отображает «родной язык»
в настройках профиля можно выбрать и настроить тот который захочется
Не работает, бесконечная загрузка :(. Браузеры: хром, фф, ие, последних версий.
Думал виндовый фаер блочит, выключил — так же бесконечная загрузка.
Думал виндовый фаер блочит, выключил — так же бесконечная загрузка.
попробуйте lingualeo.com/social/dialogs
возможно вы перешли по ссылке https://
возможно вы перешли по ссылке https://
Замечательное описание внедрение технологий. Интересно было бы ещё узнать, в какие сроки вам удалось вложиться.
Здесь должен был быть Go lang, а не node.js.
Тогда было бы быстрее и не 600 Мб ОЗУ, а 6.
Тогда было бы быстрее и не 600 Мб ОЗУ, а 6.
Язык хороший, но либ мало, по этому они бы убили кучу времени на каждый чих.
P.S. Да я знаю, что судя по спискам либы есть для всего и вся, но они или мало поддерживаются, или вообще заброшены и ни кому не нужны, в большинстве своем. Такая уж печальная ситуация. А основатели судя по всему будут и дальше заниматься только самим языком, все остальное по их мнению должно делать сообщество.
P.S. Да я знаю, что судя по спискам либы есть для всего и вся, но они или мало поддерживаются, или вообще заброшены и ни кому не нужны, в большинстве своем. Такая уж печальная ситуация. А основатели судя по всему будут и дальше заниматься только самим языком, все остальное по их мнению должно делать сообщество.
Кроме того, грамотный JavaScript-программист, работая на Node, сможет реализовать весь объём задачи, а не только её серверную часть (в отличие, например, от специалиста по Erlang).
Люди, очнитесь уже, ваш NodeJS это сборище костылей, разной степени тяжести.
Специалист на Erlang, напишет серверную часть, на порядок грамотнее и лучше, чем js разработчик.
А так же дольше, а потом он не заменим.
Дольше? Вы пробовали писать на erlang? Язык очень простой, с отличной, стабильной платформой, в отличии от.
Пробовал, досихпор кошмары сняться. Дольше потому, что все надо будет делать самому, ибо модулей практически нет. Нет удобного средства контроля зависимостей (rebar смешен и не все библиотеки цепляет). А так же все еще нет удобного вэб фрэимворка (ну аксиом не плох), приходится писать на вэб-сервере :)
Забавно, когда начинает указывать на недостатки ерланга, выясняется, что он не для вэба и максимум для rest сервисов. Но приэтом каждый раз в топике про node.js говорят, что надо было на ерланге писать.
Забавно, когда начинает указывать на недостатки ерланга, выясняется, что он не для вэба и максимум для rest сервисов. Но приэтом каждый раз в топике про node.js говорят, что надо было на ерланге писать.
выясняется, что он не для вэба и максимум для rest сервисов
А чем REST для веба не устраивает?
Под «вебом» видимо имелись в виду классические html/css/js для «сложных» сайтов, где на одной странице обычно отображается куча несвязанных динамических формируемых разнотипных сущностей (которые в «канонических» (XML, JSON и т. п.) rest-ответах отсутствуют) типа навигации, рекламы, информеров, личных кабинетов, в общем всяческих хидеров, футеров и сайдбаров, а раскладки для них базируется на мощной системе шаблонов (хотя бы в голове у дизайнера). Без поддержки такого html-рендеринга со стороны фреймворка как-то грустно становится. В обработчике запроса нужно «ручками» анализировать «тип» запроса (например, /user/volch.html или /user/1.json) и вытягивать или один объект или коллекцию, или вдобавок к ним кучу всяких «лучшие темы», «последние комментарии» и т. д. Приложению (одностраничному веб или «нативному» — не суть) не сложно все нужные запросы по одному отправить, даже если оно отображает то же самое, что сайт. А вот сайту нужен механизм сбора страницы из шаблонов, так чтобы шаблон мог независящие от параметров запроса данные сам вытащить из приложения.
Сумбурно объяснил, но, надеюсь, понятна основная мысль, что без поддержки со стороны фреймворка чистота рест-контроллеров сильно нарушается.
Сумбурно объяснил, но, надеюсь, понятна основная мысль, что без поддержки со стороны фреймворка чистота рест-контроллеров сильно нарушается.
В обработчике запроса нужно «ручками» анализировать «тип» запроса (например, /user/volch.html или /user/1.json) и вытягивать или один объект или коллекцию, или вдобавок к ним кучу всяких «лучшие темы», «последние комментарии» и т. д.
Ок, только при чем тут REST тогда? Если у вас запросы на /user/volch.html отдают коллекцию, а /user/1.json — объект, то что-то не так спроектировано (по крайней мере, с точки зрения REST resources).
так чтобы шаблон мог независящие от параметров запроса данные сам вытащить из приложения.
По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.
Сумбурно объяснил, но, надеюсь, понятна основная мысль, что без поддержки со стороны фреймворка чистота рест-контроллеров сильно нарушается.
Современные web-системы имеют тенденцию к decoupling на всех уровнях. Посмотрите на привычные Flask (python), Sinatra (ruby), или весь Clojure-овский стек. Есть сервер, которые выполняет базовые вещи — request/response handling. Все остальное — прикручивается дополнительно: ровно то, что вам нужно и тогда, когда вам нужно. Нужны темплейты — прикрутили. Нужны сессии пользователей — прикрутили. База или ORM — прикрутили. И т.д.
Ок, только при чем тут REST тогда? Если у вас запросы на /user/volch.html отдают коллекцию, а /user/1.json — объект, то что-то не так спроектировано (по крайней мере, с точки зрения REST resources).
Они отдают один и тот же объект точки зрения REST, но по разному представленный, а, главное, по разному декорированный.
По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.
Скорее это DDD в чистом виде. Пришел к обработчику запрос на объект типа такого-то с id таким-то, он его от модели получил и отдал рендереру. От того, что дизайнер или менеджер решил добавить на страницу ещё какой-то объект модели, с запросом не связанный, разве должна меняться логика rest-контроллера?
По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.
Судя по ощущениям (и личным, и наблюдениям) к фреймворкам на языках типа Erlang или JavaScript мощные html-шаблонизаторы плохо прикручиваются, когда речь идет о сборе независимых данных в один ответ. Они (фреймворки) хорошо работают в ситуациях канонического REST, когда возвращается один объект или коллекция однотипных объектов, желательно в минимально изменяющемся формате. Но в мире сайтов, многостраничных веб-приложений, это редкость — обычно на один запрос кроме цели запроса нужно возвращать и кучу «служебных» объектов, причем и их набор, и их представление, и их компоновка могут меняться очень часто, и в идеале эти изменения должен быть способен сделать дизайнер или менеджер, которым программист дал какое-то «API».
У Вас же бэкенд на php написан, пробовали phpDaemon? Если да, то чем не устроил?
вместо phpDaemon
я думаю лучше www.phpReact.org ;) он интереснее
я думаю лучше www.phpReact.org ;) он интереснее
под php нет серверной части для sockjs
Мы помним об этом, и для WebSocket-соединения используем порт 443 (без привязки к https). Это решение позволяет избегать возможных сетевых проблем.
А почему не через 80 порт, благо Nginx теперь позволяет?
Каким образом вы решили вопрос с транзакциями?
=) а где конкретно в диалогах «транзакции»?
и что вы подразумеваете под этим словом?
в чем заключаются на ваш взгляд «проблемы»?
и что вы подразумеваете под этим словом?
в чем заключаются на ваш взгляд «проблемы»?
Конкурентное обновление группы данных
конкуретное обновление в данном случае не требуется, при добавлении сообщения, в DynamoDB просто добавляются Item по HashKey для соответсвующего dialogID
максимум требуется атомарный инкремент (если хранить длину сообщения)…
его можно сделать через внешние локи по ключу (опять же dialogID например на redis), но нагрузка не настолько большая…
а с учетом того что сервер nodejs одно-поточный и используется nodejs+sockjs… то возникновение необходимости обновить кол-во сообщений в диалоге одновременно от двух клиентов, очень мала
если говорить про DynamoDB то там все просто, это не ACID хранилище и консистентности там нет, зато очень высокая доступность и низкая latency, достаточно стоимость низкая (по сравнению с остальными сервисами типа EC2 или RDS) и приемлимое API для определенного вида выборок =)
максимум требуется атомарный инкремент (если хранить длину сообщения)…
его можно сделать через внешние локи по ключу (опять же dialogID например на redis), но нагрузка не настолько большая…
а с учетом того что сервер nodejs одно-поточный и используется nodejs+sockjs… то возникновение необходимости обновить кол-во сообщений в диалоге одновременно от двух клиентов, очень мала
если говорить про DynamoDB то там все просто, это не ACID хранилище и консистентности там нет, зато очень высокая доступность и низкая latency, достаточно стоимость низкая (по сравнению с остальными сервисами типа EC2 или RDS) и приемлимое API для определенного вида выборок =)
Sign up to leave a comment.
Хроники LinguaLeo: как мы сделали «Диалоги на английском» с Node.js и DynamoDB