Не можа знайсці модуль: налагадчык імпорта Express і параметраў маршруту

Дэбагаванне API параду погады на TypeScript Express частаючы дае большае розуміенне таго, як разам працюе бэкэнд на Node, чым які-небудзь іншы абстрактны практычны курс па REST.

Памылка

Пасля таго, як праект быў раздзелены на маршруты і кантролеры, сервер зазнаў неудачы з наступным месажам:

Cannot find module '../controllers/weatherController'

Такі месаж ўзніквае, калі бэкэнд складаецца з не адной файловай структуры. Express імпортуе weatherController, а час выканання не можа знайсці шлях да гэтага модуля.

Што пераканаць

Раследавайце прычыну неудачы па адрэжанам парадку, а не проста спадзяючыся.

Чы існуе файл? У падметку src/ должна быць такая структура:

src/
├── controllers/
│   └── weatherController.ts

Чы назва папкі абсалютна зусім тая ж? Лепш выкарыстоўваць controllers, а не controller чы Controllers. На файловых сістэмах, чутлівых да роўнагу, важна як множына, так і роўнавага.

Чы роўна падходзіць назва файла? Любачыце weatherController.ts, а не WeatherController.ts, weathercontroller.ts чы weather-controller.ts. Працэс развязкі модуляў у TypeScript спрацьоввае гэтыя назвы як разныя цялі.

Чы правільны шлях імпорту? У weatherRoutes.ts працэс імпорту і наладкі маршрутаў выглядае так:

import { Router } from "express";
import { getWeather } from "../controllers/weatherController";

const router = Router();router.get("/:city", getWeather);export default router;

Чы кантролер дэйсна экспортуе функцыю? Частая памылка — запісваць функцыю-обрабоўчык без export, тады імпорт маршрута не мае чаго прыўязваць.

import { Request, Response } from "express";

export const getWeather = (req: Request, res: Response): void => {
  const { city } = req.params;  res.json({
    city,
    temperature: 29,
    condition: "Cloudy",
    humidity: 82,
  });
};

Даданне export пры getWeather вярнуло сервер у робочы стан. Адна ключавая слова, адна выправленая памылка.

Што ўжо ўключае праект

У гэтым пункце контралю прыемная служба вжо адключае калькі, якія падобнае да тых у продакшэне:

• Інструментальная лінейка TypeScript для рэпазітарыя
• Рабочы працэс Express HTTP
• Адзінаковыя каталогі замест адна мега-файловая структура
• URL-маршруты, падключаныя да працоўнікаў
• Модулі-працоўнікі для логікі запытанняў
• Параметры шляху, такія як :city
• Структураваныя JSON-даныя
• Адліквідацыя проблемы з нехутчайным модулем па чэргавам перагляду шляхоў і экспортаў у местных умовах

Розумеўце параметраў маршрута

Апробаваце маршрут з HTTP-кліента, такога як Postman:

GET http://localhost:3000/weather/bangalore
GET http://localhost:3000/weather/mumbai
GET http://localhost:3000/weather/chennai

Кожна адаптацыя зміняе поле city. Фармат застаецца стабільным: temperature, condition і humidity застаюцца прыемнымі. Строка з назвай горада прадаецца з сегмента шляху пасля /weather/ і выказваецца як req.params.city. Гэта і ёсь цялесообразнае выкарыстоўванне параметра маршруту: адна вялічынка маршрута, але разныя значэнні па кожнай запытцы.

Наступны вызов: базавая перакананне

Запытка, падобная да наступнай, яшчэ можа успець з фальшывымі дадзеннямі:

GET /weather/123

і вяртае ўсё роўна што-небудзь падобнае да гэтага:

{
  "city": "123",
  "temperature": 29,
  "condition": "Cloudy",
  "humidity": 82
}

Назва горада не павінна складацца толькі з цыфр. Такія кейсы трэба адхіліць, а не спрыятаць іх як правільныя даны пра пагоду.

Пераканайце параметр горада за дапамою /^\d+$/. Калі адпаведнае падтрыманне, адпавяжце код 400 Bad Request, а не фальшывыя даны пра пагоду:

res.status(400).json({
  error: "City name must contain letters.",
});

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

Кароткая пераконтроўка знанняў

Короткі самапрабавач паказвае, чытыры мысці зрозумелы, а не проста успешна скомпіляваны код:

1. Як GET /weather/:city відрóżняецца ад GET /weather?city=bangalore? Сегменты шляху выкарыстоўваюць обав’язковыя параметры маршруту, якія ўключаны ў шаблон URL. Значэнні пасля ? ўжо являюцься параметрамі запыту і застаюцца необав’язковымі. Калі значэнне служыць для ідэнтыфікаціі рэсурсу, крашчэ выкарыстоўваць параметры маршруту; для фільтраў і настройкаў — параметры запыту.

2. Чаму вжываць res.status(400).json() заместо проста res.json()? Сама по сабе res.json() выдае статус 200 OK за замовчаннем. Для некорэктных дадзеных патрэбны статусы, якія сігналізуюць пра адзінак, а не толькі строка з адказам у тэле. Кліенты спакоююцца на гэты код.

3. Кой слой керуе бізнес-правіламі — рутэр, кантролер чы ў іншым месцы? Правілы трэба размешчаць у кантролерах. Рутэры толькі супакоююць метод HTTP і шлях з апрацоўшчыкам. Перакананне дадзеных і званні на зовнішнія рэсурсы спачатку выкананы ў кантролерэ, а праз тое, калі прыложэнне растае, пераводзяцца ў модуль службы.

4. Чы ўмоць req.params.city для запіту GET /weather/mumbai? Строка "mumbai", адносна той, як яна была запісана ў шляху.

Што будзе далей

Мадэльяванне парадожніх умоў паветра выканала сваю працу. Наступны ўзлок являе сабою API для рэальных парадожніх умоў паветра, што включае:

• Выклік зовнішняга HTTP API
• Зменныя сераўіса (.env) так, каб ключы ніколі не былі закодаваны безпосерэдна ў кодзе
• Выварытак fetch або axios для адправкі запіта
• Чыстая обработка тайма-аўтаматав і адказоў з вышэйшагіх роўней
• Папка з сервісамі, каб контролеры не абавяліся працай з HTTP-кліентам

Шлях запіта павышаецца на ўзлок:

Browser/Postman
      │
      ▼
   Routes
      │
      ▼
 Controllers
      │
      ▼
  Services
      │
      ▼
Weather API (external)

Такая структура з узлакамі падходзіць для багато продакшн-прыемлень Express. Іе поступовая стварэнне дазволяе заставіць чыстую точку вярнення, калі зламаецца інтэграцыя з рэальнымі данымі, у працоўнасці замест таго, каб усе проблемы складваць у аднам файле.