Хроники LinguaLeo: как мы сделали «Диалоги на английском» с Node.js и DynamoDB



    Пользователи LinguaLeo начинают изучать английский язык в Джунглях — хранилище тысяч материалов разного уровня сложности, формата и тематик; шаг за шагом учатся слышать и понимать речь носителей языка и расширять словарный запас. Кому нужна грамматика — идут в Курсы. Словарный запас пополняется не только из Джунглей, при добавлении незнакомых слов в Личный словарь, но и с помощью подготовленных Наборов слов, доступных для индивидуального изучения. В разделе Общение можно вести Диалоги на английском, чтобы практиковать язык с другими пользователями LinguaLeo в режиме real-time, выбирая темы для общения. Общение только на английском!

    Для создания Диалогов на английском мы использовали Node.js, DynamoDB (все на AWS). Сейчас поделимся нашим опытом.

    Почему Node.js?




    «… Чтобы обеспечить нашим пользователям все возможности для общения, мы выбрали технологию Node.js. Почему? Node.js адекватен для работы со stream'ами, где существует огромное количество модулей. Кроме того, грамотный JavaScript-программист, работая на Node, сможет реализовать весь объём задачи, а не только её серверную часть (в отличие, например, от специалиста по Erlang).

    В качестве «транспортного узла» между сервером и клиентом мы использовали WebSockets как наиболее быстрый способ доставки информации.

    Для решения проблемы кросс-платформенности нами была выбрана библиотека Sock.JS. Во-первых, из-за соответствия стандартам W3C для WS, а во-вторых, Sock.JS отлично подходит для наших потребностей.



    Итак, поехали. Демон Node.js мы запустили на «облачных» мощностях Amazon EC2. Деплоится приложение через git. За логирование и перезапуск отвечает модуль forever. К слову, у Amazon'а есть очень полезный сервис — Amazon Cloudwatch. Его функционал позволяет мониторить основные параметры системы, а главное его достоинство — настраиваемые нотификации, которые позволяют следить только за тем, что действительно важно. Для получения детальной информации о состоянии приложения мы используем nodetime.



    В качестве драйвера для работы с DynamoDB используется модуль dynode. Он хорошо себя зарекомендовал, однако несовершенная техническая документация добавила дёгтя в бочку мёда. Официальный Node.js SDK от Amazon'а вышел позднее и всё ещё находится в стадии Developer Preview. Таким вот естественным путём образом было принято решение использовать продукты от Amazon'а, ибо они отвечают всем техническим требованиям.



    Тонкости работы Node.js


    Особое внимание мы уделили проблеме авторизации пользователя на сервере диалогов. У нас за авторизацию на сервере отвечают cookie. Это весьма «дорогое» решение с точки зрения скорости работы, но оно подкупает стабильностью и безопасностью, плюс независимой сервис-ориентированной архитектурой.

    Как это работает? Cookie пользователя поступают через WebSockets на сервер диалогов → сервер диалогов проверяет валидность cookie, отправляя запрос с полученной кукой к нашему API, а оно уже отдаёт данные пользователя обратно. Если данные получены без ошибок, сервер «Диалогов» делает своё дело (авторизует) и отсылает данные на пользователя.

    Мы знаем, что многие занимаются на LinguaLeo не только дома, но и на работе. Часто случается, что корпоративные фаерволы настроены чрезмерно строго, из-за чего все порты, кроме стандартных, бывают недоступны. Мы помним об этом, и для WebSocket-соединения используем порт 443 (без привязки к https). Это решение позволяет избегать возможных сетевых проблем.

    Особенности DynamoDB


    Чуть больше года назад Amazon выпустил распределённую NoSQL базу данных — Amazon DynamoDB. На этапе проектирования системной архитектуры перед нами стоял выбор между двумя продуктами: MongoDB и DynamoDB. От первого варианта мы отказались из-за сложностей с администрированием, и выбор пал на Amazon, так как поддержки в случае с его продуктом не требовалось. Ну и, конечно, самим было интересно «обкатать» технологию для дальнейшего использования.

    Оказалось, работа с DynamoDB сильно отличается от всего того, что мы привыкли видеть. Являясь SaaS-продуктом, эта штука научила нас принимать в расчёт время на http-запрос. В пределах датацентра Amazon'а среднее время запроса составляет около 20 миллисекунд, из-за которых мы пришли к выводу: крайне желательно все выборки делать только через индексы (это быстрее и дешевле), а scan-запросы использовать исключительно для аналитики или миграций.

    Структура данных


    Dialogs — хранение метаданных диалога, кэширование последнего сообщения.



    UserDialogs — список диалогов пользователя, кэширование + счетчик непрочитанных сообщений.



    Messages — все сообщения пользователей.



    User2User — участники диалога.



    Пример 1

    Процесс получения всех диалогов пользователя для страницы «Мои диалоги на английском» реализован нестандартно. На странице пользователь видит все свои диалоги, в том числе общее количество непрочитанных сообщений, а также последнее сообщение каждого диалога.

    Данные выбираются за два запроса. Первый – это выборка всех dialogld из таблицы UserDialogs с помощью Query. Второй – это получение диалогов посредством BatchGetItem. Тут есть небольшой нюанс — BatchGetItem за один раз выбирает максимум 100 сообщений. Поэтому, если их у пользователя 242 штуки, нам потребуется сделать 3 запроса, что занимает около 70-100 миллисекунд. Помня об этом и стремясь к большей оптимизации производительности, мы кэшируем данные диалогов в ElasticCache, обновляя его при каждом новом сообщении.



    Пример 2

    Добавление нового сообщения в диалог тоже происходит нетривиально. Скорость базы данных нам не очень важна, поскольку мы не дожидаемся записи в DynamoDB. Нам ведь нужно провести большое количество записей, а это играет значительную роль для быстроты последующей выборки. Сначала мы записываем новое сообщение в таблицу Messages PutItem, а после кэшируем в таблице Dialogs UpdateItem. Дальше нам нужно заинкрементить messageCounter в таблице UserDialogs для каждого пользователя (UpdateItem). Всякое ведь бывает, вдруг один из пользователей решил удалить диалог и сбросил нам счетчик сообщений. В сумме = 4 запроса, по времени собираются около 70-100 миллисекунд. К сожалению, такие транзакции не поддерживаются в DynamoDB, что накладывает ощутимые ограничения для процессов, где сохранность данных критично важна.

    А вообще, изменение требований к продукту — явление довольно частое. Иногда это влечёт за собой трансформацию структуры данных. В реляционных базах данных это решается с помощью ALTER TABLE, а вот в DynamoDB этой штуки просто нет. Изменение схемы тут обходится очень дорого. Нам приходится пересоздавать таблицы или использовать Elastic MapReduce. За оба варианта приходится платить. Много данных = много денег. Чтобы с этим как-то справиться, пришлось выбирать все данные Scan'ом по 1 мегабайту, а после записывать в новую таблицу. Отнимает очень много времени, но это плата за отсутствие DBA.

    Впечатления от DynamoDB


    Наш эксперимент по использованию DynamoDB удался. Это потрясающая база данных, которая отличается простотой масштабирования. Работаете с ней и забываете про администрирование. Но помните: взамен она требует аккуратного обращения на этапе проработки архитектуры. Иначе возможны всякие там неожиданные повороты и неприятные грабли. Мы рекомендуем использовать DynamoDB, если некритичных данных много, а работать с ними надо часто. Мы пользуемся — нам нравится» :)

    ***
    Общайтесь легко и непринуждённо в Диалогах на английском — практикуйте английский язык в приятной компании и присоединяйтесь к нашей команде!

    Следите за новостями на Facebook, Вконтакте и в Twitter, делитесь впечатлениями и получайте удовольствие. Свобода общения — это здорово!

    Команда LinguaLeo
    Lingualeo
    0.00
    Company
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 81

      –1
      Отлично! Спасибо, Лео.
        +9
        Я все равно не понял, почему собственно выбрали NodeJS
        По сути единственное приемущество которое я вижу — возможность писать клиентский и серверный код на одном языке.
        Все остальное(event driven processing) вполне себе реализуемо на любом адекватном языке программирования и к фреймворку отношения не имеет.
        С другой стороны, для того что бы писать клиентский и серверный код на одном языке можно использовать например GWT, либо еще какой-нибудь компилятор в javascript.
        А главное, JS — язык без строгой типизации, что на мой взгляд — минус, причем существенный, для серверных языков программирования.
          0
          Обычно серверная логика WebSockets реализуется на Java/Python/Ruby/Erlang, если не брать в расчет JS. При выборе любой технологии из этого списка, нам бы пришлось нанимать отдельно человека, что получилось бы существенно дороже. Также мы бы получили размытие стэка технологий, что есть не хорошо.
            +3
            Погодите, что такое «обычно»?)
            Про размытие стека технологий — вы до этого использовали NodeJS? Если да, тогда понятно, но тогда ответ на мой вопрос — «потому что уже было».
            Если нет, то стек технологий все равно размысля за счет добавления NodeJS.
            По сути мне кажеться язык вещь второстепенная. В том смысле, что если у вас везде single thread assumed CRUD код, а надо добавить что-то хитрое(для чего вам потребовался event driven processing), то все равно надо потратить усилия на изучение тонкостей. И в этом смысле изучения нового языка — о(прочих усилий).
              +2
              Код Node.js сможет понять любой наш JS'ер, в отличии от Erlang'а или Scala, поэтому размытия почти нет ;-)
                +2
                А ведь вы правы.
                Я как раз хотел поспорить на тему того, что челове знающий Erlang скорее всего уже знает JS и еще с десяток языков (в эрланг просто так с улицы не приходят). Но как-то совсем забыл о том, что в обратную сторону не работает.
                  0
                  А что случается с человеком, чтобы ему прийти в ерланг?
                    +7
                    просветление
                      +2
                      это в хаскель (дзен) или лисп (чань)
                    –1
                    Парень, знающий Эрланг, будет просить дохрена бабла. С другой стороны, за возможность покодить на Ноде многи джаваскриптеры согласятся прийти за скромные деньги.
                    +3
                    Я вот одного не понимаю — неужели для вас другой язык(не считая erlang, давайте возьмем python/java/perl vs javasscript) это большее препятствие, чем другая концепция(single threaded environment на клиенте vs async event processing на сервере)?
                      0
                      На клиенте как бы тоже все асинхронное, так что я не вижу проблемы.
                      +5
                      Знание языка(js) не делает из человека специлиста по бекенду ) Мягко говоря. Шаг в сторону и ваш специалист читает тонны документации об элементарных вещах, так что мечта утопична имхо. И Размытие тут больше похоже на разделение обязностей.
                +1
                Когда появится поддержка планшетов в приложении для android?
                  +1
                  в течение 2-х недель
                    +3
                    Отличная новость! Жду с нетерпением
                      0
                      Тоже интересует приложение для планшетов. Надеюсь вы не сдвините дедлайны для своих разработчиков.
                      А можно подписаться на какой-нибудь закрытый бета-тест?
                        +1
                        Для участия в бета-тесте отправьте запрос на android [dog] lingualeo.ru
                        0
                        Покупал планшет на Android специально для изучения английского в Lingualeo. Уже полгода жду приложения и все никак! Надеюсь что это правда, что через две недели будет.
                          0
                          Вы что-нибудь с виджетом уже сделайте а, им же нереально пользоваться из-за тормозов!
                            0
                            Подскажите устройство и ваш аккаунт на lingualeo
                        +1
                        Почему выбор отграничивался MongoDB и DynamoDB? В чем была проблема с обычными реляционками?
                          0
                          Захотелось поэкспериментировать :-)
                            0
                            По максимальной нагрузке тестировали? Сколько соединений одновременно держит? Какая максимальная скорость записи?
                              –1
                              Node.js не тестировали, но внимательно следили за нагрузкой. Никаких проблем по этой части нет, разве пришлось немного настраивать *nix.
                              +2
                              Есть же и другие, CouchDB, например. И код бы понимал каждый JS-ер :) (там есть возможность выбора JS или Erlang использовать для представлений, фильтров и т. п.)
                                +1
                                Кауч или Риак — классные. Но у Монги есть псевдоSQLный язык запросов. Многим гораздо удобнее писать на SQL, чем функции map-reduce. С последними, в общем-то, нет проблем — это скорее дело опыта и привычки, но раз многие SQL и так знают, то и хватаются прежде всего за Mongo.

                                Для Couch должны были разрабатывать свой язык запросов, но они скучковались с дядей, который пишет SQLite. Он крутой и доктор наук и все такое, но чего-то у них все зависло. Может быть, было бы лучше наизобретать какой-то — пусть кривой, но рабочий -велосипед, чем ждать, пока мудрейший доизобретет все «как надо».
                                +1
                                Runa Capital тебя сейчас поэкспериментирует )
                              0
                              А как вы оцениваете стоимость использования DynamoDB, она же до недавнего времени была дорогая ужасно!
                                0
                                С учетом стоимости DBA, она нас полностью устраивает.
                                  0
                                  В смысле стоимости его отсутствия? Ну да, при учете стоимости DBA около 100-150k$ можно на базе сэкономить.
                                    0
                                    Да :-)
                                +1
                                А какая нагрузка достается NodeJS? И сколько памяти при этом она потребляет?
                                  +2
                                  Демон потребляет от 300 до 600 мегабайт, сам все чистит, спасибо V8. По процессору нагрузка около 5-7 от EC2 small.
                                    +11
                                    А нагрузка в пользователях и коннектах в секунду какая?
                                      0
                                      Сколько демонов?
                                    0
                                    Расскажите про развертку, вы просто делали на сервере git clone ?
                                    Вы писали на чистом js или coffee script? Если кофе, то значит приложение собирали не на сервере, и нужен ведь алгоритм который позволит из того же гита брать только скомпилированные файлы.
                                    И как вы обновляете код на сервере, есть ли какая автоматизированная система?
                                      0
                                      Написано все на чистом JS'е. Выкладка делается руками, занимает 2 минуты, в будущем возможно сделаем deploy систему.
                                        0
                                        И при выкладке новой версии всех клиентов отключаете?
                                      0
                                      Для решения проблемы кросс-платформенности нами была выбрана библиотека Sock.JS. Во-первых, из-за соответствия стандартам W3C для WS, а во-вторых, Sock.JS отлично подходит для наших потребностей.

                                      Socket.IO рассматривался? Если да, то интересно чем не устроил?
                                        +1
                                        Обе библиотеки очень хороши. У Sock.js несколько кошернее реализованы fallback'и.
                                          +2
                                          А можно поподробнее про разницу?
                                            +1
                                            Порядок выбора транспортов:

                                            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. В этом случае все прокси видят зашифрованый трафик и вряд ли будут резать переход на другой протокол.
                                              0
                                              Только при использовании связки TLS + Socket.IO память течет ой-ой-ой как. Без объяснения причин :( И судя по многостраничным обсуждением этих проблем, им уже не один год и исправят ли, неизвестно.
                                        0
                                        А чем node адекватен в работе со streamами?
                                          +1
                                          Адекватен чуть более, чем полностью.
                                            +1
                                            Из опыта: нужно скачать с FTP сервера многогигабайтный файл, разгзипить, растарить, найти в архиве нужное, распарсить полученный XML, выжимку послать дальше.

                                            Реализовано на ноде без единого временного файла, на одних потоках.
                                            +2
                                            Есть хорошее видео www.youtube.com/watch?v=lQAV3bPOYHo
                                            Хотя докладчик в лучшем случае под гинко билоба)
                                            0
                                            Вообще очень радует, что вы выбрали эту технологию. Компании, использующие открытую технологию, делают вклад в нее.
                                            Расскажите о недостатках? Ранее вы на чем писали подобные вещи? Или это первый опыт? С node.js до этого имели дело?

                                            Хотелось бы так-же больше узнать про оптимизацию. Спасибо ;)
                                              –1
                                              Можно я тоже поделюсь, как недавний конверт в ноде? Недостатки:
                                              • яваскрипт неплохой язык, но синтаксис удручает. Лечится кофискриптом.
                                              • асинхронно-событийная модель ноде не всегда легко ложится в мозг. Надо всегда заботиться о том, как бы не заблокировать единственный тред, и любая (даже простая, типа чтения директории) операция выполняется не линейно, а с колбэком. Лечится звёздным модулем async.js, и некоторым опытом.
                                              • нету HAML/SLIM. Лечение: node-blade.
                                                отсутствие флагшип-фреймворков, типа Ruby on Rails. Пока не излечено, но как-то и не особо мешает. Голый REST не так уж часто подходит.

                                              • Преимущества: скорость! Более резвого я ничего не видел. Продуманность: потоки просто рулят. Интегрированная крипто-библиотека высокого качества (из OpenSSL). Поддержка сообщества, модули, значительное количество перешедших из рельсов, и взявших с собой лучшие практики. Отсутствие шизокодии: сервер и клиент пишутся на одном языке.
                                              +2
                                              Молодцы! Еще бы прекратили тихушные обновления сайта (без уведомления пользователей, что вообще происходит). А то постоянные бета-тесты на пользователях расстраивают. То одно сломается, то другое. Народ ругается.

                                              А обещанную среднюю и долгую память когда доделаете?
                                                0
                                                Спасибо!
                                                Уведомления с новостями реализуем.
                                                Средняя и долгая память в разработке, в течение месяца будет.
                                                +2
                                                Если не секрет — какая сейчас нагрузка у сервиса в rps?
                                                  0
                                                  Не совсем в тему, но как-то странно у вас скидочная политика работает: например, я хочу купить Золотой статус на год и Программу для начинающих. Если я это делаю на свой аккаунт у меня получается, с учетом скидок, 990 + 690 (вместо полных 2400 + 1485), а если я хочу купить в подарок, то скидка только на годовой статус (990 + 1485). Это баг или фича?:)

                                                  Кстати, несовсем корректно работает переключалка языков, при самом первом заходе на сайт язык стоит английский (видимо, из локали), но переключатель в позиции Русский язык. (Version 26.0.1410.63 Chrome)
                                                    0
                                                    >Кстати, несовсем корректно работает переключалка языков, при самом первом заходе на сайт язык стоит английский (видимо, из локали), но переключатель в позиции Русский язык. (Version 26.0.1410.63 Chrome)

                                                    Это потому внутри есть два понятия «языка»
                                                    1) язык интерфейса
                                                    2) родной язык пользовтеля
                                                    а переключатель один =)

                                                    у вас в хроме выставлен английский интерфейс (английская локаль), поэтому отображается на Английском
                                                    но при этом вы из России и пришли на lingualeo.ru поэтому скорее всего ваш родной язык русский

                                                    переключатель отображает «родной язык»
                                                    в настройках профиля можно выбрать и настроить тот который захочется
                                                      0
                                                      Почему тогда, если в этом же выключателе, и так стоящем на положении русский язык, снова выбрать русский язык — сменится язык интерфейса (речь о заходе на сайт без логина)?
                                                        0
                                                        там другая логика
                                                        переключатель меняет «родной язык» и устанавливает наиболее подходящий для выбранного «родного языка» «язык интерфейса»
                                                    0
                                                    Не работает, бесконечная загрузка :(. Браузеры: хром, фф, ие, последних версий.

                                                    Думал виндовый фаер блочит, выключил — так же бесконечная загрузка.
                                                    0
                                                    Замечательное описание внедрение технологий. Интересно было бы ещё узнать, в какие сроки вам удалось вложиться.
                                                      +3
                                                      Здесь должен был быть Go lang, а не node.js.
                                                      Тогда было бы быстрее и не 600 Мб ОЗУ, а 6.
                                                        0
                                                        Язык хороший, но либ мало, по этому они бы убили кучу времени на каждый чих.

                                                        P.S. Да я знаю, что судя по спискам либы есть для всего и вся, но они или мало поддерживаются, или вообще заброшены и ни кому не нужны, в большинстве своем. Такая уж печальная ситуация. А основатели судя по всему будут и дальше заниматься только самим языком, все остальное по их мнению должно делать сообщество.
                                                        +3
                                                        Кроме того, грамотный JavaScript-программист, работая на Node, сможет реализовать весь объём задачи, а не только её серверную часть (в отличие, например, от специалиста по Erlang).


                                                        Люди, очнитесь уже, ваш NodeJS это сборище костылей, разной степени тяжести.

                                                        Специалист на Erlang, напишет серверную часть, на порядок грамотнее и лучше, чем js разработчик.
                                                          +2
                                                          А так же дольше, а потом он не заменим.
                                                            +1
                                                            Дольше? Вы пробовали писать на erlang? Язык очень простой, с отличной, стабильной платформой, в отличии от.
                                                              +3
                                                              Пробовал, досихпор кошмары сняться. Дольше потому, что все надо будет делать самому, ибо модулей практически нет. Нет удобного средства контроля зависимостей (rebar смешен и не все библиотеки цепляет). А так же все еще нет удобного вэб фрэимворка (ну аксиом не плох), приходится писать на вэб-сервере :)

                                                              Забавно, когда начинает указывать на недостатки ерланга, выясняется, что он не для вэба и максимум для rest сервисов. Но приэтом каждый раз в топике про node.js говорят, что надо было на ерланге писать.
                                                                +1
                                                                выясняется, что он не для вэба и максимум для rest сервисов


                                                                А чем REST для веба не устраивает?
                                                                  0
                                                                  Под «вебом» видимо имелись в виду классические html/css/js для «сложных» сайтов, где на одной странице обычно отображается куча несвязанных динамических формируемых разнотипных сущностей (которые в «канонических» (XML, JSON и т. п.) rest-ответах отсутствуют) типа навигации, рекламы, информеров, личных кабинетов, в общем всяческих хидеров, футеров и сайдбаров, а раскладки для них базируется на мощной системе шаблонов (хотя бы в голове у дизайнера). Без поддержки такого html-рендеринга со стороны фреймворка как-то грустно становится. В обработчике запроса нужно «ручками» анализировать «тип» запроса (например, /user/volch.html или /user/1.json) и вытягивать или один объект или коллекцию, или вдобавок к ним кучу всяких «лучшие темы», «последние комментарии» и т. д. Приложению (одностраничному веб или «нативному» — не суть) не сложно все нужные запросы по одному отправить, даже если оно отображает то же самое, что сайт. А вот сайту нужен механизм сбора страницы из шаблонов, так чтобы шаблон мог независящие от параметров запроса данные сам вытащить из приложения.

                                                                  Сумбурно объяснил, но, надеюсь, понятна основная мысль, что без поддержки со стороны фреймворка чистота рест-контроллеров сильно нарушается.
                                                                    0
                                                                    В обработчике запроса нужно «ручками» анализировать «тип» запроса (например, /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 — прикрутили. И т.д.
                                                                      0
                                                                      Ок, только при чем тут REST тогда? Если у вас запросы на /user/volch.html отдают коллекцию, а /user/1.json — объект, то что-то не так спроектировано (по крайней мере, с точки зрения REST resources).

                                                                      Они отдают один и тот же объект точки зрения REST, но по разному представленный, а, главное, по разному декорированный.
                                                                      По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.

                                                                      Скорее это DDD в чистом виде. Пришел к обработчику запрос на объект типа такого-то с id таким-то, он его от модели получил и отдал рендереру. От того, что дизайнер или менеджер решил добавить на страницу ещё какой-то объект модели, с запросом не связанный, разве должна меняться логика rest-контроллера?
                                                                      По описанию похоже на какой-то шаблон-driven development. Обычно наоборот делают — приложение отдает шаблону все, что нужно.

                                                                      Судя по ощущениям (и личным, и наблюдениям) к фреймворкам на языках типа Erlang или JavaScript мощные html-шаблонизаторы плохо прикручиваются, когда речь идет о сборе независимых данных в один ответ. Они (фреймворки) хорошо работают в ситуациях канонического REST, когда возвращается один объект или коллекция однотипных объектов, желательно в минимально изменяющемся формате. Но в мире сайтов, многостраничных веб-приложений, это редкость — обычно на один запрос кроме цели запроса нужно возвращать и кучу «служебных» объектов, причем и их набор, и их представление, и их компоновка могут меняться очень часто, и в идеале эти изменения должен быть способен сделать дизайнер или менеджер, которым программист дал какое-то «API».
                                                                        0
                                                                        На мой взгляд, «плохо прикручиваются» потому что там где их активно используют никому это не нужно.
                                                                          0
                                                                          Хотя и сложно вас читать без запятых, но полностью согласен — с помощью, грубо говоря, «ФП» пытаются(емся) реализовать структуры ему «неизвестные». И хорошо если заметим фактическую и теоретическую (воздаю дань должности Имперскому Флоту уже не существующей империи) оценку ресурсов.
                                                          +1
                                                          У Вас же бэкенд на php написан, пробовали phpDaemon? Если да, то чем не устроил?
                                                            0
                                                            вместо phpDaemon
                                                            я думаю лучше www.phpReact.org ;) он интереснее
                                                              0
                                                              под php нет серверной части для sockjs
                                                              0
                                                              Мы помним об этом, и для WebSocket-соединения используем порт 443 (без привязки к https). Это решение позволяет избегать возможных сетевых проблем.

                                                              А почему не через 80 порт, благо Nginx теперь позволяет?
                                                                0
                                                                судя по заголовкам на dialogs.lingualeo.com нет nginx
                                                                0
                                                                Каким образом вы решили вопрос с транзакциями?
                                                                  0
                                                                  =) а где конкретно в диалогах «транзакции»?
                                                                  и что вы подразумеваете под этим словом?

                                                                  в чем заключаются на ваш взгляд «проблемы»?
                                                                    0
                                                                    Конкурентное обновление группы данных
                                                                      0
                                                                      конкуретное обновление в данном случае не требуется, при добавлении сообщения, в DynamoDB просто добавляются Item по HashKey для соответсвующего dialogID

                                                                      максимум требуется атомарный инкремент (если хранить длину сообщения)…
                                                                      его можно сделать через внешние локи по ключу (опять же dialogID например на redis), но нагрузка не настолько большая…

                                                                      а с учетом того что сервер nodejs одно-поточный и используется nodejs+sockjs… то возникновение необходимости обновить кол-во сообщений в диалоге одновременно от двух клиентов, очень мала

                                                                      если говорить про DynamoDB то там все просто, это не ACID хранилище и консистентности там нет, зато очень высокая доступность и низкая latency, достаточно стоимость низкая (по сравнению с остальными сервисами типа EC2 или RDS) и приемлимое API для определенного вида выборок =)

                                                                Only users with full accounts can post comments. Log in, please.