Solution for process.env.TZ = ‘UTC’ in Node for Windows?

I was trying to test my Postgres database to make sure everything was being added properly and would include a hardcoded date in this format 2029-01-22T16:28:32.000Z .

Here is the table for it:

I expect to get back 2029-01-22T16:28:32.000Z but get back 2029-01-23T00:28:32.000Z because Windows would automatically adjust it for the timezone difference and my test would fail.

It should automatically adjust for daylight savings time but here is my solution:

Here is how I used it:

I made the adjustingForTimezone function that should adjust it automatically, is there any way that I could improve it? What are the potential pitfalls of using this in my code?

1 Answer 1

The approach used to «adjust» for time zone doesn’t actually adjust. Instead, it creates a different point in time. It’s common to think that one can just subtract an offset to account for time zones, but those are two very different concepts.

The Date object has only one actual value stored within it, which is the numeric timestamp that you see when calling getTime , valueOf , parse , etc. Any other functions that use the local time zone (such as toString ), or a named time zone (such as the timeZone option of toLocaleString ) will expect that the internal timestamp is UTC-based. If it’s not, then you may get incorrect results.

Where this matters in your code is where you call getTimezoneOffset . The point in time you are asking for should be UTC-based, but since you need to adjust then it is already the wrong point in time. You can test this near date/time of a DST transition and you’ll see that it switches offsets slightly too early or slightly too late.

So let’s go back to the original problem — you’re getting a timestamp out of Postgres that has been shifted by the local time zone. This is the culprit:

Here’s what’s probably happening:

The now() function returns a TIMESTAMP WITH TIME ZONE (aka TIMESTAMPTZ ), using the session time zone in effect when you insert the row. In your example, it is returning 2029-01-23T00:28:32.000+08:00 . Thus the session time zone is probably the default, which is pulling from the server’s time zone setting. (UTC+8 — used in China, Australia, and a few other places.)

Then you pass it to a TIMESTAMP , which in Postgres is not aware of time zone. So it strips off the offset and stores 2029-01-23T00:28:32.000 . Thus your timestamp is not stored in UTC but in local time.

Later when you query, the session time zone is set to UTC, so you get back 2029-01-23T00:28:32.000Z , which is incorrect.

There are a few different ways you could fix this:

You could ensure the session time zone was set to UTC during the row insert.

You could explicitly convert to UTC before storing your timestamp when defining your table:

You could define your date_published field as a TIMESTAMPTZ instead of a TIMESTAMP . (This is arguably the best approach.)

You could ensure the session time zone at time of query is the same local time zone as at time of insert. However, I don’t recommend this one because you will have discrepancies if the server’s time zone ever changes or if you are using a time zone that transitions between offsets for daylight saving time.

With any of these in place, you can delete your adjustingForTimezone function and directly use the timestamp returned from the query.

How to read environment variable from windows in node.js ? #2220

Comments

kumaresan-subramani commented Oct 5, 2019 •

Node.js Version: 10.16.3 OS: 10 Scope (install, code, runtime, meta, other?): Module (and version) (if relevant):

Is there any way to read environment variable which is set in windows like below:

This is my requirement, in here I want to read above-mentioned variables values:

tagchange.js

package.json

The text was updated successfully, but these errors were encountered:

Hakerh400 commented Oct 6, 2019

What is the problem you’re experiencing? This should work just fine

kumaresan-subramani commented Oct 6, 2019

It throws error like:

Process.env.oldtag is undefined

addaleax commented Oct 6, 2019

@kumaresan-subramani Sharing the full error, possibly including a stack trace, might be helpful.

kumaresan-subramani commented Oct 7, 2019 •

Sorry, here you can find my error. please see below screenshot:

if i written like below: it shows all refer below content

kumaresan-subramani commented Oct 7, 2019 •

While trying below command, I can able read variables:

