ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
モバイルアプリのジオコーディング呼び出しを移行する
モバイルアプリから直接行うジオコーディング呼び出しの移行には、純粋なサーバー側の移行では扱う必要のない制約がいくつか加わります。それらは計画の形を変えるため、始める前にはっきりと挙げておく価値があります。
1つ目はリリースの周期です。サーバー側の変更はデプロイした瞬間に反映されます。モバイルアプリの変更はアプリストアの審査を通過する必要があり、その後の普及はユーザーが実際にアップデートするかどうかにかかっています。多くのアプリでは、インストールベースの過半数に届くまでに数週間かかり、全員に届くまでにはさらにかなり長くかかることがあります。モバイルアプリの移行計画では、2つのプロバイダー、または2つのバージョンのアプリを、サーバーの移行で通常必要な期間よりも長く並行して運用することを考慮に入れる必要があります。
2つ目は認証情報の露出です。モバイルアプリのバイナリに直接埋め込まれたAPIキーは、調べようとする動機のある人なら誰でも抽出できます。これはどのプロバイダーを使っているかに関係なく、セキュリティ上の考慮事項です。現在の連携がキーを埋め込んだクライアントからジオコーディングAPIを直接呼び出しているなら、移行はそのパターンを見直し、呼び出しを自社のバックエンドの裏に移す妥当なタイミングです。多少のレイテンシとバックエンドの作業が増えるとしてもです。
ほとんどのモバイル移行に当てはまる実践的な手順をいくつか紹介します。
- 呼び出しをサーバー側に移す場合は、まず新しいバックエンドのエンドポイントを設計し、その裏にどのプロバイダーを置くかを気にする前に、モバイルアプリが自社のAPIとやり取りするようにします。これにより、アプリ側の変更とプロバイダー側の変更を完全に切り離せます
- 呼び出しをクライアント側に残す場合は、APIのホストとキーをハードコードするのではなく、ビルド時の設定値を使います。そうすれば、将来の移行でコードベース全体からリテラル文字列を探して置き換える作業を繰り返さずに済みます
- 移行期間中に両方のプロバイダーをサポートする予定なら、最新のビルドだけでなく、まだ使われている実際の古いアプリバージョンでもテストします。古いアプリバージョンが間もなく廃止される古いホストを呼び出すのは現実的なシナリオであり、それをいつまでサポートし続けるかについて明示的に判断する必要があるからです
My Geocodeの認証方法(X-API-Key ヘッダー、Authorization: Bearer ヘッダー、HTTPベーシック認証、クエリパラメータ)は、リクエストがモバイルクライアントから直接送られる場合も、自社のバックエンドが呼び出しを中継する場合も同じように機能します。そのため、この判断(クライアント側かサーバー側か)によって、使える認証方式が制限されることはどちらの場合もありません。割り当ての使用状況は、X-Quota-Used や X-Quota-Reset などのヘッダーを通じてすべてのレスポンスで確認でき、/docs/rate-limits/に記載されています。リクエストの送信元でこれらのヘッダーにアクセスできるなら、モバイル移行の展開状況を監視するのに役立ちます。
モバイルの移行では、サーバー側の移行以上に忍耐が報われます。主な理由は、リリースと普及のサイクルが、早く作業しても短縮できないスケジュールを課すからです。最初から長めの移行期間を計画しておけば、構造的にそれほど速く進めないプロセスにサーバー側の移行のペースを期待してしまうというもどかしさを避けられます。