Окружай себя правильно
#frontend #reactjs #nodejs
Недавно мы получили frontend-приложение на React.js для оценки трудозатрат по расширению его функциональности. Для того чтобы запустить полученный сервис, нам пришлось модифицировать код. Всему виной — отсутствие механизма работы с переменными окружения.
DevOps-инженер должен иметь возможность конфигурировать приложение в рамках конкретной среды развертывания. А разработчик должен обеспечить такую возможность без вмешательства в код.
К переменным окружения относятся порты, на которых будет запущено приложение или URL-адрес RESTful-сервиса. Значения этих параметров могут отличаться для разных сред, например, для тестового стенда и боевого сервера.
В проектах мы выделяем такие переменные в .env-файлы. А чтобы упростить процесс развертывания и ничего не потерять, в репозиторий проекта укладывается файл .env.example. Он содержит перечень всех переменных окружения для текущего проекта. Файл .env создается путем копирования .env.example и не находится под контролем git.
Для конфигурации react-приложений можно использовать npm-пакет dotenv.
#frontend #reactjs #nodejs
Недавно мы получили frontend-приложение на React.js для оценки трудозатрат по расширению его функциональности. Для того чтобы запустить полученный сервис, нам пришлось модифицировать код. Всему виной — отсутствие механизма работы с переменными окружения.
DevOps-инженер должен иметь возможность конфигурировать приложение в рамках конкретной среды развертывания. А разработчик должен обеспечить такую возможность без вмешательства в код.
К переменным окружения относятся порты, на которых будет запущено приложение или URL-адрес RESTful-сервиса. Значения этих параметров могут отличаться для разных сред, например, для тестового стенда и боевого сервера.
В проектах мы выделяем такие переменные в .env-файлы. А чтобы упростить процесс развертывания и ничего не потерять, в репозиторий проекта укладывается файл .env.example. Он содержит перечень всех переменных окружения для текущего проекта. Файл .env создается путем копирования .env.example и не находится под контролем git.
Для конфигурации react-приложений можно использовать npm-пакет dotenv.
12factor.net
The Twelve-Factor App
A methodology for building modern, scalable, maintainable software-as-a-service apps.
Самое время поставить точку
#frontend #debug #react #nodejs
Каждый современный браузер, даже IE, имеет встроенные средства отладки клиентского JavaScript. У Chrome, например, есть инструменты разработчика, которые позволяют расставлять точки останова, выводить отладочную информацию и в режиме реального времени работать с некоторыми объектами js.
У такой отладки есть минусы — вы отлаживаете уже скомпилированный js, например из EcmaScript или TypeScript. Получается, что код пишется на одном языке, а отлаживается — на другом. Иногда удобно сразу исправлять код в момент отладки.
Наши frontend-разработчики используют IDE Visual Studio Code, в которой есть удобные встроенные средства отладки кода 🐞
VS Code позволяет настраивать различные сценарии отладки — можно отлаживать и серверный, и клиентский js.
Для настройки дебагера в VS Code используется файл
Microsoft создала даже сборник рецептов настройки отладчика для различного типа приложений и языков разработки.
Например, для отладки кода на Next.js можно взять за основу вот эту инструкцию (https://github.com/Microsoft/vscode-recipes/tree/master/Next-js) и отлаживать как клиентскую, так и серверную часть вашего приложения. Не забудьте включить source-maps в настройках сборщиков для Dev-режима, чтобы отладчик показывал исходный, а не транспилированный код.
Старайтесь минимизировать использование механизмов псевдоотладки, типа console.log. Отладка в режиме runtime дает вам полностью объективную, живую картину состояния ваших переменных, объектов и текущего хода выполнения. Вы производите отладку внешними средствами, не изменяя свой код, и спите спокойно, не думая о том, что ваши
#frontend #debug #react #nodejs
Каждый современный браузер, даже IE, имеет встроенные средства отладки клиентского JavaScript. У Chrome, например, есть инструменты разработчика, которые позволяют расставлять точки останова, выводить отладочную информацию и в режиме реального времени работать с некоторыми объектами js.
У такой отладки есть минусы — вы отлаживаете уже скомпилированный js, например из EcmaScript или TypeScript. Получается, что код пишется на одном языке, а отлаживается — на другом. Иногда удобно сразу исправлять код в момент отладки.
Наши frontend-разработчики используют IDE Visual Studio Code, в которой есть удобные встроенные средства отладки кода 🐞
VS Code позволяет настраивать различные сценарии отладки — можно отлаживать и серверный, и клиентский js.
Для настройки дебагера в VS Code используется файл
./vscode/launch.json. Чтобы мы могли отлаживать браузерный js, понадобится расширение, сопрягающее работу отладчика с браузерами движка Chrome. Для отладки nodejs-кода будем использовать вот это расширение.Microsoft создала даже сборник рецептов настройки отладчика для различного типа приложений и языков разработки.
Например, для отладки кода на Next.js можно взять за основу вот эту инструкцию (https://github.com/Microsoft/vscode-recipes/tree/master/Next-js) и отлаживать как клиентскую, так и серверную часть вашего приложения. Не забудьте включить source-maps в настройках сборщиков для Dev-режима, чтобы отладчик показывал исходный, а не транспилированный код.
Старайтесь минимизировать использование механизмов псевдоотладки, типа console.log. Отладка в режиме runtime дает вам полностью объективную, живую картину состояния ваших переменных, объектов и текущего хода выполнения. Вы производите отладку внешними средствами, не изменяя свой код, и спите спокойно, не думая о том, что ваши
console.log() проявят себя на промышленном сервере или в браузере у конечного пользователя 🙃Останься в памяти моей
#frontend #backend #reactjs #nodejs
Даже опытный react-разработчик может не до конца осознавать, как используется оперативная память компонентами его приложения. Недавно мы обнаружили memory leak в сервисе — через N дней многопоточное приложение на стороне SSR переставало работать из-за нехватки оперативной памяти.
Оказалось, что при очередном запросе пользователя составной заголовок страницы записывался в глобальный объект, не затирая предыдущие значения.
Встречается распространенная проблема, при которой react-компонент был размонтирован, но инициализированные в нем
С ростом кодовой базы продукта увеличивается и объем хранимой информации как на стороне клиента, так и на стороне сервера. Повышается вероятность возникновения новых утечек.
На стороне клиента контролировать потребляемую браузером память и работу сборщика мусора помогают инструменты разработчика. Например, браузер Google Chrome и его DevTools позволяют делать периодические снепшоты состояния памяти в различные промежутки времени работы приложения. Снимки можно анализировать и сравнивать между собой специальными средствами.
На серверной стороне также возможно настроить мониторинг используемой памяти. Для этого необходимо запустить nodejs с флагом --inspect и открыть в Chrome специальную страницу
#frontend #backend #reactjs #nodejs
Даже опытный react-разработчик может не до конца осознавать, как используется оперативная память компонентами его приложения. Недавно мы обнаружили memory leak в сервисе — через N дней многопоточное приложение на стороне SSR переставало работать из-за нехватки оперативной памяти.
Оказалось, что при очередном запросе пользователя составной заголовок страницы записывался в глобальный объект, не затирая предыдущие значения.
Встречается распространенная проблема, при которой react-компонент был размонтирован, но инициализированные в нем
setTimeout или setInterval не были остановлены и продолжают выполняться в фоне. Сборщик мусора не будет выполнять очистку памяти от данных, используемых в этих методах, следовательно, происходит систематическая утечка памяти.С ростом кодовой базы продукта увеличивается и объем хранимой информации как на стороне клиента, так и на стороне сервера. Повышается вероятность возникновения новых утечек.
На стороне клиента контролировать потребляемую браузером память и работу сборщика мусора помогают инструменты разработчика. Например, браузер Google Chrome и его DevTools позволяют делать периодические снепшоты состояния памяти в различные промежутки времени работы приложения. Снимки можно анализировать и сравнивать между собой специальными средствами.
На серверной стороне также возможно настроить мониторинг используемой памяти. Для этого необходимо запустить nodejs с флагом --inspect и открыть в Chrome специальную страницу
chrome://inspect. Здесь настраивается интеграция с серверной частью вашего приложения для работы отладочного механизма. Затем процесс работы со снимками памяти сервера и их анализа происходит в таком же интерфейсе, как и в случае с клиентской частью.Ты не пройдешь 🛑
#frontend #nodejs #express #cors
Веб-продукты, которые мы разрабатываем, часто интегрируются с внешними сервисами посредством RESTful API. В свою очередь, уважающие себя внешние сервисы реализуют CORS.
В этом случае для разработчика затрудняется локальная отладка веб-сервиса, особенно его frontend-части. Запросы типа XMLHttpRequest на внешний удаленный веб-сервер отправляются с localhost или тестовых локальных DNS-имен, что зачастую запрещено CORS-политиками внешних сервисов.
Для решения этой проблемы при разработке сайтов и сервисов мы в Студии используем реализацию простейшего прокси-сервера на node.js для подмены оригинального доменного имени клиента, выполняющего http-запрос.
Для реализации такого прокси-сервера нам потребуются следующие ингредиенты 👨🍳:
🌶 Express Framework
🥕 NPM-пакет http-proxy-middleware
🍆 NPM-пакет CORS
Как реализовать базовую конфигурацию Express, можно посмотреть здесь. Далее с помощью двух middleware-модулей осуществляем проксирование наших запросов с подменой доменного имени и поддержкой CORS.
Пример скрипта можно посмотреть здесь.
Для удобства динамические параметры, которые могут изменяться, выносим в переменные окружения:
Например, запустим наш прокси-сервер командой:
Тогда запрос
Такой лайфхак можно использовать практически в любом проекте, где в процессе разработки требуется выполнять кроссдоменные запросы к внешним сервисам.
#frontend #nodejs #express #cors
Веб-продукты, которые мы разрабатываем, часто интегрируются с внешними сервисами посредством RESTful API. В свою очередь, уважающие себя внешние сервисы реализуют CORS.
В этом случае для разработчика затрудняется локальная отладка веб-сервиса, особенно его frontend-части. Запросы типа XMLHttpRequest на внешний удаленный веб-сервер отправляются с localhost или тестовых локальных DNS-имен, что зачастую запрещено CORS-политиками внешних сервисов.
Для решения этой проблемы при разработке сайтов и сервисов мы в Студии используем реализацию простейшего прокси-сервера на node.js для подмены оригинального доменного имени клиента, выполняющего http-запрос.
Для реализации такого прокси-сервера нам потребуются следующие ингредиенты 👨🍳:
🌶 Express Framework
🥕 NPM-пакет http-proxy-middleware
🍆 NPM-пакет CORS
Как реализовать базовую конфигурацию Express, можно посмотреть здесь. Далее с помощью двух middleware-модулей осуществляем проксирование наших запросов с подменой доменного имени и поддержкой CORS.
Пример скрипта можно посмотреть здесь.
Для удобства динамические параметры, которые могут изменяться, выносим в переменные окружения:
PROXY_PORT — порт, на котором будет запущен express-сервер;TARGET_HOST — целевой хост удаленного сервера, на котором будем проксировать наши запросы.Например, запустим наш прокси-сервер командой:
TARGET_HOST=http://www.example.com node api-proxy.js
Тогда запрос
http://localhost:8088/locations будет проксирован на фактический адрес внешнего сервиса http://www.example.com/locations.Такой лайфхак можно использовать практически в любом проекте, где в процессе разработки требуется выполнять кроссдоменные запросы к внешним сервисам.