SET oldtag=[ejs-button,ejs-chart] && SET newtag=[kumar-button,kumar-chart] && npm i @syncfusion/ej2-angular-buttons

tagchange.js file

ouptut

addaleax commented Oct 7, 2019

if i written like below: it shows all refer below content

That makes it seem like it’s more an issue with setting the environment variable than with reading it?

kumaresan-subramani commented Oct 7, 2019

Sorry @addaleax , i cant understand

addaleax commented Oct 7, 2019

@kumaresan-subramani It sounds like the environment variables aren’t actually set when you run the Node.js code. So you are reading them correctly, they’re just not there to begin with.

Why that is, I don’t know. Maybe somebody with more Windows expertise will give an answer, but it doesn’t seem to be related to Node.js itself.

kumaresan-subramani commented Oct 7, 2019

okay @addaleax , THanks for your fast and nice reply. i will close this issue now.

Amrkamel1 commented Apr 30, 2020

@kumaresan-subramani
did you manage to solve this issue, im facing same one

kumaresan-subramani commented Apr 30, 2020

@kumaresan-subramani
did you manage to solve this issue, im facing same one

Yes i have resolved like below:
#2220 (comment)

but this command wont work in lastest Vs code terminal

Amrkamel1 commented Apr 30, 2020

@kumaresan-subramani im using intellij did u find any issue

Эффективное использование process.env

Если вы только начинаете осваивать Node.js, то, вам, наверняка, встречались примерно такие строчки кода: app.listen(process.env.PORT) . Зачем вбивать в редактор кода шестнадцать символов, когда того же эффекта можно добиться, просто указав номер порта, например — 3000? Предлагаем это выяснить.

Что такое process.env?

Глобальная переменная process.env доступна приложению во время его выполнения благодаря внутренним механизмам Node. Она представляет собой состояние окружения системы в момент запуска приложения. Например, если в системе задана переменная PATH , обратиться к ней из приложения можно посредством конструкции process.env.PATH . Её можно использовать, например, если вам нужно узнать место, где можно найти исполняемые файлы, к которым требуется обратиться из кода.

О важности окружения, в котором работает приложение

До тех пор пока приложение не развёрнуто, будь то код, реализующий простейший сайт, или сложное API, используемое в тяжёлых вычислениях, оно совершенно бесполезно. Это — лишь строки текста, хранящиеся в файлах.

Занимаясь созданием программ, разработчик никогда точно не знает, где именно они будут работать. Например, если в процессе разработки нужна база данных, мы запускаем её экземпляр локально и связываемся с ней с использованием строки соединения, которая выглядит примерно так: 127.0.0.1:3306 . Однако, когда мы развёртываем рабочий экземпляр приложения, может возникнуть потребность, например, подключиться к СУБД, расположенной на удалённом сервере, скажем, доступной по адресу 54.32.1.0:3306 .

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

Первый заключается в том, чтобы обеспечить доступность базы данных на той же машине, на которой работает приложение, что позволит подключиться к ней по адресу 127.0.0.1:3306 . Такой подход означает сильную привязку приложения к инфраструктуре, его потенциально низкую доступность и невозможность его масштабировать, так как развернуть можно лишь один экземпляр приложения, зависимый от единственного экземпляра СУБД.

Второй вариант предусматривает модификацию кода таким образом, чтобы в ходе его выполнения, через условный оператор с несколькими ветвями else , можно было выбрать подходящую строку подключения к базе данных:

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

Если же для указания строки подключения к базе используются переменные окружения, нашу задачу можно решить так:

При таком подходе можно как подключаться к локальному экземпляру СУБД при разработке, так и организовать соединение с чем-то вроде защищённого удалённого кластера баз данных, поддерживающего балансировку нагрузки и умеющего масштабироваться независимо от приложения. Это даёт возможность, например, иметь множество экземпляров приложения, которые независимы от конкретного экземпляра СУБД.

В целом, рекомендовано всегда рассматривать зависимости приложения от неких внешних служб как присоединённые ресурсы и настраивать подключение к ним с помощью переменных окружения.

Как использовать переменные окружения

Действия, которые выполняются для того, чтобы подготовить переменные окружения для приложения называют предоставлением ресурсов (provisioning) или подготовкой к работе. При подготовке сервера можно выделить два уровня, на которых можно работать с переменными окружения: уровень инфраструктуры и уровень приложения. Подготовить окружение можно, либо используя специализированные инструменты, либо — некую логику, реализованную на уровне приложения.

Среди средств, работающих на уровне приложения, можно отметить пакет dotenv , который позволят загружать переменные окружения из файла .env . Установить этот инструмент можно так:

Загрузка переменных окружения выполняется с помощью следующей простой команды:

Такой подход удобен в процессе разработки, но не рекомендуется в продакшне, поэтому, в частности, файл .env лучше добавить в .gitignore .

На инфраструктурном уровне для настройки окружения можно использовать средства для управления развёртыванием приложений вроде PM2, Docker Compose и Kubernetes.
PM2 использует файл ecosystem.yaml , в котором можно задать переменные окружения с помощью свойства env :

Docker Compose, аналогичным образом, позволяет задавать свойство environment в манифест-файле сервиса:

У Kubernetes есть похожее свойство env в шаблоне манифеста, которое также позволяет задавать переменные окружения:

Сценарии использования переменных окружения

▍Настройки приложения

Настройки приложения не влияют на то, какие именно действия выполняет это приложение, не влияют на его логику. Например, приложению известно, что ему необходимо прослушивать порт для того, чтобы к нему можно было обратиться извне, но ему необязательно знать — какой именно это будет порт. Такие данные вполне подходят для вынесения их в переменные окружения. Поэтому их установку и подготовку сетевой инфраструктуры можно доверить средствам развёртывания приложений.

▍Взаимодействие с внешними службами

Переменные окружения часто используют для указания того, как приложение должно подключаться к службам, от которых оно зависит. Это позволяет сделать код чище и улучшить тестируемость приложения. В частности, такой подход позволяет окружению тестирования передавать приложению некие условные данные, которые, например, имитируют внештатные ситуации, что позволяет проверить приложение на предмет сбоев в подобных ситуациях. Тут мы имеем дело с похожей ситуацией: приложение нуждается в некоей службе, но где именно она расположена, заранее неизвестно. Настройку переменных окружения для подобных случаев можно доверить менеджерам развёртывания.

▍Вспомогательные средства разработки

В ходе локальной разработки обычно полезно иметь некие программные средства, которые позволяют быстро получать информацию из выполняющегося приложения или изолировать ошибки. Пример подобных средств — интерактивная перезагрузка веб-страницы после внесения изменений в относящийся к ней код приложения. Подобное поведение можно реализовать с помощью условных конструкций, решения в которых принимаются либо на основании стандартных переменных окружения, вроде process.env.NODE_ENV , либо на базе специальных переменных, которые создаёт сам разработчик, наподобие process.env.HOT_RELOADING_ENABLED .

Анти-паттерны

Вот несколько распространённых вариантов неправильного использования переменных окружения.

Руководство по Node.js, часть 10: стандартные модули, потоки, базы данных, NODE_ENV

Этот материал завершает серию переводов руководства по Node.js. Сегодня мы поговорим о модулях os, events и http, обсудим работу с потоками и базами данных, затронем вопрос использования Node.js при разработке приложений и в продакшне.

Модуль Node.js os

Модуль os даёт доступ ко многим функциям, которые можно использовать для получения информации об операционной системе и об аппаратном обеспечении компьютера, на котором работает Node.js. Это стандартный модуль, устанавливать его не надо, для работы с ним из кода его достаточно подключить:

Здесь имеются несколько полезных свойств, которые, в частности, могут пригодиться при работе с файлами.

