proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-NginX-Proxy true; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_redirect off;

у меня вот так работало. тебе для ws?

proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-NginX-Proxy true; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_redirect off;

нет, я хочу отловить prefetch (preload) хэдер и передать его express

А как у тебя хидер зовется?

а без nginx прокси работает?

X-Moz: prefetch (Mozilla), X-Purpose: preview (Safari, Opera), and X-Purpose: instant (Chrome)

а без nginx прокси работает?

хз)

ну офигеть)) так ты проверь без nginx

ну офигеть)) так ты проверь без nginx

поясни пожалуйста как по быстрому это можно проверить?

console.log(req,headers)

блин. затупил. все верно. нет, без nginx не работает

а как ты посылаешь этот хидер?

а как ты посылаешь этот хидер?

пока никак, по идее нужно сделать что-то такое proxy_set_header X-Purpose <variable>; так вот я не знаю как эту variable указать. Либо я что-то не так понимаю. Поясните пжлст)

в доке nginx не нашел ничего

как ты клиентом посылаешь этот X-Purpose?

Сейчас для теста

я никак не посылаю, этот заголовок же браузер вроде прокидывает

эммм ну так ты пошли его лучше руками для тестов чем надеяться на браузер

понял, попробую. ну а как потом быть?

А кто нибудь собирает node.js приложение в один файл на продакшене?

webpack/browserify

Серверную часть?

да

зачем?

зачем?

+1

Зачем х3?

оптимизации через closure compiler, например

Хм. А можно пример таких оптимизаций?

// foo.js module.exports = 1; // bar.js const foo = require('./foo'); if (foo) { // do something } else { // do something else } // bundle.js // do something else

для реакта 1 из советов для ускорения брать react/dist/react.min.js в продакшене с серверным рендерингм. process.env.NODE_ENV === 'production' - не самая дешевая проверка

можно не плохо так помочь движку убрав код, который никогда не выполнится в общем

Движку на этот код в целом наплевать так-то

Житы всякие?

Да и ради простейшего инлайна всё усложнять

Дык, в жите не просто так два компилятора, ага

Ну вот и мне так показалось)

Для клиента оно понятно, бандл уменьшим

угу

А для ноды не совсем

совсем не

можно не плохо так помочь движку убрав код, который никогда не выполнится в общем

Вы не меряли разницу?

Ну тут как посмотреть. Если используется какой-нибудь babel или typescript, то есть всё равно sourcemap вкручивать, то мб и есть смысл. Но если чистая нода, то хз

Стало ли быстрее или медленнее?

Ставлю на то, что разница на уровне погрешности

Ну тут как посмотреть. Если используется какой-нибудь babel или typescript, то есть всё равно sourcemap вкручивать, то мб и есть смысл. Но если чистая нода, то хз

Так а зачем бандл собирать? В крайнем случае каждый файл отдельно закомпилить, а так require хук наверное

Ну речь о том, что если всё равно sourcemap'ы генерить, то разница уже нет по одному файлы или в бандле. И тогда если времени сборки не жалко, впилить closure вполне можно, только я не думаю, что там разница будет хоть какая-нибудь

эм, я говорю вам, берем react с NODE_ENV=production и берем реакт минифицированный, без проверок вообще, получаем буст

Пруф?

Ну не верю я, что при такой проверке, которая везде в одно и то же разворачивается, ни компилятор, ни брэнч-предиктор в процессоре не раскурят

она не в одно и то же разворачивается, если не ошибаюсь

env переменные вроде рантайм можно менять

это значит что там геттер, а геттеры нельзя заинлайнить

там разве геттер, а не просто свойство?

https://github.com/facebook/react/issues/812

Ну даже если так, брэнч-предиктор никто не отменял

ну окей, а где бенчмарки-то?

https://www.youtube.com/watch?v=PnpfGy7q96U

доклад в тему

надо бенчмаркать свой код, а не чужой

Ну для своего проводил?

Мне действительно интересно почему есть разница, если она есть

не, я верю в логику

но вот тебе бенчмарки

Чем отличается второй и третий вызовы?

Я пока не понял на что это бенчмарк? На то, что с production оно быстрее работает? Ясен пень. Вопрос же про ускорение за счёт вырезания условий

ERROR: S client not available

Ну ты дай JIT'у разогнаться

Тут же смысл с нуля тестировать особо нету

да и нет тут теста, соб-но

Чем отличается второй и третий вызовы?

Видимо со dom-stream и без

Кстати dom-stream не факт что будет быстрее на мелких аппах)

И еще интересно было бы все это сравнить вот с этим https://github.com/airbnb/hypernova

airbnb отказались от alt-iso в пользу этой штуки

зачем?

Хотел не делать на слабой виртуалки npm install. Очень долго ставится и памяти не хватает. Спасате только swap.

Видимо со dom-stream и без

не

1 - NODE_ENV=development

2 - NODE_ENV=production

3 - NODE_ENV=production и react/dist/react.min

Сколько на разогрев было выделено?

