15. Уроки Node.js. Асинхронная разработка. Введение.

async_node

В реальной жизни очень редко бывает так, что, получив запрос, сервер может тут же на него ответить. Обычно для того, чтобы ответить, серверу нужны какие-то данные. Эти данные он получает либо из базы, либо из какого-то другого источника, например, из файловой системы. В этом примере, используя модуль fs при получении запроса на url ‘/’, считывается файл index.html и выводится посетителю.

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

Если бы это был запрос к базе данных, это было бы ожидание ответа по сети от базы. Такой код, с одной стороны, будет работать, а с другой стороны, в нем есть проблема, связана с  масштабируемостью, которая неизбежно проявится в серьезной промышленной эксплуатации. Например, Джон зашел по этому url ‘/’и запросил файл fs.readFileSync(‘index.html’). Джон ждет, когда сервер ему ответит. Сервер ждет, когда файл прочитается и готов выслать ему данные. В это время заходят Илон, Линус и много других, которые тоже хотят чего-то от сервера. Например, они хотят не данный файл, а что-то другое, скажем, получить текущую дату, которую, по идее, можно взять и тут же вернуть.

Но сервер не может этого сделать, поскольку сейчас его интерпретатор JavaScript занят, он ожидает ответа от диска. Когда этот ответ будет получен, он сможет продолжить выполнение строчки, закончить обработку запроса, и тогда JavaScript освободится и сможет обработать какие-то еще запросы.

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

Относительно этой функции есть следующее соглашение. Если чтение прошло успешно, то функция будет вызвана с первым аргументом null, а во втором аргументе будет содержимое файла.  Но если произошла ошибка, то функция будет вызвана только с первым аргументом, в котором будет информация о ней. Таким образом, мы даем задачу Node.js и после этого выполнение продолжается. При этом, на этом этапе пока что ничего не просчитано, просчитано оно будет только вот здесь:

Такое решение полностью снимает проблему блокировки, поскольку теперь интерпретатор JavaScript вовсе не будет ждать, пока файл прочитается. Он тут же продолжит выполнение и сможет заняться другими посетителями.

Функцию, которую Node.js обязуется вызвать, когда завершит процесс, называют функцией обратного вызова или по-английски callback function. То есть, модуль fs возвращает управление JavaScript интерпретатору и говорит, что ты сейчас поработай, а я, когда закончу чтение файла, тебе перезвоню (вызов callback).

Важный подводный камень состоит в том, что о возможности ошибки при таком вызове можно легко забыть. Например, посмотрим, что будет, если файл index.html почему-то отсутствует либо была какая-то ошибка при чтении, скажем, с правами, с диском. В этой ситуации модуль fs вызовет callback с первым аргументом объекта ошибки.

А второго аргумента вообще не будет. Если мы ошибку никак не обрабатываем, то получится, что посетитель в итоге получит пустую строку. Кошмар ситуации здесь в том, что код просто тихо сглючит без всяких сообщений об ошибке. При этом, во-первых, это может стать известным не сразу, то есть, будут уже какие-то жалобы от недовольных людей, а во-вторых, будет достаточно сложно отладить это, то есть, найти причину. Соответственно, что бы такого не происходило, нужно обязательно обрабатывать аргумент ошибки. В крайнем случае, если мы точно уверенны, что ошибки никогда не будет, можно сделать вот так:

Но в данном случае, будет, конечно, более правильным сделать вот такой вариант:

Итак, в завершение этого выпуска сравним синхронный и асинхронный код, используя для примера реализацию сервера.
why-so-asynchronous
Ниже у нас синхронный вариант:

А здесь асинхронный:

Начнем с синхронного варианта. Синхронные вызовы типа readFileSync используются достаточно редко. Они применяются в тех случаях, когда мы можем позволить себе заблокировать интерпретатор JavaScript. Как правило, это значит, что нет параллелелизма. Например, консольный скрипт – делай а, в, с и т.д. Синхронный вызов заставляет наш интерпритатор ждать, потом он пишет ответ в info, если вышла какая-то ошибка, то это исключение, и оно отлавливается при помощи try catch:

Асинхронный вариант работает по-другому. Здесь, как видите, другой вызов:

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

При этом, обертывать этот вызов в try catch не имеет особого смысла. Конечно, можно, но, с другой стороны, при этом вызове ошибки никакой не возникнет. Этот метод устроен так, что работает асинхронно и все ошибки передает callback. На эту тему в Node.js есть соглашение: все встроенные модули ему следуют, и мы тоже, что первый аргумент функции обработчика является всегда ошибкой. То есть, эту функцию для примера назовем сb.

При ошибке будет вызвано так: cb(err), а если ошибки нет – cb(null, …). Соответственно, важное отличие между асинхронным и синхронным вариантом здесь в том, что если мы в синхронном варианте вдруг забыли try catch, то при ошибке нам обязательно станет это известным. Исключение выпадет и повалит процесс в данном коде. В асинхронном варианте, если мы забыли обработать ошибку, то оно будет глючить страшным образом. А мы не получим информации об этом. Соответственно, очень важно при асинхронной разработке обязательно хоть как-то обрабатывать ошибки. Конечно же, асинхронная разработка сложнее, нужно делать какие-то функции обратного вызова, но, вместе с тем, здесь есть свои способы упростить жизнь, которые  мы рассмотрим в следующих статьях.

Код урока вы можете найти здесь

I-know-async
Материал урока взят из следующего скринкаста.

We are looking forward to meeting you on our website soshace.com

About the author

Stay Informed

It's important to keep up
with industry - subscribe!

Stay Informed

Looks good!
Please enter the correct name.
Please enter the correct email.
Looks good!

Related articles

Уроки Express.js . Логгер, Конфигурация, Шаблонизация с EJS. Часть 2.

Favicon – это все connect Middleware, он смотрит, если url имеет вид favicon.ico, то он читает favicon и ...

3. Уроки Express.js. Шаблонизация с EJS: Layout, Block, Partials

В реальной жизни у нас обычно больше, чем один шаблон. Более того, если уж так ...

24.11.2016

Уроки Express.js. Основы и Middleware. Часть 2.

Всем привет! Давайте продолжим наш урок об основах Express и Middleware. Итог (добавим в ...

2 comments

Sign in

Forgot password?

Or use a social network account

 

By Signing In \ Signing Up, you agree to our privacy policy

Password recovery

You can also try to

Or use a social network account

 

By Signing In \ Signing Up, you agree to our privacy policy