Так, свойство os.EOL позволяет узнать используемый в системе разделитель строк (признак конца строки). В Linux и macOS это \n , в Windows — \r\n .

Надо отметить, что упоминая тут «Linux и macOS», мы говорим о POSIX-совместимых платформах. Ради краткости изложения менее популярные платформы мы тут не упоминаем.

Свойство os.constants.signals даёт сведения о константах, используемых для обработки сигналов процессов наподобие SIGHUP , SIGKILL , и так далее. Здесь можно найти подробности о них.

Свойство os.constants.errno содержит константы, используемые для сообщений об ошибках — наподобие EADDRINUSE , EOVERFLOW .

Теперь рассмотрим основные методы модуля os .

▍os.arch()

Этот метод возвращает строку, идентифицирующую архитектуру системы, например — arm , x64 , arm64 .

▍os.cpus()

Возвращает информацию о процессорах, доступных в системе. Например, эти сведения могут выглядеть так:

▍os.endianness()

Возвращает BE или LE в зависимости от того, какой порядок байтов (Big Engian или Little Endian) был использован для компиляции бинарного файла Node.js.

▍os.freemem()

Возвращает количество свободной системной памяти в байтах.

▍os.homedir()

Возвращает путь к домашней директории текущего пользователя. Например — ‘/Users/flavio’ .

▍os.hostname()

Возвращает имя хоста.

▍os.loadavg()

Возвращает, в виде массива, данные о средних значениях нагрузки, вычисленные операционной системой. Эта информация имеет смысл только в Linux и macOS. Выглядеть она может так:

▍os.networkInterfaces()

Возвращает сведения о сетевых интерфейсах, доступных в системе. Например:

▍os.platform()

Возвращает сведения о платформе, для которой был скомпилирован Node.js. Вот некоторые из возможных возвращаемых значений:

▍os.release()

Возвращает строку, идентифицирующую номер релиза операционной системы.

▍os.tmpdir()

Возвращает путь к заданной в системе директории для хранения временных файлов.

▍os.totalmem()

Возвращает общее количество системной памяти в байтах.

▍os.type()

Возвращает сведения, позволяющие идентифицировать операционную систему. Например:

• Linux — Linux.
• Darwin — macOS.
• Windows_NT — Windows.

▍os.uptime()

Возвращает время работы системы в секундах с последней перезагрузки.

Модуль Node.js events

Модуль events предоставляет нам класс EventEmitter , который предназначен для работы с событиями на платформе Node.js. Мы уже немного говорили об этом модуле в седьмой части этой серии материалов. Вот документация к нему. Здесь рассмотрим API этого модуля. Напомним, что для использования его в коде нужно, как это обычно бывает со стандартными модулями, его подключить. После этого надо создать новый объект EventEmitter . Выглядит это так:

Объект класса EventEmitter пользуется стандартными механизмами, в частности — следующими событиями:

• newListener — это событие вызывается при добавлении обработчика событий.
• removeListener — вызывается при удалении обработчика.

Рассмотрим наиболее полезные методы объектов класса EventEmitter (подобный объект в названиях методов обозначен как emitter ).

▍emitter.addListener()

Псевдоним для метода emitter.on() .

▍emitter.emit()

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

▍emitter.eventNames()

Возвращает массив, который содержит зарегистрированные события.

▍emitter.getMaxListeners()

Возвращает максимальное число обработчиков, которые можно добавить к объекту класса EventEmitter . По умолчанию это 10. При необходимости этот параметр можно увеличить или уменьшить с использованием метода setMaxListeners() .

▍emitter.listenerCount()

Возвращает количество обработчиков события, имя которого передаётся данному методу в качестве параметра:

▍emitter.listeners()

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

▍emitter.off()

Псевдоним для метода emitter.removeListener() , появившийся в Node 10.

▍emitter.on()

Регистрируеn коллбэк, который вызывается при генерировании события. Вот как им пользоваться:

