Вийти їсти та зрозуміти основи Express.js

Вийти їсти та зрозуміти основи Express.js

Якщо ви коли-небудь відвідували ресторан, що сидить, тоді ви можете зрозуміти основи Express. Але якщо ви тільки починаєте створювати свій перший задній кінець Node.js ... можливо, вас чекає нерівна їзда.

Так - звичайно, легше вивчити Node, якщо у вас є досвід роботи з JavaScript. Але виклики, з якими вам доведеться зіткнутися під час створення внутрішнього інтерфейсу, зовсім інші, ніж ті, з якими ви стикаєтесь під час використання JavaScript на передньому кінці.

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

Є простіший спосіб. Я збираюся використати аналогію ресторану, щоб пояснити чотири ключові частини вашого першого додатку Express. Express.js - це популярний фреймворк для організації вашого коду, і я б рекомендував його для початківців. Поясню далі за мить.

Ось чотири ключові частини, які ми розглянемо:

  1. Заяви вимагати
  2. Проміжне програмне забезпечення
  3. Маршрутизація
  4. App.listen () / Запуск сервера

За цією аналогією, ви власник ресторану, який прагне найняти генерального менеджера - людину, яка створює всі процеси та керує місцем, щоб воно працювало безперебійно, а клієнти йшли задоволеними.

Ось попередній перегляд наступного:

Зрештою, ви зрозумієте функціональність кожної частини базової програми Express.

Крок 1: найняти менеджера (вимагати виписки)

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

Якщо ви хочете запустити ефективний та безпечний ресторан, вам потрібен хтось, щоб ваш персонал працював з максимальною ефективністю. Експрес - новий менеджер.

Перша частина досить зрозуміла. Як і в будь-якому іншому пакеті NPM, вам потрібно встановити експрес-модуль npm, а потім використовувати оператор require для завантаження модуля.

На відміну від багатьох інших пакетів NPM, вам також потрібно використовувати цей рядок:

const app = express();

Це пов’язано з тим, що вам потрібна змінна для зберігання вашої нової програми Express. Express не є частиною Node за замовчуванням.

Крок 2: Прийняття рішень у ресторані (проміжне програмне забезпечення)

Зробимо крок назад. Які загальні процедури бувають у ресторанах? Є троє, які одразу вскакують мені в голову:

  1. Розміщення нових клієнтів
  2. Прийом замовлень на їжу
  3. Пред'явлення чека в кінці їжі

Для кожного з них існує ряд перевірок, які потрібно виконати, перш ніж можна виконати дію. Наприклад, перед тим, як розсадити клієнтів, потрібно знати:

  1. Вони носять сорочку та взуття (та штани)? В іншому випадку їх не можна посадити.
  2. Якщо вони хочуть сісти за бар, чи їм 21 рік (якщо ви перебуваєте в США)?

Це не пляжний бар! Подібним чином у коді вам потрібно буде перевірити, чи мають запити певні критерії, перш ніж вони зможуть продовжуватись. Наприклад, якщо людина намагається увійти на ваш сайт:

  1. У них є рахунок?
  2. Вони ввели правильний пароль?

Тут з’являється концепція проміжного програмного забезпечення . Функції проміжного програмного забезпечення дозволяють вживати дії щодо будь-якого вхідного запиту та модифікувати його перед тим, як надіслати відповідь назад.

У вашому ресторані вам потрібна низка правил, щоб вирішити, чи слід вам розміщувати людей, що приходять, чи ні. Скажімо, пара проходить через ваші двері. У вас є одне правило перед тим, як подавати їм стіл: вони одягнені в сорочку та взуття?

Спочатку ви починаєте з app.use (). Це означає, що це просто правила, які потрібно застосовувати до маршрутів, що йдуть далі. Вони не є GET, POST, PUT або DELETE.

У рядку 4 у вас є анонімна функція з параметрами req, res та next. Для цілей цього блоку коду ви просто перевіряєте запит (запит), щоб перевірити, чи є в ньому сорочка та взуття.

Вам також потрібно використовувати функцію next () наприкінці, оскільки ви просто перевіряєте тут одяг. Пізніше, у маршрутах, ви дозволите гостям отримати фактичний стіл.

У рядках 5 і 6 ви перевіряєте, чи є у них сорочка та взуття.

А в рядках 7–9 ви продовжуєте лише якщо вони мають обидва.

У наведеному вище блоці коду відсутня одна важлива річ: Шлях . Це конкретний рядок, що входить до запиту. І оскільки в ньому відсутній шлях, він буде виконуватися при кожному окремому запиті.

Чи можеш ти уявити? Коли клієнти заходили до ресторану… замовляли їжу… просили чек… працівники змушені були дивитись на них догори і вниз, щоб переконатися, що вони одягнені! Це швидкий спосіб вийти з бізнесу.

Отже, ми міняємо рядок 4 у прикладі вище. Тепер ми будемо запускати цей код лише тоді, коли користувач запитує за маршрутом '/ table'.

Повне пояснення:

Крок 3: Виконання загальних процедур (маршрутизація)

