Не можа знайсці модуль: налагадчык імпорта 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. Їе поступовая стварэнне дазволяе заставіць чыстую точку вярнення, калі зламаецца інтеграцыя з рэальнымі данымі, у працоўнасці замест таго, каб усе проблемы складваць у аднам файле.