Reliable by Design
エラー処理、入力検証、監視、復旧は、機能と同時に設計します。最初の障害のあとに足すのではありません。失敗するなら、見える形で、予測できる形で失敗するべきです。
技術
このページは、フレームワークの一覧ではなく、エンジニアリング上の判断について書いています。道具は案件ごとに変わります。原則は変わりません。
エンジニアリングの原則
どれにもコストがあります。そのコストを受け入れるのは、そうしない場合、本番稼働のあと、より悪いタイミングで表面化することが多いためです。
エラー処理、入力検証、監視、復旧は、機能と同時に設計します。最初の障害のあとに足すのではありません。失敗するなら、見える形で、予測できる形で失敗するべきです。
他のシステムが必要とするものは、定義した契約を持つ明示的なインタフェースで公開します。連携が内部実装の細部に依存しないようにします。
Secrets、認証、認可、検証はサーバー側に置きます。クライアント側のコードは公開されているものとして扱い、権限は動く範囲で最も狭いものにします。
動く部品を減らし、一般的な型に従い、読めるコードにします。複雑さは、問題がそれを求めるときにだけ足します。あとで保守するのは別人だからです。
運用上重要なシステムには、logging、計測、ヘルスチェックを付けます。動きとコストの問いに、想定ではなくデータで答えられるようにします。
アーキテクチャ
出発点とする既定です。理由があれば外して構いません。その理由は文書に残します。
ご覧のサイトも同じ方針です。ページはあらかじめ静的 HTML として生成され、Cloudflare の edge network から配信されます。ページ閲覧時に server-side rendering もデータベース照会も発生しません。リクエスト時に動くコードは、 /api 配下の少数の API だけです。ヘルスチェック、サービス一覧、お問い合わせ用 endpoint、および将来用に予約した決済 endpoint です。
health endpoint は、こちらで確認できます。 /api/health.
対応領域
日常的に扱う範囲です。この範囲の外になる場合は、その場で申し上げます。お客様の案件で学ぶ、ということはしません。
作業を限定した model の利用です。検証、代替の動き、コストの見通しを付けます。
版管理された HTTP のインタフェース、webhook、認証されたサービスの境界です。
スケジュールまたはイベントで動く処理です。再試行、logging、例外キューを持ちます。
構造化データとテキストに対する正規化、検証、変換です。
serverless と edge への配置、環境の分離、管理された secrets です。
アクセスしやすく、画面幅に応じたインタフェースです。検証はサーバー側で一貫して行います。
運用システム間の接続です。項目ごとの所在を明示します。
システムが使う同じデータに基づく、運用上の帳票と計測です。
すでにソフトウェアがある場合、作り直すより、評価の方が役に立つことが多いです。現行の実装を確認し、残す価値があるものをご説明できます。