Мы в stdout пишем access logs, а в stderr — все остальное (service logs).
Получается удобно. Эти логи очень сильно по размерам отличаются (access logs гораздо больше), соответсвенно их ротация и индексация настроены по разному
Попробуйте Itead SONOFF MINI — ставится в подрозетник, позволяет управлять выключателем и через WiFi. Есть локальный режим работы без облачного сервера.
Сейчас сам с ним экспериментирую.
Если бы архитектуру разных компонентов / подсистем продумывали разные разработчики, это способствовало бы обмену опытом и развитию членов команды
В этом случае дополнительно надо следить, что архитектура остается консистентной, и однотипные задачи решаются в едином стиле. Иначе получится сборная солянка, которая работает, но в долгосрочной поддержке будет гораздо затратнее. Или будет зоопарк технологий.
Спасибо за интересную статью. Мы тоже используем BFF, поэтому интересно узнать ваше мнение.
— Как вы тестируете соответствие ответа бэкенд АПИ и его Swagger документации? Каки-либо контракт-тесты используете?
— Как часто валидация ответа по JSON-схеме помогало находит ошибки на проде?
— Валидация синхронная, не было у вас проблем с блокированием event-loop при валидации большого ответа?
Можете предоставить ссылку на пруф, что именно сжатый HTML влияет на СЕО?
Где указано, что влияет именно HTML без лишних пробелов и кавычек, а не просто более оптимальный HTML без лишних тегов или более правильный семантически.
Кроме того, одно другому не мешает, а дополняет: можно сначала пожать код, а потом gzip использовать.
Давайте проведем эксперимент. Возьмем довольно большую страницу, например habr.com/post/425351 и сожмем ее по разному:
Исходный размер HTML: 582KB
Размер после html-minifier: 543KB (-7%)
Размер после html-minifier и gzip: 78KB (-87%)
Размер после одного gzip: 81KB (-86%)
Т.е. при условии, что HTML сжимается с помощь gzip, минификация дает крайне минимальный эффект (1% всего) — вот это я и называю «экономия на спичках».
Лучше процессорное время потратить на обработку другого запроса, чем минифицировать HTML (а тем более JSON)
я ставлю перед node приложением кеширующий проксер (nginx например)
Вместо того, чтобы экономить на спичках и удалять из HTML и JSON пробелы и кавычки, лучше сжать ответ с помощью gzip. К тому же так можно сжимать потоки и не надо накапливать весь ответ (тем более 1ТБ в памяти).
Ох и намучались мы в свое время с этими css-селекторами в Selenium тестах — никому не советую так делать.
Очень скоро наши тесты начали так сильно зависеть от имен css-классов или структуры html, что любое, даже малейшее косметическое изменение UI вело к падению большого количества тестов. И время на фикс этих тестов было гораздо больше чем на создание самой фичи, а еще тесты блокировали деплой.
В общем для себя решили в тестах использовать только семантические идентификаторы (например data-ref=«submit_button» или data-action=«submit») а css пусть занимается только стилизацией.
Вопрос о серверных шаблонах — вы используете handlebars через модуль consolidate, почему не express-handlebars? Есть какие-то преисущества у consolidate?
Я использую es6 modules на сервере, поэтому и прогоняю через бабел. А вот зачем нужен вебпак на сервере — мне как-то не понятно. Вы используете его только чтобы следить за изменениями в файлах и делать хот-релоад?
Спасибо за статьи, скажите, какие преимущества дает сборка серверного когда с помощью вебпака? Кроме возможности хот-релоада.
Зачем его вообще собирать, когда достаточно просто прогнать через бабел если надо.
Столкнулся с такой проблемой при использовании веб-компонентов.
Допустим внутри компонента есть кнопка с классом «my-button» и вне компонента тоже есть такие кнопки. И я как владелец веб-компонента хочу, чтобы кнопка внутри моего компонента была стилизована так же. Как этого достичь?
Было бы здорово такой развернутый пост почитать, особенно примеры были бы полезны.
Скажите, насколько данный чек-лист подходит для Agile разработки?
Когда и требования и разработка идёт инкрементально и все постоянно меняется после тестирования на реальных пользователях.
Получается удобно. Эти логи очень сильно по размерам отличаются (access logs гораздо больше), соответсвенно их ротация и индексация настроены по разному
Физический выключатель работает всегда, независимо от того есть WiFi или нет.
Сейчас сам с ним экспериментирую.
blog.logrocket.com/node-js-12
В этом случае дополнительно надо следить, что архитектура остается консистентной, и однотипные задачи решаются в едином стиле. Иначе получится сборная солянка, которая работает, но в долгосрочной поддержке будет гораздо затратнее. Или будет зоопарк технологий.
— Как вы тестируете соответствие ответа бэкенд АПИ и его Swagger документации? Каки-либо контракт-тесты используете?
— Как часто валидация ответа по JSON-схеме помогало находит ошибки на проде?
— Валидация синхронная, не было у вас проблем с блокированием event-loop при валидации большого ответа?
Ok, раскройте, в чем именно плюс. И желательно с ссылкой на пруф.
Можете предоставить ссылку на пруф, что именно сжатый HTML влияет на СЕО?
Где указано, что влияет именно HTML без лишних пробелов и кавычек, а не просто более оптимальный HTML без лишних тегов или более правильный семантически.
Давайте проведем эксперимент. Возьмем довольно большую страницу, например habr.com/post/425351 и сожмем ее по разному:
Т.е. при условии, что HTML сжимается с помощь gzip, минификация дает крайне минимальный эффект (1% всего) — вот это я и называю «экономия на спичках».
Лучше процессорное время потратить на обработку другого запроса, чем минифицировать HTML (а тем более JSON)
Это, безусловно, правильное решение.
Посмотрите например www.npmjs.com/package/compression
Очень скоро наши тесты начали так сильно зависеть от имен css-классов или структуры html, что любое, даже малейшее косметическое изменение UI вело к падению большого количества тестов. И время на фикс этих тестов было гораздо больше чем на создание самой фичи, а еще тесты блокировали деплой.
В общем для себя решили в тестах использовать только семантические идентификаторы (например data-ref=«submit_button» или data-action=«submit») а css пусть занимается только стилизацией.
Зачем его вообще собирать, когда достаточно просто прогнать через бабел если надо.
Допустим внутри компонента есть кнопка с классом «my-button» и вне компонента тоже есть такие кнопки. И я как владелец веб-компонента хочу, чтобы кнопка внутри моего компонента была стилизована так же. Как этого достичь?