Когда нужно использовать асинхронные запросы а когда синхронные?

Question

[TheRevan]

Когда нужно использовать асинхронные запросы а когда синхронные?

Answer 1

[Lynn «Кофеман»]

Очень просто.
Асинхронные всегда.
Синхронные никогда.

https://developer.mozilla.org/ru/docs/Web/API/XMLH...

[...] В основном предпочтительно использовать асинхронные запросы вместо синхронных из-за соображений производительности.

Синхронный запрос приводит к выполнению кода, который "блокирует" взаимодействие с вкладкой браузера до тех пор, пока запрос не будет полностью выполнен, что существенно ухудшает отклик страницы.

Новомодный fetch вообще не имеет синхронной версии и даже старый добрый XHR сильно ограничен.

Comments

[АртемЪ]

Алексей Тен,
Бывают ситуации когда синхронные запросы неудобны, и надо использовать асинхронные.
Бывают и противоположные ситуации.

В основном предпочтительно использовать асинхронные запросы вместо синхронных из-за соображений производительности

Далеко не всегда важна производительность, зачастую в приоритете совсем другие вещи, в ущерб производительности.

Синхронный запрос приводит к выполнению кода, который "блокирует" взаимодействие с вкладкой браузера

Да, бывает что запросы выполняют из браузера. И такое случается. Но вопрос то про JS, а не про браузеры.

[Lynn «Кофеман»]

АртемЪ, Автор поменял вопрос. В первой версии фигурировали React и vue.js, так что браузер подразумевался.

Но, в общем-то в той же ноде вообще невозможно сделать синхронный запрос

[Павел Корнилов]

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

Для всех остальных случаев - да, вы правы.

[Александр Моргунов]

Павел Корнилов, проще как раз таки цепь callback'ов, чем блокировать поток.

[АртемЪ]

Алексей Тен, Понятно. Если в контексте браузерного JS то да, там крайне сложно придумать где синхронный запрос будет удобней.

А так JS это и нода, и скрипты администрирования, и много чего другого.

[Дмитрий Беляев]

Но, в общем-то в той же ноде вообще невозможно сделать синхронный запрос

Алексей Тен, можно, но придется использовать низкоуровневое апи, вроде net.Socket + fs.writeSync + fs.readSync и соответственно городить свои костыли. И хорошо если автор сего творения знает недокументированые сущности модуля http для парсинга ответа в http.IncomingMessage инстанс

[Lynn «Кофеман»]

Дмитрий Беляев, не надо подсказывать!

Answer 2

[АртемЪ]

Все просто -
Асинхронные - когда дальнейшая работа программы не зависит от выполнения запроса.
Синхронные - когда зависит.

Comments

[Александр Моргунов]

Если зависит дальнейшая работа, то есть callback.

[АртемЪ]

Александр Моргунов, callback разве останавливает исполнение программы до получения результата запроса?

[Александр Моргунов]

АртемЪ, при чем здесь остановка? Если важен дальнейший исход работы одного метода/функции для части кода, то почему бы не поместить эту часть кода в callback-функцию, чем блокировать поток синхронным запросом? Если важна цепочка событий, которые можно выполнить асинхронно, но они должны выполняться друг за другом, то почему бы не сделать всё это путем вложения необходимого функционала в следующий callback? Разработчики очень долго и упорно двигаются к асинхронной обработке данных и событий, а вы предлагаете откатиться назад?

[АртемЪ]

Александр Моргунов,

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

Ни в коем случае. Асинхронная обработка это отличная вешь, там где она нужна.
Но она не всегда нужна. Только и всего.

[Александр Моргунов]

АртемЪ, окей. В таком случае цепочка callback'ов в помощь. Не вижу проблемы.

[АртемЪ]

Александр Моргунов, Не совсем пойму зачем callback при синхронном выполнении.