▍emitter.once()

Регистрирует коллбэк, который вызывается только один раз — при первом возникновении события, для обработки которого зарегистрирован этот коллбэк. Например:

▍emitter.prependListener()

При регистрации обработчика с использованием методов on() или addListener() этот обработчик добавляется в конец очереди обработчиков и вызывается для обработки соответствующего события последним. При использовании метода prependListener() обработчик добавляется в начало очереди, что приводит к тому, что он будет вызываться для обработки события первым.

▍emitter.prependOnceListener()

Этот метод похож на предыдущий. А именно, когда обработчик, предназначенный для однократного вызова, регистрируется с помощью метода once() , он оказывается последним в очереди обработчиков и последним вызывается. Метод prependOnceListener() позволяет добавить такой обработчик в начало очереди.

▍emitter.removeAllListeners()

Данный метод удаляет все обработчики для заданного события, зарегистрированные в соответствующем объекте. Пользуются им так:

▍emitter.removeListener()

Удаляет заданный обработчик, который нужно передать данному методу. Для того чтобы сохранить обработчик для последующего удаления соответствующий коллбэк можно назначить переменной. Выглядит это так:

▍emitter.setMaxListeners()

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

Модуль Node.js http

В восьмой части этой серии материалов мы уже говорили о стандартном модуле Node.js http . Он даёт в распоряжение разработчика механизмы, предназначенные для создания HTTP-серверов. Он является основным модулем, применяемым для решения задач обмена данными по сети в Node.js. Подключить его в коде можно так:

В его состав входят свойства, методы и классы. Поговорим о них.

▍Свойства

http.METHODS

В этом свойстве перечисляются все поддерживаемые методы HTTP:

http.STATUS_CODES

Здесь содержатся коды состояния HTTP и их описания:

http.globalAgent

Данное свойство указывает на глобальный экземпляр класса http.Agent . Он используется для управления соединениями. Его можно считать ключевым компонентом HTTP-подсистемы Node.js. Подробнее о классе http.Agent мы поговорим ниже.

▍Методы

http.createServer()

Возвращает новый экземпляр класса http.Server . Вот как пользоваться этим методом для создания HTTP-сервера:

http.request()

Позволяет выполнить HTTP-запрос к серверу, создавая экземпляр класса http.ClientRequest .

http.get()

Этот метод похож на http.request() , но он автоматически устанавливает метод HTTP в значение GET и автоматически же вызывает команду вида req.end() .

▍Классы

Модуль HTTP предоставляет 5 классов — Agent , ClientRequest , Server , ServerResponse и IncomingMessage . Рассмотрим их.

http.Agent

Глобальный экземпляр класса http.Agent , создаваемый Node.js, используется для управления соединениями. Он применяется в качестве значения по умолчанию всеми HTTP-запросами и обеспечивает постановку запросов в очередь и повторное использование сокетов. Кроме того, он поддерживает пул сокетов, что позволяет обеспечить высокую производительность сетевой подсистемы Node.js. При необходимости можно создать собственный объект http.Agent .

http.ClientRequest

Объект класса http.ClientRequest , представляющий собой выполняющийся запрос, создаётся при вызове методов http.request() или http.get() . При получении ответа на запрос вызывается событие response , в котором передаётся ответ — экземпляр http.IncomingMessage . Данные, полученные после выполнения запроса, можно обработать двумя способами:

• Можно вызвать метод response.read() .
• В обработчике события response можно настроить прослушиватель для события data , что позволяет работать с потоковыми данными.

http.Server

Экземпляры этого класса используются для создания серверов с применением команды http.createServer() . После того, как у нас имеется объект сервера, мы можем воспользоваться его методами:

• Метод listen() используется для запуска сервера и организации ожидания и обработки входящих запросов.
• Метод close() останавливает сервер.

http.ServerResponse

Этот объект создаётся классом http.Server и передаётся в качестве второго параметра событию request при его возникновении. Обычно подобным объектам в коде назначают имя res :