Продовжимо з прикладом сидіння. Поки що ми знаємо лише, як перевірити, чи повинен хтось сидіти чи ні. Але ми насправді не знаємо, як провести їх до столу і сісти.

Тут трапляються маршрути . Маршрути дозволяють нам створювати сценарії конкретних дій на основі шляху . Варіанти: GET, POST, PUT та DELETE, але ми зосередимося зараз на GET і POST.

У контексті ресторану нам потрібно створити запит GET, щоб вибрати конкретний стіл і розсадити гостей. GET не змінює та не додає до вашої бази даних. Вони просто отримують інформацію на основі конкретних параметрів.

У цьому випадку, скажімо, вам потрібно створити процедуру для розміщення партії з двох осіб. Номер 2 походить із запиту замовника .

Добре, перш ніж пояснити: Так, це лише надсилання повідомлення в кінці. Насправді він ще не знайшов конкретного столу для розміщення клієнта. Мені потрібно було б шукати масив для відкритої таблиці, мати більше попередньої історії ... що виходить за рамки цього підручника.

У рядку 12 ми визначимо процедуру для знаходження таблиці , коли гість просить уздовж «/» таблиці маршруту . Як і в прикладі проміжного програмного забезпечення вище, ми маємо доступні параметри запиту та відповіді. Він також має параметр , кількість. У цьому прикладі це два.

Насправді все після оголошення функції у рядку 12 є технічно проміжним програмним забезпеченням, оскільки воно змінює запит користувача. Ви побачите на схемі в кінці.

У рядку 13 ми отримуємо доступ до кількості людей у ​​партії з параметрів об’єкта запиту. Це ніде не декларується, оскільки запит надійшов від користувача, і у нас немає коду інтерфейсу. Отже, як би міг виглядати запит, якби це був справжній додаток:

req = { params: { amount: 2; }}

У рядку 13, наша змінна сторона звертається до сум майна в Params об'єкта в межах запиту .

Нарешті, у рядку 14 ми надсилаємо відповідь клієнту: ми шукаємо таблицю відповідного розміру.

Це одразу багато. Ось схема:

Крок 3.5: Зробіть свій ресторан ефективним (маршрутизатор)

Тепер ви можете простежити повний шлях від запиту до відповіді. Але оскільки ваш додаток збільшується в розмірі, ви не захочете кодувати правила для кожного маршруту окремо. Ви побачите, що деякі маршрути мають однакові правила, тому вам потрібно знайти спосіб застосувати один набір правил до кількох маршрутів.

Що стосується місць, ви можете посадити своїх клієнтів за барною стійкою або за столом. У них є спільні правила, такі як сорочка + взуття, але сидіння в барі вимагає від кожного члена партії 21 року.

І, що стосується обслуговування клієнтів, вам потрібно буде застосувати дещо інший порядок подачі закуски, основної страви та вечері. Але у цих трьох маршрутів також є багато спільного.

Тут з’являється маршрутизатор . Маршрутизатор дозволяє групувати маршрути, щоб можна було створити загальні правила.

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

Ось повний фрагмент коду:

Я збираюся висвітлити кожну частину окремо.

У рядку 4 ми оголошуємо наш маршрутизатор.

У рядках 6 та 14 ми тепер маємо seatRouter.use () замість app.use (), щоб вказати, що це проміжне програмне забезпечення стосується лише маршрутів sittingRouter.

Нарешті, у рядок 21, ми додаємо більше проміжного програмного забезпечення, щоб показати, що кожен маршрут routeRouter починається з "/ посадка". Отже, якби хтось попросив місце в барі, повний шлях мав би бути «/ посадка / бар». Це може здатися трохи невпорядкованим, оскільки ви можете очікувати, що шлях буде визначений під час створення маршрутизатора в рядку 4. Це нормально!

Ось це у вигляді діаграми:

І коли ви додаєте маршрут GET, він переходить над останнім оператором, де ви призначаєте маршрутизатору маршрутизатор.

Крок 4: Відкриття для бізнесу (порти)

Гаразд, остання частина. Наразі ви найняли менеджера, визначили, що робити, перш ніж приймати запити клієнтів, і визначали, що робити з конкретними запитами клієнтів, як тільки вони надходять. Тепер вам просто потрібно визначити адресу місця, де все це станеться.

На вашому сервері є порти , подібні до адреси самого ресторану.Оскільки ваш сервер може одночасно обробляти багато типів ресторанів (або сценарії на стороні сервера), вам потрібно вказати йому, де повинен запускатися кожен сценарій.

У наведеному вище прикладі порт становить 3000 і він знаходиться на вашому комп’ютері. Отже, якщо ви введете:

//localhost:3000/

у вашому браузері, і ви запускаєте програму Node, сервер знає, щоб запустити конкретний сценарій. У цьому випадку, як тільки ви введете URL-адресу, ви ввійдете повідомлення в консоль і зможете скористатися будь-яким із ваших маршрутів . Якщо ресторан сам по собі є вашим додатком, то він тепер відкритий для бізнесу за адресою 3000.

Вам сподобалось це? Дайте йому плескати, щоб інші могли це також виявити. І якщо ви хочете отримувати сповіщення, коли я випущу майбутні підручники, які використовують аналогії, підпишіться тут: