プロトタイピングのためのスタブAPIサーバ

APIサーバが出来てない、 もしくはAPIサーバが外部サーバのため開発、テストへ利用しづらい時にスタブのAPIサーバを作る。
外部のAPIサーバのように振る舞うサーバをlocalhost上に作る。

何がうれしいのか

リクエストを送るとほしいレスポンスが帰ってくるので、 APIサーバがなくてもクライアント側の開発に専念できる。

初期にAPIのスタブサーバが出来てしまうと

  • サーバサイドエンジニア => スタブサーバと同じjsonを返すようにサーバサイド開発
  • フロントエンドエンジニア => スタブサーバが返すjsonをパースするインタフェースを作成できる

jsonの型を先に握ってしまえば並行開発が可能、テストやりやすくなる、など結構捗るので積極的に導入すべき。

APIドキュメントの自動生成

加えてドキュメントサーバとして動くスタブサーバであればさらに便利。

また、APIドキュメントのメンテは面倒で放置されやすいため、テストやスタブサーバから自動生成するようにしておく。

実際にあった話として

  • APIの仕様書にjsonレスポンスがない
  • APIの返すレスポンス内容が仕様書と違っている
  • 外部APIサーバのレスポンスデータが少ない、中身がない

あとからテスト・デバッグが面倒になってきて泣きそうになった。APIスタブサーバは先に作るべき。

node-easymockでスタブサーバ作る

  • npm i easymock --save-devで開発環境用にインストール
  • path/to/end-point_get.jsonのようなファイル名でレスポンスボディのJSONを記述する
  • localhost:8000/_document で整形されたAPIドキュメントが返される

非常にシンプル。 POSTで認証用のレスポンスも返せる、ドキュメントサーバがありアクセスログも記録される。

起動スクリプトを作る

package.jsonに以下のような記述をして起動スクリプトを作成する。

"scripts": {
  "easymock": "easymock --port 8000 --path spec/api/easymock"
}

ターミナルでnpm run easymockを実行するとspec/api/easymockを起点に配置したパス(path/to/end-point)でAPIスタブサーバが起動する。

リーンな開発のためのAPI開発

下記のような順序で開発すると捗る。(実際に捗った) 両方担当するのが必須ではないが、フロントエンド・サーバサイドを両方触れるAPIを開発するエンジニアがいると並行開発をコントロールしやすい。

  1. APIレスポンスとなるjsonを決める
  2. フロントエンドのAPI叩くマネージャ的なサービスのモック(モック内にjson持っているだけで実際にリクエストしない)を作る
  3. フロントエンドのロジック書く人にタスクを切り出す
  4. APIスタブサーバ作る
  5. フロントエンドのAPI叩くマネージャ的なサービス内を実装し、モックを置き換える
  6. サーバサイドのrouting/controller/view(json)を作成し、APIスタブサーバなしの疎通確認
  7. サーバサイドでDBの型を決定し、モデルレイヤ書く
  8. サーバサイドにビジネスロジックを書いていく

柔らかい所から作り始める

経験則的にあとから大きな変更があると面倒な部分はモデル、DB周り。
Railsでの通常の開発だとmodel、controller、viewの順で作っていく。
プロトタイピング的な観点でプロダクトを作る場合、変更コストの高いDB設計をどれだけ遅延させられるかがキモになる。
フロントエンドは一旦先に決めはするものの、一度固めたjsonをちょいちょいいじるだけなので変更が非常に簡単である。
硬いDB部分は一番最後に、 一方柔らかいフロントのモデル周りは先にやる。
ユーザテスト後にDB周りの設計やるくらいがちょうどいい。