Comments 35
А можно просто:
$ npm install express-generator -g
$ express --view=jade myapp
Я храню сессии в REDIS, думаю он быстрее будет, чем MongoDB. Так же сессии можно хранить в мастер процессе используя strong-store-cluster библиотеку. Делал сравнительные нагрузочные тесты с десятками миллионов сессий, редис будет по быстрее, чем хранение в мастере.
Кластеризацию я предпочел делать используя strong-cluster-control, она позволяет автоматически делать рестарт воркеров, если те упали по той или иной причине. Так же, очень важный аспект этой библиотеки в том, что можно произвести тихий (без даунтайма) рестарт воркеров, что очень актуально при апдейте сервера (не мастер части). Причем она запускает сначала воркер, и если тот удачно стартанул, то дает сигнал на нормальное завершение работы старого воркера (т.е. пока есть зависшие процессы в нем, он не выгружается, ну и новые реквесты к нему не отправляются). И так для всех воркеров.
Redis это хорошо, но я решил не усложнять все. Ибо архитектура и так сложная, а изменить архитектуру добавив редис можно за 5 минут.
Что такое "асинхронные потоки"?
cluster использует fork().
Например в строке
app.use(require(...)) мне захотелось ударить вас :-)Нужно всегда делать в начале файла
const module = require('module') и уже потом использовать егоКаждый require синхронный и, очевидно, блочит весь процесс
Вопрос. Если все worker-ы симметричные, то не проще было ли писать приложение без cluster (особенно учитывая что усложнять пример не хотелось), а запускаться потом через PM2? Там и gracefull reload, и cluster, и auto restart, и даже логи в реальном времени.
И таки для request request-promise, которые для тестирования кода, лучше таки --save-dev использовать.
Кто-нибудь может сказать, зачем писать на express, когда уже давно можно писать на koa?
И да, коллбеки — отстой.
А зачем писать на koa, если есть express? Различий не увидел, кроме this.req вместо req и все :)
В основном потому что есть опыт с express ом.
И да вы где ты коллбеки увидели? Все в проекте на обещаниях… (практически)
Ну и ещё Koa — это больше connect, нежели express.
Посмотрел я Koa. Идея хорошая использовать yield next() и прочее вместо классических коллбеков. Хотя сам против таких вещей как yield т.к. они усложняют понимание кода фронт енд разработчикам :).
Писать код в синхронном стиле хорошо с использованием async/await.
Генераторы я вообще не понимаю для кого и зачем сделаны. Их дизайн сделан настолько плохо,
что вернувшись к функции которую написал 15 минут назад, уже не понимаешь что она делает.
Это похоже на такой задел под ленивые вычисления, который не довели до конца.
Генераторы были сделаны для того, чтобы упростить написание итераторов. Просто они оказались нужнее в другом месте.
Асинхронные функции пока что всё равно реализуются через них. Не вижу ничего плохого.
А я вижу. В асинхронном async/await сразу понятно, что происходит. А что происходит с генераторами? Они просто сложны. И сложны они на пустом месте. Я ПРОТИВ генераторов т.к. они НЕ для этого предназначены. А вот async/await веб фреймоворк, да пожалуйста!
Генераторы были сделаны для того, чтобы упростить написание итераторов.
Звучит как масло масляное, что дальше то делать с этими итераторами? Разработчики ES6 этим функционалом предоставили просто аппендикс для работы с ленивыми структурами данных, но в сам язык никакой удобной их поддержки не предоставили. Для декларативного описания обработки коллекций по прежнему проще использовать сторонние либы по типу "Stream.js". Сообщество просто покрутило эту штуку и пристроило куда могло, то что генераторы решают проблему callback hell красивее чем целый ряд изобретенных до этого костылей, сомнительно. В любом случае в Node.js 7.0.0 подвезли async/await и использованию генераторов для написания синхронного кода, нет никакого оправдания.
Рано вы про нативную имплементацию заговорили. Нода 7й версии ещё только релизнулась, да и поддержка асинхронных функций работает пока только с флагом.
Рано? Самое время… Не хотите флаг используйте обещания. Хотите асинхронности, то только async/await все остальное так-же плохо, как использовать коллбеки если есть промисы.
Асинхронные функции удобные, зачем от них отказываться? А что там под капотом транспайлера происходит — без разницы. Когда нода начнёт поддерживать всё это дело без флага, можно будет просто убрать компиляцию и пользоваться уже нативно. При этом не придётся переписывать код, чтобы работать уже с асинхронными функциями.
Если есть возможность использовать Babylon или похожие, то async/await однозначно. Если нет то обещания. Не надо делать костыли. Можно, но плохо.
А вы про какой babylon?
Извиняюсь babel. :)
Есть еще Hapi, Sails, Kraken
А еще можно взять роутер из PillarJS и использовать чистый http.createServer()
Мы, в JavaScript мире, всегда имеем выбор, и если не из чего выбрать, то делаем свою игрушку
И нужно ценить выбор других, а не кидаться вопросом "зачем"
И да, против async/await ничего не имею, когда есть возможность, то тыкаю, но это не панацея, так как по сути промисы это красивая обертка над колбеками
Делаем проект на Node.js с использованием Mongoose, Express, Cluster. Часть 1