faultline v1.0.0 をリリースした

残念ながら2018年に入りましたが、リリースできました。

github.com

v1になって何が変わったのか?

基本的に機能追加などはありませんが、v0からいくつかBREAKING CHANGEが入りました。

BREAKING - レスポンスフォーマットを変更した

faultline v1で絶対にやりたかったところがコレでした。

RubyKaigi2017でonkさんの発表を聞いてとても勉強になりました。

RubyKaigi 2017 でどんな発表をしたか - onk.ninja

そして、fautlineのレスポンスフォーマットにしっくりきていなかったので、懇親会で質問させてもらってアドバイスをもらいました。ありがとうございました。

質問内容としては「レスポンスフォーマットを決める際に、何か参考になる情報もしくは標準的な仕様はありますか?」で、「あまりない、けど例えばGraphQLではResponseのフォーマットが定義されているよ」とアドバイスをもらっていろいろ調べた上でこれにしようということになりました。

BREAKING - FAULTLINE_* なenvを追加/デフォルト値を変更した

https://github.com/faultline/faultline/blob/master/docs/env.md に詳細を書いていますが、いくつかenvに手をいれました。

大きいのは

  • FAULTLINE_STAGE のデフォルト値を dev にした
  • FAULTLINE_DYNAMODB_TABLE_SUFFIX ( DynamoDBのテーブル名のサフィックス値)
  • FAULTLINE_ERROR_DATA_RETENTION_IN_DAYS ( fautlineに保存するエラー情報のTTL設定 ) を追加
  • FAULTLINE_DYNAMODB_READ_CAPACITY_UNITS
  • FAULTLINE_DYNAMODB_WRITE_CAPACITY_UNITS

などです。

これによりv0からv1にマイグレーションをしたい場合にはいくつか気をつけることがあります。

各ハンドラを middy でラップした

github.com

PrivateなSlackで @horike37 さんが紹介していたので見てみて、良さそうだったので採用してみました。

実際にはこんな感じ で、1つのハンドラでもミドルウェア層ができるだけでいろいろスッキリしました。

v0からv1へのマイグレーション方法

v0から使っている方は、APIエンドポイントのURLや蓄積したエラーデータなどをそのままにアップデートしたい方もいると思います。

Migration Guide: from v0.x to v1.x

a. 新しいfautlineスタックを作成してデータを移行する場合

新しいfautlineスタックを作る場合は、APIエンドポイントのURLは変わってしまいます。 S3のデータ構造やDynamoDBのデータ構造はv0と変わりませんので、awscliなどを利用してデータを移行してください。

b. v0のスタックをそのまま利用する場合

v0のスタックをそのまま利用する場合はAPIエンドポイントのURLも蓄積したエラーデータもそのままにできます。

v0のスタックをそのままにv1にマイグレーションしたい場合は、FAULTLINE_STAGEFAULTLINE_DYNAMODB_TABLE_SUFFIX を設定する必要があります(config.ymlで設定している場合は stagedynamodbTableSuffix になります)。

FAULTLINE_STAGE はv0と同様に(デフォルト値であれば v0 )に、 FAULTLINE_DYNAMODB_TABLE_SUFFIX は空値 ( '' ) にすればOKです。

fautlineのエンドポイントを同じにできれば、各アプリケーションに組み込んだfautlineのSDKの設定は更新する必要はありません。

fautline-webuiを使っている場合

v1ではレスポンスフォーマットが変更になっているので、fautline-webuiもv1にアップデートしてください

fautlineのこれから

機能面については最低限運用に耐えうるものができて一段落と思っています。

今回のアップデートで内部実装も結構リファクタリングできたので、機能追加もしやすくなりました。

もし次何か機能を追加するとしたらfautline自体をモニタリングする何かかなとか考えています。

というか、CloudWatchのダッシュボードの共有機能まだかな。。。