грубо говоря эти скрипты выполняются по порядку

накатывая все изменения на базу исторически

и тогда ты получаешь последнюю версию

без потери данных

и тогда можно обновляться с любой версии на любую нажал я npm update myapp

и получил в preinstall апдейтики

я пока так планирую

ну как вариант, но хотелось бы в более сжатом виде, так сказать для чайников :)

http://stackoverflow.com/questions/25568613/node-js-event-loop Допустим, если для чайников

Вам скорее всего не нужен, но есть такая штука как event sourcing (типа как redux на клиенте). Там достаточно просто удалить все данные, кроме ивентов и рестартануть ивенты

А так запилите коллекцию с миграциями, куда пишите последнюю версию схемы. Скрипт запуска миграций такой: взять последнюю версию из базы, взять из папки все более новые миграции и накатывать по одной

В миграцию есть смысл добавлять две команды - up и down. Если потом придётся откатывать

http://stackoverflow.com/questions/25568613/node-js-event-loop Допустим, если для чайников

как евентлуп работает я знаю. меня интересует как многопользовательские стейты разруливаются

выносятся в отдельные микросервисы, с возможностью блокировки операции записи

как евентлуп работает я знаю. меня интересует как многопользовательские стейты разруливаются

Можешь ещё раз вопрос сформулировать?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

короткие?

да, электрические

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

Да, наверняка суть вопроса была в этом

Можешь ещё раз вопрос сформулировать?

вопрос в следующем - в пыхе когда приходит коннект от браузера, хедеры всякие, сам реквест, будь то гет или пост или что еще, скрипт отрабатывает, отдает результат и завершается, с полной очисткой памяти. поэтому искаропке в пыхе нет и не бывает никакого стейта, каждый раз приходится с клиента куку слать, парсить ее, сессию из файла или еще откуда таскать и прочие ужосы. в ноде все иначе, плюс коннект может не обрываться, в частности для СПАхи с кучей аякса это вообще гут. Плюс пока процесс крутится, он хранит весь стейт. Т.е. вот ты запустил node index.js допустим и доколе скрипт не завершит выполнение всех-всех-всех операций либо не крашнется, стейт сохраняется, а если мы в скрипте запустим веб-сервер, который слушает порт, то все, пока скрипт не крашнется или по CTRL-C Или как еще не отвалится, стейт хранится. При этом на порт лосятся клиенты с разных браузеров, т.е. один и тот же скрипт обслуживает кучу разных запросов. Я нутром чую, что для каждого отдельного коннекта стейт хранится отдельно, иначе это была бы вакханалия. Вопросов два - евент луп единый для всех коннектов или тоже по лупу на каждый коннект? И насколько сильно изолированы стейты, могут ли они сообщаться с ведома скрипта?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

есть общий стейт - это все переменные в скрипте

а есть стейт реквеста - он в обработчике

т.е. я правильно понимаю что на потоке единый стейт на все коннекты?

Я, кажется, понял. Чувак, а ты знаешь как работают замыкания?

канэшна дарагой :)

например, если ты делаешь скрипт var players = []; app.post(‘/addPlayer’, (req,res)=>{ players.push[req.body.name] }) то в players будет общий стейт

и поток один

т.е. любой коннект в потенциале может получить доступ к этому общему стейту?

Что такое стейт? Есть переменные и есть их область видимости. Обработчик запроса — функция. Всё, что было в функции, остаётся в функции.

т.е. любой коннект в потенциале может получить доступ к этому общему стейту?

да

стейт это все переменные запущенного скрипта

вообще все

Он на то и общий какбэ

понял, мерси

хотя одну штуку не догоняю я еще

вот 100 бразуеров ломятся на порт

т.е. 100 коннектов имеем

и для каждого надо сходить в бд

т.к. все асинхронно и евент луп

непойми когда что отработает

допустим коннект к бд имеем один

на всех

через него для каждого лезем

т.е. шлем в базу 100 запросов

ответы прилетают в переменные

название переменной по сути будет единое для всех

получается действительно только замыкания спасут отца русской демократии

Давай я расскажу как я понимаю, а товарищи меня поправят, если я где фигню сморожу 1) Приложение запускается и висит в памяти, загрузив все модули. 2) Для каждого клиента запускаются нужные ему обработчики и они всю его фигню хранят в замыканиях, то есть в памяти. Обработчики имеют доступ и к переменных верхних скоупов. 3) Клиент отваливается — сборщик мусора всё это дело прибирает. Количество обрабатываемых клиентов упирается только в память для хранения их переменных.

А приложение на всех одно

ответы прилетают в переменные

Ответы прилетают в обработчик и падают ему в замыкание. Соседний вызов этого обработчика для другого клиента этого ответа никогда не увидит.