В таких обработчиках, после того, как ответ сервера будет готов к отправке клиенту, вызывают метод end() , завершающий формирование ответа. Этот метод необходимо вызывать после завершения формирования каждого ответа.

Вот методы, которые используются для работы с HTTP-заголовками:

• getHeaderNames() — возвращает список имён установленных заголовков.
• getHeaders() — возвращает копию установленных HTTP-заголовков.
• setHeader(‘headername’, value) — устанавливает значение для заданного заголовка.
• getHeader(‘headername’) — возвращает установленный заголовок.
• removeHeader(‘headername’) — удаляет установленный заголовок.
• hasHeader(‘headername’) — возвращает true если в ответе уже есть заголовок, имя которого передано этому методу.
• headersSent() — возвращает true если заголовки уже отправлены клиенту.

После обработки заголовков их можно отправить клиенту, вызвав метод response.writeHead() , который, в качестве первого параметра, принимает код состояния. В качестве второго и третьего параметров ему можно передать сообщение, соответствующее коду состояния, и заголовки.

Для отправки данных клиенту в теле ответа используют метод write() . Он отправляет буферизованные данные в поток HTTP-ответа.

Если до этого заголовки ещё не были установлены командой response.writeHead() , сначала будут отправлены заголовки с кодом состояния и сообщением, которые заданы в запросе. Задавать их значения можно, устанавливая значения для свойств statusCode и statusMessage :

http.IncomingMessage

Объект класса http.IncomingMessage создаётся в ходе работы следующих механизмов:

• http.Server — при обработке события request .
• http.ClientRequest — при обработке события response .

Его можно использовать для работы с данными ответа. А именно:

• Для того чтобы узнать код состояния ответа и соответствующее сообщение используются свойства statusCode и statusMessage .
• Заголовки ответа можно посмотреть, обратившись к свойству headers или rawHearders (для получения списка необработанных заголовков).
• Метод запроса можно узнать, воспользовавшись свойством method .
• Узнать используемую версию HTTP можно с помощью свойства httpVersion .
• Для получения URL предназначено свойство url .
• Свойство socket позволяет получить объект net.Socket , связанный с соединением.

Данные ответа представлены в виде потока так как объект http.IncomingMessage реализует интерфейс Readable Stream .

Работа с потоками в Node.js

Потоки — это одна из фундаментальных концепций, используемых в Node.js-приложениях. Потоки — это инструменты, которые позволяют выполнять чтение и запись файлов, организовывать сетевое взаимодействие систем, и, в целом — эффективно реализовывать операции обмена данными.

Концепция потоков не уникальна для Node.js. Они появились в ОС семейства Unix десятки лет назад. В частности, программы могут взаимодействовать друг с другом, передавая потоки данных с использованием конвейеров (с применением символа конвейера — | ).

Если представить себе, скажем, чтение файла без использования потоков, то, в ходе выполнения соответствующей команды, содержимое файла будет целиком считано в память, после чего с этим содержимым можно будет работать.

Благодаря использованию механизма потоков файлы можно считывать и обрабатывать по частям, что избавляет от необходимости хранить в памяти большие объёмы данных.

Модуль Node.js stream представляет собой основу, на которой построены все API, поддерживающие работу с потоками.

▍О сильных сторонах использования потоков

Потоки, в сравнении с другими способами обработки данных, отличаются следующими преимуществами:

• Эффективное использование памяти. Работа с потоком не предполагает хранения в памяти больших объёмов данных, загружаемых туда заранее, до того, как появится возможность их обработать.
• Экономия времени. Данные, получаемые из потока, можно начать обрабатывать гораздо быстрее, чем в случае, когда для того, чтобы приступить к их обработке, приходится ждать их полной загрузки.

▍Пример работы с потоками

Традиционный пример работы с потоками демонстрирует чтение файла с диска.

