почему app.listen должен быть в конце после всех запросов? и зачем это нужно?

Question

const app = express();
app.get("/", (req, res) => {
  res.send("Hello there");
});
const PORT = process.env.PORT || 5000;

app.listen(PORT, () => console.log(`server started on ${PORT}`));

Вот почему app.listen находится в конце? не следует ли разместить его перед app.get, чтобы он прослушивал запросы на порт 5000?

Answer 1

Вот почему app.listen() находится в конце?

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

не должен быть помещен перед app.get(), чтобы его прослушивание в порту 5000 для запросов

Нет, app.get() регистрирует обработчики маршрутов. «регистры» в этом случае означают, что он добавляет маршрут во внутренний список, поэтому при поступлении какого-либо будущего входящего запроса Express может просмотреть список, чтобы узнать, какие обработчики маршрутов соответствуют запрошенному пути. Объект app необходимо создать перед регистрацией обработчика маршрута на нем, но совершенно не важно, был ли сервер уже запущен или нет.

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

Итак, мы показали, что на самом деле не имеет значения, звонили ли вы app.listen() до или после Вы регистрируете свои маршруты. Маршруты регистрируются (для будущего использования) в любом случае.

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

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

Итак ... кажется, что для большинства нормальных кодов синхронной инициализации сервера не имеет значения, выполняете ли вы app.listen() до или после настройки маршрутов. Скорее всего, это делается последним, просто как логическое соглашение, которое кажется соответствующим порядком действий (настройте сервер, затем запустите сервер).

Я должен упомянуть один крайний случай. Если по какой-то причине часть инициализации вашего сервера включала выполнение асинхронных вызовов (например, некоторые app.get() находились внутри некоторого асинхронного обратного вызова), и вы выполняли app.listen() до того, как этот обратный вызов был запущен, то у вас будет открытое окно времени, в котором Сервер работал, но еще не настроен должным образом. Это не обычный способ настройки сервера, но все же это можно сделать. Таким образом, в этом случае, чтобы избежать обработки запросов на частично сконфигурированном сервере, вам нужно будет дождаться вызова app.listen(), пока не будут выполнены все асинхронные операции.