Ну, если его специально не прокинуть в общий скоуп

Нужно не забывать о том, что обработка в node происходит в один поток. Это означает, что никакого «соседнего» вызова нет. Есть более ранний и более поздний вызовы.

Нужно не забывать о том, что обработка в node происходит в один поток. Это означает, что никакого «соседнего» вызова нет. Есть более ранний и более поздний вызовы.

Ну да, я их и имел в виду

Соседний вызов === соседнее замыкание

Вернее даже, соседний асинхронный отложенный вызов, который ещё ждёт своего выполнения

Допустим есть обработчик запроса (псевдокод, похожий на express.js): app.get('/example', (req, res, next) => { console.log('Request handler started'); dbRequest(req.query, (err, data) => { console.log('DB request ended'); }); console.log('Request handler ended'); }); К моменту, когда начнет выполнятся обработчик для второго вопроса, выполнение этой функции для первого запроса уже будет завершено.

Здесь нужен стикер со сборщиком мусора

Допустим есть обработчик запроса (псевдокод, похожий на express.js): app.get('/example', (req, res, next) => { console.log('Request handler started'); dbRequest(req.query, (err, data) => { console.log('DB request ended'); }); console.log('Request handler ended'); }); К моменту, когда начнет выполнятся обработчик для второго вопроса, выполнение этой функции для первого запроса уже будет завершено.

но ее стейт сохранится

Смысла держать замыкание из обработчика в результат выборки из БД нет, т.к. ответ на клиента все равно надо отправлять из колбека запроса к БД.

Сможете привести пример стейта, который нужно было бы из колбека dbRequest передать в обработчик?

Вдруг я что-то упускаю из виду

* то, что req, res, next в замыкании, понятно. Я имею ввиду какие-то дополнительные переменные.

Ребят, кому еще прилетело про https://medium.com/@deian/63e6e0a566a7#.8dlz2whq5?

Только на неделе думал, насколько сложно закинуть зловред в NPM

несложно было всегда

есть же пост/пре-инстал хуки

ERROR: S client not available

Можно скомпилировать ещё что нибудь

и запустить на тысячах чужих CI

Я представляю, как бы бомбануло, если бы left-pad не выпилился, а делал чтонибудь эдакое

Ребят, кому еще прилетело про https://medium.com/@deian/63e6e0a566a7#.8dlz2whq5?

Общий смысл статьи: пользуйтесь только https

Я представляю, как бы бомбануло, если бы left-pad не выпилился, а делал чтонибудь эдакое

парень то все правильно сделал. Его код же. Без зловреда по отношению к сообществу

Про смысл статьи я понял. Вопрос в том, что письмо от этого товарища всем мейнтенерам в репе npm прилетело?

Общий смысл статьи: пользуйтесь только https

эм. это не поможет пока не отключишь компиляцию бинарников

парень то все правильно сделал. Его код же. Без зловреда по отношению к сообществу

удалить все пакеты, это так себе идея

эм. это не поможет пока не отключишь компиляцию бинарников

Как минимум проверять пакеты и фиксировать версии же. В стетье речь идет о возможной подмене источника пакета же, так

смотри синдре, сабстек и зкат удалят свои пакеты и чо будет?

Как минимум проверять пакеты и фиксировать версии же. В стетье речь идет о возможной подмене источника пакета же, так

как фиксировать версии пакета?

удалить все пакеты, это так себе идея

ну это их право. это их собственность если они не принимали чужой вклад

тем более что один из пакетов

npm и так фактически удалил

как фиксировать версии пакета?

npm shrinkwrap же, нет?

npm shrinkwrap же, нет?

он сломан

Вот же

Весело

Все держится фактически на взаимном доверии и соплях

допустим он лочит бинарники os regardless

зашринкврапишь на винде

на маке не будет работать

Как вариант еще bundleDependencies, проверяешь сборку в изолированной среде, пакуешь и в бой

и с бандл/пир депсами шринкврап тоже плохо работает

Все держится фактически на взаимном доверии и соплях

так бизнес и ведется ну + государство но нашему никакого доверия нету

ахахах

так бизнес и ведется ну + государство но нашему никакого доверия нету

А потом рыдаем - ну как же так... да

Как вариант еще bundleDependencies, проверяешь сборку в изолированной среде, пакуешь и в бой

бандл депсы основной проблемный кейс для шринкврапа

Короче везде засада

А потом рыдаем - ну как же так... да

зачем рыдать? делаем выводы - живем дальше. ну бизнес то тоже всегда отжать могут

зачем рыдать? делаем выводы - живем дальше. ну бизнес то тоже всегда отжать могут

Не знаю. Рыдают же.