ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
クライアントに手を加えずにサーバー側の連携を移行する
よく設計されたバックエンドアーキテクチャの好ましい特性の1つは、プロバイダーの移行を内部APIの境界の裏側だけで完結させ、サービスを利用するWebやモバイルのクライアントからは見えないようにできることです。これを実現できるかどうかは、移行先のプロバイダーが何かということよりも、移行を始める前にその境界がコードベースにきれいに存在しているかどうかにかかっています。
重要な設計原則は、クライアントアプリケーション(Webフロントエンド、モバイルアプリ、その他の社内サービス)が、サードパーティのジオコーディングプロバイダーと直接やり取りしたり、そのプロバイダーの生のレスポンス形式をそのまま受け取ったりするのではなく、独自に正規化したレスポンス形式を返す自社のAPIとやり取りすべきだということです。その境界があれば、プロバイダーの移行は自社のエンドポイントの裏側の実装にしか影響せず、そのエンドポイントを利用するすべての側は、運ではなく設計によって影響を受けません。
その境界がまだ存在しない場合、つまりクライアントが現在特定のプロバイダーの生のレスポンス形式を受け取っている場合は、最初に多少の追加作業が発生するとしても、移行はそれを導入する妥当なタイミングです。手順はおおよそ次のとおりです。
- 独自の正規化されたレスポンス形式を定義します。特定のプロバイダーの慣習をそのまま写すのではなく、自社のアプリケーションにとって意味のあるフィールド名を選びます
- 現在のプロバイダーの実際のレスポンスからその正規化された形式への内部マッピングを構築し、すべてのクライアントを、プロバイダーの生のレスポンスではなく正規化された形式を使うように更新します
- すべてのクライアントが正規化された形式に更新されてデプロイされれば、その境界の裏側での実際のプロバイダーの移行は、クライアントとの調整が一切不要な、バックエンドだけの変更になります
初回は確かに作業が増えますが、以後のすべての移行でその効果が得られます。将来プロバイダーを変更する際に必要なのは手順3だけになるからです。
My Geocodeの互換ホストは、なじみのあるプロバイダーのレスポンス形式をそのまま保持するため、まだこの正規化レイヤーを構築していないチームは、既存のマッピングコードを書き直す必要のない暫定的な手段として互換ホストを利用できます。これにより、差し迫った期限に迫られて急ごしらえの正規化レイヤーを今作るのではなく、後でじっくり構築する時間を確保できます。利用可能な互換ホストの全体は互換ホストの概要で紹介しています。
バックエンドサービス自体の認証には、X-API-Key ヘッダー、Authorization: Bearer ヘッダー、HTTPベーシック認証、クエリパラメータのうち、バックエンドの既存の外部リクエストの慣習に最も自然に合うものを使えます。また、割り当ての使用状況はすべての呼び出しでレスポンスヘッダーを通じて確認でき、/docs/rate-limits/に記載されています。バックエンドはこれを一元的に監視でき、クライアント側は割り当てという概念の存在すら意識する必要がありません。
クライアントから見えないサーバー側の移行は特別な技ではなく、適切な境界がすでに整っているアーキテクチャの自然な結果にすぎません。移行のプレッシャーの中であっても、その境界を構築することは投資する価値があります。まさに、今回以降のすべての移行からクライアントとの調整をなくしてくれるからです。