Автор оригинала: Kevin Kononenko.
Если вы когда-либо посещали ресторан Sit-Down, вы можете понять основы Express.
Если вы просто начинаете создавать свой первый конец Node.js … вы можете быть в неровной поездке.
Да – это, безусловно, легче изучать узел, если у вас прошедший опыт работы с JavaScript. Но проблемы, с которыми вы столкнетесь, при создании заднего конца совершенно разные, чем те, которые вы сталкиваетесь с использованием JavaScript на переднем конце.
Когда я узнал узел, я выбрал трудный путь. Я изучал электронные книги, письменные учебные пособия и видео вплоть и снова, пока я наконец понял Почему Я делал то, что занимаюсь.
Есть проще. Я собираюсь использовать аналогию ресторана для объяснения четырех ключевых частей вашего первого приложения Express. Express.js Это популярные рамки для организации вашего кода, и я бы порекомендовал его для любого новичка. Я объясню дальше через мгновение.
Вот четыре ключевых деталя, которые мы будем покрывать:
- Требования требуются
- Промежуточное программное обеспечение
- Маршрутизация
- App.listen ()/Запуск сервера
В этой аналогии вы являетесь владельцем ресторана, который хочет нанять генерального директора – человеку, который создает все процессы и управляет этим местом, так что он бежит гладко, и клиенты оставляют счастливыми.
Вот предварительный просмотр того, что дальше:
К концу вы поймете функциональность каждой части приложения Basic Express.
Шаг 1: Найм менеджера (требуется заявления)
В этом примере вы являетесь владельцем ресторана. И вам нужно нанять эксперта по проведению повседневных операций вашего нового ресторана. Вы, конечно, не являетесь экспертом, и вы не можете оставить его на вайкете и кухне, чтобы выяснить.
Если вы хотите запустить эффективный и безопасный ресторан, вам нужен кто-то, чтобы ваш персонал работал с максимальной эффективностью. Экспресс – новый менеджер.
Первая часть довольно простая. Как и с любым другим пакетом NPM, вам нужно NPM установить модуль Express, а затем использовать требуется Заявление для загрузки модуля.
В отличие от многих других пакетов NPM, вам также нужно использовать эту строку:
const app = express();
Это потому, что вам нужна переменная для удержания вашего нового экспресс-приложения. Экспресс не является частью узла по умолчанию.
Шаг 2: принятие решений в ресторане (промежуточное программное обеспечение)
Давайте сделаем шаг назад здесь. Какие обычные процедуры происходят в ресторанах? Есть три, которые сразу прыгают в голову:
- Посадка новых клиентов
- Принимать продовольственные заказы
- Представляя проверку в конце еды
Для каждого из них есть ряд проверок, которые вам нужно запустить, прежде чем вы сможете выполнить действие. Например, прежде чем у вас сиденье клиентов вам нужно знать:
- Они носят рубашку и обувь (и штаны)? В противном случае они не могут сидеть.
- Если они хотят сидеть в баре, они 21 год (если вы находитесь в Соединенных Штатах)?
Это не пляжный бар! Точно так же в вашем коде вам необходимо проверить, что запросы имеют определенные критерии, прежде чем они смогут продолжить. Например, если человек пытается войти на ваш сайт:
- У них есть аккаунт?
- Они ввели правильный пароль?
Это где концепция промежуточное программное обеспечение Приходит. Функции промежуточного программного обеспечения позволяют принимать меры по любому входящему запросу и изменить его перед отправкой ответа.
В вашем ресторане вам нужна серия правил, чтобы решить, если вы должны сидеть входящими людьми или нет. Допустим, пара гуляет по твоей двери. У вас есть одно правило, прежде чем дать им стол: они носят рубашку и обувь?
Во-первых, вы начинаете с app.use () Отказ Это означает, что это просто правила, которые необходимо применять для маршрутов, подходящих рядом. Они не получают, пост, поставили или удалять.
В строке 4 у вас есть анонимная функция с параметрами REQ, RES и затем. Для целей настоящего блока кода вы просто проверяете запрос (REQ), чтобы увидеть, имеет ли он рубашку и обувь.
Вам также необходимо использовать следующую () функцию в конце, потому что вы просто проверяете одежду здесь. Позже, в маршрутах вы позволите гостям получить фактический стол.
В строках 5 и 6 вы проверяете, есть ли у них рубашка и обувь.
А в строках 7-9 вы действуете только в том случае, если у них оба.
Блок кода выше отсутствует одна важная вещь: A путь Отказ Это определенная строка, включенная в запрос. И поскольку оно отсутствует путь, он будет работать по каждому запросу.
Можешь представить? Когда клиенты вошли в ресторан … Заказанные еды … Просили чек … Сотрудники будут вынуждены посмотреть вверх и вниз на них, чтобы убедиться, что они одеты! Это быстрый способ выйти из бизнеса.
Итак, мы изменяем строку 4 в примере выше. Теперь мы запустим этот код только при запросе пользователей вдоль маршрута «/Таблица».
Полное объяснение:
Шаг 3: выполнение общих процедур (маршрутизация)
Давайте продолжим пример сидения. До сих пор мы только знаем, как подтвердить, должен ли кто-то сидеть или нет. Но мы на самом деле не знаем, как привести их к столу и сидеть их.
Это где маршруты Войдите. Маршруты позволяют нам скрипт конкретные действия на основе путь Отказ Варианты получают, пост, поставить и удалить, но мы сосредоточимся на Get и Post на данный момент.
В контексте ресторана нам нужно создать запрос на получение, чтобы выбрать конкретную таблицу и сиденье гостей. Получает не изменять или добавлять в вашу базу данных. Они просто извлекают информацию на основе определенных параметров.
В этом случае, скажем, что вам нужно создать процедуру для сидения вечеринки из двух. Номер 2 пришел от клиента запрос.
Ладно, прежде чем я объясню: Да, это только отправка сообщения в конце. Он на самом деле не нашел определенную таблицу, чтобы он еще не посадил клиента. Мне нужно было бы найти массив для открытой таблицы, есть больше спины … Это за пределами объема этого учебника.
В строке 12 мы определяем процедуру поиска таблицы, когда гость Запросы вдоль «/стол» Маршрут Отказ Также как пример промежуточного программного обеспечения выше, у нас доступны параметры запроса и ответа. У этого также есть параметр , количество. Это два в этом примере.
На самом деле, все после объявления функции в строке 12 технически промежуточное программное обеспечение Так как он изменяет запрос пользователя. Вы увидите на диаграмме в конце.
В строке 13 мы получаем доступ к количеству людей на вечеринке от Параметры объекта запроса. Это не объявлено нигде, поскольку запрос пришел от пользователя, и у нас нет никакого интерфейса кода. Итак, вот какой запрос может выглядеть так, если это было настоящее приложение:
req = {
params: {
amount: 2;
}
}
В строке 13 наша партийная переменная обращается к сумме Недвижимость парадов объект в пределах Запрос Отказ
Наконец в строке 14, мы отправляем ответ Вернуться к клиенту: мы ищем таблицу сопоставленного размера.
Это много сразу. Вот диаграмма:
Шаг 3.5: Делать свой ресторан эффективный (маршрутизатор)
Теперь вы можете проследить полный путь от запроса на ответ. Но по мере роста вашего приложения вы не захотите кодировать правила для каждого маршрута индивидуально. Вы обнаружите, что некоторые маршруты имеют одни и те же правила, поэтому вам нужно найти способ применить один набор правил на несколько маршрутов.
С точки зрения сидения вы можете либо разместить ваших клиентов в баре или за столом. У тех правил общего, как рубашка + обувь, но сидения в баре требуют, чтобы каждый член партии был 21.
И, с точки зрения обслуживающих клиентов, вам нужно будет использовать немного другой процедуру для обслуживания закусок, основного курса и ужина. Но эти три маршрута также имеют много общего.
Это где Маршрутизатор Приходит. Маршрутизатор позволяет группировать свои маршруты, чтобы вы могли создавать общие правила.
Нам нужно создать промежуточное программное обеспечение для покрытия каждого из этих случаев. Я просто буду покрывать тестовые чехлы сейчас, поскольку оно перезаписает код выше.
Вот полный фрагмент кода:
Я собираюсь покрыть каждую часть индивидуально.
В строке 4 мы объявляем наш маршрутизатор.
В строках 6 и 14 теперь у нас есть SeatingRouter.use () вместо App.use (), чтобы указать, что это промежуточное программное обеспечение связано только с маршрутами синхронизации.
Наконец, в строке 21, мы добавляем больше промежуточного программного обеспечения, чтобы показать, что каждый маршрут синхронизации начинается с «/посадки». Итак, если кто-то запросил сиденье в баре, полный путь будет «/сидения/бар». Это может чувствовать немного из строя, поскольку вы можете ожидать, что путь будет определен, когда вы создаете маршрутизатор в строке 4. Это нормально!
Вот что в диаграмме форме:
И, когда вы добавляете маршрут Get, он идет выше последнего утверждения, где назначаете маршруты маршрутизатору.
Шаг 4: Открытие для бизнеса (порты)
Хорошо, последняя часть. До сих пор вы наняли менеджер, определили, что делать, прежде чем принимать запросы клиентов, и определили, что связано с конкретными запросами на клиента, как только они приходят. Теперь вам просто нужно определить адрес для места, где все это произойдет.
Ваш сервер имеет Порты которые видны как адрес для сама ресторана. Поскольку ваш сервер может сразу же справиться с множеством типов ресторанов (или сценариев на стороне серверов), вам нужно сказать, где каждый сценарий должен работать.
В приведенном выше примере порт 3000 и расположен на вашем компьютере. Так что если вы напечатаете:
https://localhost:3000/
В ваш браузер, и вы запустите приложение вашего узла, сервер знает, чтобы запустить определенный скрипт. В этом случае, как только вы входите в URL, вы будете регистрировать сообщение в консоли и иметь возможность использовать любой из ваших маршруты Отказ Если сам ресторан – это все ваше приложение, то теперь он открыт для бизнеса по адресу 3000.
Вам понравилось это? Если вы хотите получить уведомление, когда вы выпустите будущие учебные пособия, которые используют аналогии, Проверьте блог CodeAnalogies Отказ