5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

chaliceで複数API作る時に考えるプロジェクト構成

Last updated at Posted at 2018-09-19

chaliceの記事は日々増えてきており、情報を集めるには苦労しなくなってきた。
ただ、どれも1APIを作る部分の説明のみで、プロジェクトを続けていく中で複数APIを作る時にどんな構成を組んでるか記載されているものが少なかった。

少しハマったので、書いて残しておく。

基本の流れ

プロジェクト作成

chalice new-project api_1

これでAPIのプロジェクトを作成し、app.pyにコーディングしていく。
しかしこのプロジェクトに全部詰め込むのも管理し辛いので、API毎にファイルを分けたい。

デプロイ

chalice deploy

作成したプロジェクト内でデプロイのコマンドを叩くと、.chalice/config.json及び.chalice/policy-prod.jsonの設定に沿ってデプロイが実行される。
実行すると、deployeddeploymentsが作成される

gitプロジェクトの構成

├── README.md
├── api_1
│   ├── app.py
│   ├── requirements.txt
│   ├── chalicelib -> ../lib
│   ├── vendor
│   ├── .chalice
├── api_2
│   ├── app.py
│   ├── requirements.txt
│   ├── vendor
│   ├── .chalice
・・・
・・・

こんな感じにしたい。
api_1だけデプロイしたいとか当然あるし。

必要なこと

1. .chalice/config.jsonの"app_name"をそれぞれ独自のものにする

よくよく考えれば当たり前だが、app_nameはそれぞれのプロジェクト毎に独自に設定する
(api_1なら"api_1"、api_2なら"api_2"等)

config.json
{
  "version": "2.0",
  "app_name": "api_1",
  "stages": {
    "prod": {
      "api_gateway_stage": "prod",
      "manage_iam_role":false,
      "iam_role_arn":"arn:aws:iam::prod",
      "environment_variables": {
        "DEVELOP": "false"
      }
    },
    "dev": {
      "api_gateway_stage": "dev",
      "manage_iam_role":false,
      "iam_role_arn":"arn:aws:iam::dev",
      "environment_variables": {
        "DEVELOP": "true"
      }
    }
  }
}

2. 初回デプロイ時はdeployeddeploymentsは削除する

これも当たり前の話なんだけど、デプロイ実行で作成されるファイルはそのプロジェクト用なので、他のプロジェクトにコピーしちゃダメ。気付かずに時間だけ食ってしまった。

3. lambdaとAPIGatewayの関係を一対一にする

実装・デプロイを繰り返していると、lambdaとAPIGatewayの関係が歪になることをあるかもしれない。
作業中、何故か一つのAPIGatewayに複数のlambdaが乗っていた時があって、api_1をデプロイするとapi_2が502のエラーを返すようになった。

"ChaliceError": Execution failed due to configuration error: Malformed Lambda proxy response

その時は一度lambdaを削除してデプロイし直して、APIGatewayとの関連付けを一対一にする。

まとめ

chaliceはデプロイ周りが本当に楽で、ロジック作成に集中出来るので便利だが、いくつものAPIを作成するような大きなプロジェクトでは向いているのか正直まだ分からない。

が、気軽にサーバレスでAPIを作るにはもってこいなフレームワークであることは間違いない

余談

自作ライブラリを追加する場合は、同プロジェクト内のchalicelibに格納するのがセオリー。
docsにも記載されてる

├── api_1
│  ├── app.py
│  ├── chalicelib
│  │   └── utils.py

でもこれだとapi毎に用意しなければならないので、共通処理とか用意する時に不便。

[シンボリックリンクでもいける]

├── api_1
│  ├── app.py
│  ├── chalicelib -> ../lib
├── api_2
│  ├── app.py
│  ├── chalicelib -> ../lib
├── lib
│  └── utils.py
5
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?