はじめに
ここからいよいよ 「動くもの」 を作り始める。
今回は Node.js を使って、
Angularから呼び出される前提のAPI を、
TypeScriptで最小構成から作ってみる。
目的は、
- Node.jsが何をしているのか
- APIとは何を返すものなのか
- TypeScriptがどこで効いてくるのか
を、実装を通して理解すること。
APIとは何か（超ざっくり）
APIは、
「リクエストを受けて、結果を返す窓口」
画面を持たず、
HTMLも返さない。
返すのは基本的に JSON。
{
"message": "hello"
}
Angularは、このJSONを受け取って
画面に表示したり、処理に使ったりする。
今回の構成
今回は学習用として、
Express + TypeScript を使う。
理由は単純で、
- Node.jsの素の動きが分かりやすい
- 処理の流れが追いやすい
- 後でNestJSに移行しやすい
という点。
最小のAPI構成イメージ
src/
├─ index.ts
└─ routes/
└─ hello.ts
- index.ts：サーバー起動
- hello.ts：API定義
サーバーの役割を理解する
Node.jsのAPIサーバーは、基本的に次の仕事しかしない。
- リクエストを受け取る
- 必要なら処理する
- JSONを返す
画面のことは一切考えない。
ここが、
Angularとの大きな役割分担になる。
TypeScriptが効いてくる場面
APIを書くときも、TypeScriptは効いてくる。
たとえば、
- 受け取るパラメータ
- 返すデータの形
- 処理結果の型
を明示できる。
type HelloResponse = {
message: string;
};
これだけで、
- このAPIは何を返すのか
- 文字列なのか、数値なのか
がはっきりする。
「とりあえず動く」より「分かる」
この段階では、
- 認証
- DB接続
- 複雑なルーティング
は不要。
むしろ、
- なぜこのファイルが必要なのか
- なぜJSONを返すのか
- なぜ画面を持たないのか
を理解する方が重要。
Angularから呼ばれる前提で考える
このAPIは、
将来Angularから呼ばれる。
つまり、
- URLがある
- HTTPメソッドがある
- JSONを返す
という条件を満たしていれば十分。
UIの都合に引っ張られず、
APIはAPIとして独立させる。
Day03 時点での理解でOKなこと
この時点では、
- Expressの細かい設定
- ミドルウェアの深い理解
- 本格的な設計
は分からなくていい。
分かっていればOKなのは、
- Node.jsは「処理担当」
- APIは「JSONを返す」
- TypeScriptは「設計を助ける」
この3つ。
Day03 のまとめ
- Node.jsは画面を持たない
- APIはJSONを返すだけ
- AngularとはHTTPでつながる
- TypeScriptで「返すもの」が明確になる
次回は、
このAPIを少しだけ整理して、
「業務っぽい形」に近づけていく。
次回予告
Day04：APIを分割する（Controller的な考え方）
コメント