Config as Code によるスキーマ駆動フロー

課題

多くの市場に対応するフローは、コードの重複を生み、プロダクトやコンプライアンスが地域ルールを変えたいたびにエンジニアリングのチケットが必要でした。

アプローチ

• スキーマからフォームを描画。 UI は jsonform を通じて JSON または YAML の設定を読み込み、スキーマがフィールドとバリデーションルールを生成します。ネイティブブリッジの起動などのカスタムアクションはコードに残します。
• 1つのステップ、異なる結果。 設定が、市場とプラットフォームごとにステップの動作を決めます。ネイティブ機能に対応していればガイドとスキャンボタンを表示し、そうでなければ通常のフォームフィールドと「続ける」ボタンを表示します。プロダクト側はコードではなく設定で変更します。
• コードとしての設定。 変更は Git で提出します。変更のたびに自動でプルリクエストが作られ、TypeScript の型に裏づけられた厳格なスキーマ検証つきの CI が走るため、不正な設定は本番に出る前に失敗します。

説明しておきたい2つの判断

描画は jsonform、アクションはコード。 サーバーから送られた任意のロジックを実行する完全サーバー駆動の UI は、リモートコード実行のリスクとパフォーマンス問題を招きます。データ駆動の描画と、事前コンパイル済みハンドラーに結びつけたアクションなら、その危険なしに柔軟性を保てます。

管理画面のフォームではなく Git。 ガバナンスのない手軽な編集は、本番のフローを壊します。プルリクエスト、型チェック、CI によって、すべての変更が追跡可能で、レビュー済みで、簡単に戻せるものになります。

結果

設定のリリースがフロントエンドのデプロイに依存しなくなり、複数市場の更新は数週間から数時間になり、地域ごとのコード重複も増えなくなりました。