この記事は投稿日付とカレンダーの日付があわないことで知られるあら便利カレンダーの ${n} 日目の記事です。

挨拶

AWS Lambda + API Gatewayを使ってサーバーレスなREST APIを作成したいことってよくありますよね。
みなさんどうしてますか？

ぼくは度々考えないといけないなあって場面に直面しつつもなんだかんだ逃げてきたんですが、
いよいよ本格的に考えないといけない事態に陥って、
現時点で「これだ！」っていうパターンにたどりついたので記事にしました。

ぶっちゃけかなり正直ベースで書きます

tl;dr

  • aws-serverless-express
  • serverless framework
  • tsorm

を使って開発することに決めたよ。

前提

  • REST APIが作りたい
  • AWS Lambda + API Gatewayで動作すること
  • TypeScript
    • 生なJavaScriptはいい加減つらい
  • serverless frameworkを利用すること
    • deployや管理が楽
    • 慣れている
  • Migrationがあるとベター

ある程度まで絞る編

まずはお馴染みのNode Frameworksを拝見。
以下から選べとあったので、ちょろっと解説つけて挙げる。

  • MVC
    • シナトラ風
      • ルーティング周りやリクエスト・レスポンス周りの面倒を見てくれるのみの軽量なもの
    • Rails風
      • PHPやRubyのフレームワークで実現されている範囲に関心のあるもの
  • Full-stack
    • websocketやテンプレートエンジンをサポートしたNode.jsならではのものも積んだ全部入り
  • REST API
    • SPAを構築する用にある程度軽量なRESTを実装できるような思想をもったもの
  • Others
    • ミドルウェアやライブラリ・静的サイトジェネレータみたいなもの

とりあえずOthersは除外。そうじゃない。
REST故にViewが不要なので、MVC.Rails風も除外。
Lambdaでやりたいが故に、websocketなどは使わないので上記の意味でのFull-stackな必要がないため、Full-stackも除外。
残ったMVC.シナトラ風とREST APIから検討していくことにする。

ある程度信用できるアプリケーションであって欲しいので、GitHubのStarの数を指標とする。
そうすると、ダントツなものが１つずつ出てくるのでそれに絞って調査していくって気持ちになった。
（３，４位くらいだと4,000くらいのスター数で対抗馬がいくつもあって選ぶ気にならない）
カッコ内は記事執筆時点でのスター数

  • MVC.Rails風
    • Sails.js（19,285)
      • 名前の通りかなりRailsっぽい感じ
  • REST API
    • LoopBack(11,324)
      • IBM bluemixで採用されている？フレームワークっぽい

踏み込んで見る編

さて、２つまで絞れたので、ある程度覚悟していたLambdaAdapterみたいなのを書いて動くか検証する必要がでてきた。
私はとんでもなく突飛な行動に出る癖があるので、
node meteor aws lambda
で検索していた。
本音を言うと、名のしれたフレームワークならなんかしら挑戦してるやつが全世界に何人かいるだろうって期待があって調べてみた次第である。

一番上に表示された記事はmeteor-lambdifyというGitHubのリポジトリのページだった。
以下翻訳して抜粋

更新：
これを本番環境で使用しようとしましたが、実際には機能しません。
問題は、Lambdaがノードプロセスを実行し続けることであり、これは毎回同じように動作するブートプロセスに依存しています。
しかし、ノードプロセスがまだ実行されてrequireいる場合は、ロードされたファイルがキャッシュされるため、プロセスは毎回同じ方法で起動しません。
AWS Elastic Beanstalkの作業層でMeteorワーカーを実行するようになりました。

実際には機能しません。

実際には機能しません。

実際には機能しません。

もうフレームワーク使うのやめよう…って決意しました。
申し訳ないんですが、残り２つもさらーっと調べたところ有用な記事もなく、
Lambdaの癖的な部分に苦しめられそうで考えるのをやめました。

諦めきれない編

でもスクラッチでやるのは絶対にいやだ。
メンテコストが高すぎるし、影響範囲を完全に把握できてしまうせいで、
修正が発生した場合の

1.「あっやばい、あそこにも影響あるな」
2. 範囲広いのはコードを書いた自分が一番わかってる
3. コストが高いのが明確にわかってやる気なくなる

みたいな黄金パティーンはもういやだ。
前のプロジェクトでやったから本当にもういやだ。

もうちょっと、もうちょっとだけ頑張ってみるから…

見直してみる編

思い直してみると（ === 後出しジャンケンすると）aws-serverless-expressは触ったことがある。
ぼくらが本当にやりたいことは

  1. Routerがほしい
  2. Requestをいい感じにラップしてほしい
  3. Responseをいい感じにラップされたものベースで返したい
  4. データ永続化に関してクエリ書きたくない
  5. Migrationほしい（クエリ書きたくないし、管理したい）
  6. DDDっぽく使いたい

あたりで、「ビジネスロジックに集中できればいいや」が本質なはず。
Expressを使う前提だと、1-3はクリアできる。
では、4-6を満たしてくれるORMっぽいなんかがあればそれ組み合わせればいけるんじゃね！？

あった編

ありましたあ
https://github.com/typeorm/typeorm

まとめ

あった編 はまじで

  • typescript orm で探したら一番上だった
  • Migrationあった
  • Model層あった
    • ActiveRecordパターンぽいけどまあよし！

ってことで導入を決めました。

実際にこれを使って開発をすすめるのはこれからになるので、
感想はまた数ヶ月後にご期待ください！

思考回路がこうなってるよって参考となれば幸いです。

元記事はこちら

「AWS Lambda利用を前提にフレームワークを選ぶときに僕がかんがえたこと」