Хотел не делать на слабой виртуалки npm install. Очень долго ставится и памяти не хватает. Спасате только swap.

Какой версии npm?

Какой версии npm?

3.10.3

Он не должен параллелить установку, насколько я знаю.

Там виртуалка 1 ядро и 1гб памяти. Выжирается полностью всяпамять и почти 1гб swap-а

эээ

у нас воркеры на проде работают с такой конфигурацией. Правда их 4 штуки, но тем не менее

в том и суть - npm отжирает очень много

ааа, мы npm на клиенте запускаем, а потом отправляем уже собранные пакеты.

Ой. Сюда можно код вставлять?

console.log('Hello, World!');

ну да)

Только что узнал.

Случайно причём.

Поздравляю

Всем привет! Для тех, кто пропустил, напоминаю - в среду, 19:00, состоится 8-й Moscow Node.js Meetup. В этот раз он пройдёт в Яндексе. Успевайте зарегистрироваться: + https://events.yandex.ru/events/yagosti/13-jul-2016/

Количество регистрации уже превысило 100 человек, поэтому Яндекс нам выделил большой зал. Это значит, мы можем позволить больше гостей. Друзья, помогите донести информацию о митапе - сделайте ретвит: + https://twitter.com/DenisIzmaylov/status/751415655056961536

http://www.opennet.ru/opennews/art.shtml?num=44752

Набрасываешь?

"Ни один нормальный язык программирования не может быть логичным продолжением Си, поскольку логичное продолжение фундаментальной ошибки - это фундаментальная ошибка. Примером тому может служить язык Go - желание сделать его нормальным привело к тому, что от Си там мало что осталось. Напомню, одним из авторов Go является Кен Томпсон - автор языка Би, а, следовательно, соавтор Си. И как тогда появилась книга Кернигана и Ричи для С, так и теперь появилась книга Кернигана и Донована о Go. В отличии от многочисленных неофитов, корифеи хорошо понимают цену своему поделию, создаваемое ими под конкретные задачи в 70-х, а не на века. Сколько убийц Си всего было? Десятки, ведь. И не взлетели. Потому что они методологически создавались неверно, всякими возомнившими из себя невесть что. Страуструп создал C++, и назвал его C++. Не D, не E и не Z, а C++. Умные люди посмотрели на C++, и поняли, почему время для D ещё не пришло. Глупые не поняли, и застолбили букву D, под какую-то фигню, которая не несла в себе ничего нового, они просто слили в один флакон, всё что они в детстве слышали о языках программирования от бабушки, не имея никакой другой объединяющей идеи. Они даже не подумали о том, что Страуструп, скорее всего, знал всё, что они знают о программировании, но почему-то не включил это в язык. Им в голову не пришёл вопрос "почему так". Они просто взяли и создали язык программирования потому, что могли создать язык программирования. И все последующие "убийцы" C, включая и Go тоже, точно так же не имели никакой идеи заложенной в них. Кроме, быть может, идеи "убить C", но это деструктивная идея и потому провальная. Отсутствие конструктивной идеи — практически наверняка провал. Бывали в истории языков программирования безыдейные исключения, добившиеся популярности, но их не так уж и много. Сегодня же время пришло. C++ долго вынашивал идеи. Сильно разные идеи, которые рождались и развивались в нём: Страуструп запилил достаточно богатый на возможности язык, чтобы там можно было дрочить вприсядку так, как это описывал Александреску. И сегодня эти идеи доросли до уровня, когда они имеют самостоятельную ценность. Rust взял одну из них, и построил вокруг неё идеологию, подчинив всё развитие языка автоматическому управлению памятью в compile-time. И именно поэтому Rust имеет шансы убить Си, в то время как Go — нет. Никакие миллиарды гугла не помогут Go, потому что Go безыдеен. В силу этих миллиардов, Go, может быть, отъест себе какую-нибудь нишу, типа как это случилось с Java, но на что-либо большее ему надеятся не приходится. Rust же как раз имеет все шансы подвинуть и C, и C++. Вытеснить их не удастся в обозримом будущем, но подвинуть их — вполне. Единственное, что может ему помешать — это кривая обучения: там реально может быть сложно въехать, если не понимать что, зачем и как сделано. А без этого понимания будет невозможно написать код, который компилятор сочтёт правильным. Собственно, если посмотреть вопросы, которые задают ньюфаги, то они неплохо демонстрируют. И бесполезно сегодня ссылаться на корифеев, которые облизывают Го. Корифеи остались в прошлом, их область экспертизы где-то там. Что Керниган, что Александреску — они слишком много интеллектуальных усилий вложили в те задачи, на которых они стали известными, и судя по всему, они уже ни на что новое больше не годны. Ну, или может быть дело в том, что просто гугл им приплачивает, чтобы Го ассоциировался с их именами. PR своего рода. Что какбэ лучше всего остального говорит об отсутствии потенциала у Го: если ему нужны подпорки в виде авторитетов для того, чтобы выглядеть перспективным, то... нахрен он такой нужен?"