что сделать то надо

уже потерял

200k елементов в цикле перебрать, и во вложенном цикле еще 100k

http://stackoverflow.com/questions/11874096/parse-large-json-file-in-nodejs

вот что советуют

http://stackoverflow.com/questions/11874096/parse-large-json-file-in-nodejs

Как раз мой случай!) Спасибо!!!

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

? Другой вопрос интересный. При разработке больших приложений, часто необходимо управлять конфигурацией. Например: + для develop разрешить Source Maps + для stage разрешить логирование на специальный + иметь для разных сред (develop, stage, prod) разные внешние сервисы логирования, и токены для них + отключить какие-то features для develop, но включить их для prod + иметь разные пресеты конфигураций одного приложения для разных продуктов/клиентов + разные стили / логотипы / описания + разные наборы языков (например, когда новый язык ещё в разработке, он может быть в stage, но не в production) + поддерживать только определенные языки на develop Таких настроек может быть несколько десятков в крупном приложении. Часть из них могут быть доступны для переопределения через ENV. Кто как решает это? Какие практики и подходы есть в других экосистемах (Ruby, Elixir, Python и пр)?

я имею несколько нужных файлов конфигов js/json, мержу их между собой юзаю dotenv и dotenv expand окружение подгружается двумя переменными: NODE_ENV для development/production/test и APP_ENV для stage, public, nightly

я имею несколько нужных файлов конфигов js/json, мержу их между собой юзаю dotenv и dotenv expand окружение подгружается двумя переменными: NODE_ENV для development/production/test и APP_ENV для stage, public, nightly

Лакшери, круто. Интересно, какие ещё интересные практики есть?

Да в принципе тож самое. config, NODE_ENV+APP_ENV, реврайт через NODE_CONFIG

я имею несколько нужных файлов конфигов js/json, мержу их между собой юзаю dotenv и dotenv expand окружение подгружается двумя переменными: NODE_ENV для development/production/test и APP_ENV для stage, public, nightly

У нас есть настройки по умолчанию и PRESET, который их переопределяет, т.е: 1. Сборка проекта: NODE_ENV=production PRESET=google-stage npm run build 1. Запуск проекта: NODE_ENV=production PRESET=google-stage npm run start

не имею понятия, что тут твориться но стало интересно

У нас есть common-конфиги, содержашие некую общую конфигурацию или значения по-умолчанию. Есть отдельные patch-конфиги для каждой из сред. Работа с конфигами инкапсулирована в свой небольшой модуль-велосипед, поэтому никто напрямую require('./my_kewl_env.json') не пишет. Окружение тоже переключаем по NODE_ENV + специфичная переменая, уточняющая путь резолва конфигов.

мне кажется, или все велосипедят config?

конфиги это сложно. видел одного он писал свой лисп для конфигов

Я года полтора назад писал валидатор конфигов на основе JSON Schema, чтобы нельзя было запустить проект с невалидными конфигами. Со временем пришли к текущей архитектуре — common + patch. Она оказалась удобнее для разработки — внесение правок в схему у команды всегда сопровождалось болью.

process.hrtime() return undefined wtf?

Я года полтора назад писал валидатор конфигов на основе JSON Schema, чтобы нельзя было запустить проект с невалидными конфигами. Со временем пришли к текущей архитектуре — common + patch. Она оказалась удобнее для разработки — внесение правок в схему у команды всегда сопровождалось болью.

Вот у нас такая же схема :)

Ну да, все ведлсипедят :(

У нас есть common-конфиги, содержашие некую общую конфигурацию или значения по-умолчанию. Есть отдельные patch-конфиги для каждой из сред. Работа с конфигами инкапсулирована в свой небольшой модуль-велосипед, поэтому никто напрямую require('./my_kewl_env.json') не пишет. Окружение тоже переключаем по NODE_ENV + специфичная переменая, уточняющая путь резолва конфигов.

Мы сделали тайп-кастинг - приведение типов, но валидацию тоже думаем прикрутить, чтобы сразу ошибку выдавать, если что-то пошло не так.

Я года полтора назад писал валидатор конфигов на основе JSON Schema, чтобы нельзя было запустить проект с невалидными конфигами. Со временем пришли к текущей архитектуре — common + patch. Она оказалась удобнее для разработки — внесение правок в схему у команды всегда сопровождалось болью.

Можешь поделиться?

Увы. NDA )

Омг

Фрагмент кода общего назначения под NDA? :)

Увы. NDA )

Даже валидатором нельзя?

Ну, не совсем NDA. Скорее ODA — Owner Doesn't Allow )

Сюда его, на ковёр :)

https://www.npmjs.com/package/app-config

вот чё нашл

Попробую глянуть в истории репо, можно ли извлечь те наработки. Мы за это время успели выйти из MVP в нормальный прод, поэтому код очень сильно поменялся.

Бля, да о чём вы все?

https://www.npmjs.com/package/config

Ну уж конфиги то не надо велосипедить!

конфиги в стиле феникса: https://github.com/phoenixframework/phoenix/tree/master/installer/templates/new/config в стиле рельсов: https://github.com/rails/rails/tree/master/railties/lib/rails/generators/rails/app/templates/config/environments также в своих проектах не связанных с фреймворками использую: http://stackoverflow.com/questions/14184971/more-complex-inheritance-in-yaml и https://github.com/markbates/configatron

а вот статья от того самого товарища

http://letrectruth.ml/posts/cpp-snafu-conclusion.html

https://www.npmjs.com/package/config

ага поэтому мы у себя их и велосипедим для микросервисов ;)

https://goenning.net/2016/05/13/how-i-manage-application-configuration-with-nodejs/