Сначала рассмотрим код, в котором потоки не используются. Стандартный модуль Node.js fs позволяет прочитать файл, после чего его можно передать по протоколу HTTP в ответ на запрос, полученный HTTP-сервером:

Метод readFile() , использованный здесь, позволяет прочесть файл целиком. Когда чтение будет завершено, он вызывает соответствующий коллбэк.

Метод res.end(data) , вызываемый в коллбэке, отправляет содержимое файла клиенту.

Если размер файла велик, то эта операция займёт немало времени. Вот тот же пример переписанный с использованием потоков:

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

▍Метод pipe()

В предыдущем примере мы использовали конструкцию вида stream.pipe(res) , в которой вызывается метод файлового потока pipe() . Этот метод берёт данные из их источника и отправляет их в место назначения.

Его вызывают для потока, представляющего собой источник данных. В данном случае это — файловый поток, который отправляют в HTTP-ответ.

Возвращаемым значением метода pipe() является целевой поток. Это очень удобно, так как позволяет объединять в цепочки несколько вызовов метода pipe() :

Это равносильно такой конструкции:

▍API Node.js, в которых используются потоки

Потоки — полезный механизм, в результате многие модули ядра Node.js предоставляют стандартные возможности по работе с потоками. Перечислим некоторые из них:

• process.stdin — возвращает поток, подключённый к stdin .
• process.stdout — возвращает поток, подключённый к stdout .
• process.stderr — возвращает поток, подключённый к stderr .
• fs.createReadStream() — создаёт читаемый поток для работы с файлом.
• fs.createWriteStream() — создаёт записываемый поток для работы с файлом.
• net.connect() — инициирует соединение, основанное на потоке.
• http.request() — возвращает экземпляр класса http.ClientRequest , предоставляющий доступ к записываемому потоку.
• zlib.createGzip() — сжимает данные с использованием алгоритма gzip и отправляет их в поток.
• zlib.createGunzip() — выполняет декомпрессию gzip -потока.
• zlib.createDeflate() — сжимает данные с использованием алгоритма deflate и отправляет их в поток.
• zlib.createInflate() — выполняет декомпрессию deflate -потока.

▍Разные типы потоков

Существует четыре типа потоков:

• Поток для чтения ( Readable ) — это поток, из которого можно читать данные. Записывать данные в такой поток нельзя. Когда в такой поток поступают данные, они буферизуются до того момента пока потребитель данных не приступит к их чтению.
• Поток для записи ( Writable ) — это поток, в который можно отправлять данные. Читать из него данные нельзя.
• Дуплексный поток ( Duplex ) — в такой поток можно и отправлять данные и читать их из него. По существу это — комбинация потока для чтения и потока для записи.
• Трансформирующий поток ( Transform ) — такие потоки похожи на дуплексные потоки, разница заключается в том, что то, что поступает на вход этих потоков, преобразует то, что из них можно прочитать.

▍Создание потока для чтения

Поток для чтения можно создать и инициализировать, воспользовавшись возможностями модуля stream :

Теперь в поток можно поместить данные, которые позже сможет прочесть потребитель этих данных:

▍Создание потока для записи

Для того чтобы создать записываемый поток нужно расширить базовый объект Writable и реализовать его метод _write() . Для этого сначала создадим соответствующий поток:

Затем реализуем его метод _write() :

Теперь к такому потоку можно подключить поток, предназначенный для чтения:

▍Получение данных из потока для чтения

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

Команда readableStream.push(null) сообщает об окончании вывода данных.

Работать с потоками для чтения можно и напрямую, обрабатывая событие readable :

▍Отправка данных в поток для записи

Для отправки данных в поток для записи используется метод write() :

▍Сообщение потоку для записи о том, что запись данных завершена

Для того чтобы сообщить потоку для записи о том, что запись данных в него завершена, можно воспользоваться его методом end() :