из того что я помню node-config не умеет сбрасывать кеш и работать нормально с кастомными env переменными

? Другой вопрос интересный. При разработке больших приложений, часто необходимо управлять конфигурацией. Например: + для develop разрешить Source Maps + для stage разрешить логирование на специальный + иметь для разных сред (develop, stage, prod) разные внешние сервисы логирования, и токены для них + отключить какие-то features для develop, но включить их для prod + иметь разные пресеты конфигураций одного приложения для разных продуктов/клиентов + разные стили / логотипы / описания + разные наборы языков (например, когда новый язык ещё в разработке, он может быть в stage, но не в production) + поддерживать только определенные языки на develop Таких настроек может быть несколько десятков в крупном приложении. Часть из них могут быть доступны для переопределения через ENV. Кто как решает это? Какие практики и подходы есть в других экосистемах (Ruby, Elixir, Python и пр)?

Сейчас решаю такой вопрос с помощью https://www.npmjs.com/package/config У каждого нод-модуля свой конфиг, который мерджится с конфигом собираемого приложения Так же реализовал подгрузку и мерж конфига от подмодулей, если они зависят от других конфигов модулей

Все через ENV

Все через ENV

больно

Неа

Вообще ноль проблем

И в деплое и в коде

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

Ну для этого деплой должен быть весь через код

infrastructure as code, etc

если там всего 2 енва ок, когда больше уже бардак начинается

Ну их и не должно быть мега много

В конфиге может быть только то, что может свободно меняться в реальности

Все остальное зашито в код

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

Все через ENV

12 factor app?

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

нод инспектор

не видел пока еще ничего лучше devtools для анализа

а он разве с чем-то кроме lts работает?

хотя даже с lts какие-то проблемы

из того что я помню node-config не умеет сбрасывать кеш и работать нормально с кастомными env переменными

https://github.com/lorenwest/node-config/wiki/Environment-Variables

To enable custom environment variables, create a configuration file, custom-environment-variables.json

12 factor app?

вроде того

To enable custom environment variables, create a configuration file, custom-environment-variables.json

я в курсе, я написал "нормально" :) что они предлагают боль

Ооок. Нормальное рещение ИМХО - держать маппинг без магии

ERROR: S client not available

Мне кажется все это бесмысленный байкшеддинг

Конфиги это не очень сложная проблема

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

Ну вот и пишите велосипеды

Это как раз нормально для такой задачи

ну да, о том и речь

Я говорил о либах для конфигов, они не нужны

в 95% нужно просто наследование пары конфигов

На самом деле в 12 factor про конфиги по делу написано

Есть конфиги в коде, а есть конфигипри деплое

Это разные вещи

Всем привет, ребят изучаю node(привет кэп). Подскажите какие проекты можно сделать для практики socket.io используя что-то из steam API.

Я года полтора назад писал валидатор конфигов на основе JSON Schema, чтобы нельзя было запустить проект с невалидными конфигами. Со временем пришли к текущей архитектуре — common + patch. Она оказалась удобнее для разработки — внесение правок в схему у команды всегда сопровождалось болью.

А что является теперь common? production или develop? :)

Я говорил о либах для конфигов, они не нужны

Зависит от требования к утилизации наработок :) Если писать модули только для одного конкретно решения - то можно всё хардкодить, когда нужна потрабельность - тогда появляются требования к гибкости

А что является теперь common? production или develop? :)

ИМХО, прод. Чем более близкую к нему среду поднимает у себя разработчик (или поднимают на тестовых контурах), тем точнее удается воспроизвести наиболее хитрые баги - скажем, связанные с производительностью, или гонками запросов, или отказоустойчивостью. Но это чисто мои установки, на истину не претендую )

Да вот мы также к этому пришли :)

Другой вопрос принципиальный - стоит ли группировать параметры

Или сделать плоскую key-value структуру

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

Типа такого? https://www.npmjs.com/package/app-config

А как группируете? Относительно библиотек или функций/фич приложений?

Сейчас решаю такой вопрос с помощью https://www.npmjs.com/package/config У каждого нод-модуля свой конфиг, который мерджится с конфигом собираемого приложения Так же реализовал подгрузку и мерж конфига от подмодулей, если они зависят от других конфигов модулей

Круто :) Но конфиги имхо лучше в виде JS, тогда и подгрузка зависимостей не нужна (правда ABA-deps проблема может быть)

А как группируете? Относительно библиотек или функций/фич приложений?

Относительно фич. Отдельно — постгрес/слой DAO, отдельно — работа с очередью, отдельно — smtp и настройки почтовых рассылок.

У феникса интересный подход тоже https://github.com/phoenixframework/phoenix/tree/master/installer/templates/new/config

Относительно фич. Отдельно — постгрес/слой DAO, отдельно — работа с очередью, отдельно — smtp и настройки почтовых рассылок.

Похоже на: 1. Core 2. Services 3. Features

Круто :) Но конфиги имхо лучше в виде JS, тогда и подгрузка зависимостей не нужна (правда ABA-deps проблема может быть)

Внутри они json, но наружу уже торчат как экспорт js(то есть самого модуля config) после мерджа конфигов модуля и аппа

Круто :) Но конфиги имхо лучше в виде JS, тогда и подгрузка зависимостей не нужна (правда ABA-deps проблема может быть)

Плюс есть возможность conditional configs делать в стиле: https://github.com/rails/rails/blob/master/railties/lib/rails/generators/rails/app/templates/config/environments/development.rb.tt#L16

Очень важная часть тут - автокомплит

Он должен работать в коде вида: import config from '../config' console.log('Connect to [%s]...', config.|

кстати кто-нибудь работал с vue.js?

@vuejs_ru - здесь целая армия счастливчиков)