Этот метод принимает несколько необязательных параметров. В частности, ему можно передать последнюю порцию данных, которые надо записать в поток.

Основы работы с MySQL в Node.js

MySQL является одной из самых популярных СУБД в мире. В экосистеме Node.js имеется несколько пакетов, которые позволяют взаимодействовать с MySQL-базами, то есть — сохранять в них данные, получать данные из баз и выполнять другие операции.

Мы будем использовать пакет mysqljs/mysql. Этот проект, который существует уже очень давно, собрал более 12000 звёзд на GitHub. Для того чтобы воспроизвести следующие примеры, вам понадобится MySQL-сервер.

▍Установка пакета

Для установки этого пакета воспользуйтесь такой командой:

▍Инициализация подключения к базе данных

Сначала подключим пакет в программе:

После этого создадим соединение:

Теперь попытаемся подключиться к базе данных:

▍Параметры соединения

В вышеприведённом примере объект options содержал три параметра соединения:

На самом деле этих параметров существует гораздо больше. В том числе — следующие:

• host — имя хоста, на котором расположен MySQL-сервер, по умолчанию — localhost .
• port — номер порта сервера, по умолчанию — 3306 .
• socketPath — используется для указания сокета Unix вместо хоста и порта.
• debug — позволяет работать в режиме отладки, по умолчанию эта возможность отключена.
• trace — позволяет выводить сведения о трассировке стека при возникновении ошибок, по умолчанию эта возможность включена.
• ssl — используется для настройки SSL-подключения к серверу.

▍Выполнение запроса SELECT

Теперь всё готово к выполнению SQL-запросов к базе данных. Для выполнения запросов используется метод соединения query , который принимает запрос и коллбэк. Если операция завершится успешно — коллбэк будет вызван с передачей ему данных, полученных из базы. В случае ошибки в коллбэк попадёт соответствующий объект ошибки. Вот как это выглядит при выполнении запроса на выборку данных:

При формировании запроса можно использовать значения, которые будут автоматически встроены в строку запроса:

Для передачи в запрос нескольких значений можно, в качестве второго параметра, использовать массив:

▍Выполнение запроса INSERT

Запросы INSERT используются для записи данных в базу. Например, запишем в базу данных объект:

Если у таблицы, в которую добавляются данные, есть первичный ключ со свойством auto_increment , его значение будет возвращено в виде results.insertId :

▍Закрытие соединения с базой данных

После того как работа с базой данных завершена и пришло время закрыть соединение — воспользуйтесь его методом end() :

Это приведёт к правильному завершению работы с базой данных.

О разнице между средой разработки и продакшн-средой

Создавая приложения в среде Node.js можно использовать различные конфигурации для окружения разработки и продакшн-окружения.

По умолчанию платформа Node.js работает в окружении разработки. Для того чтобы указать ей на то, что код выполняется в продакшн-среде, можно настроить переменную окружения NODE_ENV :

Обычно это делается в командной строке. В Linux, например, это выглядит так:

Лучше, однако, поместить подобную команду в конфигурационный файл наподобие .bash_profile (при использовании Bash), так как в противном случае такие настройки не сохраняются после перезагрузки системы.

Настроить значение переменной окружения можно, воспользовавшись следующей конструкцией при запуске приложения:

Эта переменная окружения широко используется во внешних библиотеках для Node.js. Установка NODE_ENV в значение production обычно означает следующее:

• До минимума сокращается логирование.
• Используется больше уровней кэширования для оптимизации производительности.

Например, Pug — библиотека для работы с шаблонами, используемая Express, готовится к работе в режиме отладки в том случае, если переменная NODE_ENV не установлена в значение production . Представления Express, в режиме разработки, генерируются при обработке каждого запроса. В продакшн-режиме они кэшируются. Есть и множество других подобных примеров.

Express предоставляет конфигурационные хуки для каждого окружения. То, какой именно будет вызван, зависит от значения NODE_ENV :

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