ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
Google Placesのオートコンプリート連携から移行する
オートコンプリートは、単発のジオコーディングの呼び出しとは種類の異なる連携です。ユーザーが住所欄で入力するほぼすべてのキー入力ごとに発生し、プロバイダーによってはセッション単位の料金やグループ化に依存し、レスポンスは入力している人に遅延が目に見えてわからないほど速く返ってくる必要があります。ユーザーがリアルタイムで直接操作するからこそ、この部分の移行はバッチのジオコーディングジョブよりもUXのリスクが大きくなります。
Google Places Autocompleteは予測候補のリストを返し、各候補にはdescriptionの文字列とplace_idが含まれます。place_idは、完全な住所と座標の情報を取得するための後続の詳細取得の呼び出しで使われます。予測候補が先で詳細が後というこの2段階のパターンは特有のやり取りのモデルで、デバウンスのタイミングや、詳細取得の呼び出しが完了する前に選択された結果をどう表示するかなど、それを前提に作られたフロントエンドのコードの多くを形作っています。
これは機能について正直に説明することが重要になるケースです。My Geocodeは検索エンドポイントの一部として住所オートコンプリートを提供しており、リクエストとレスポンスの形は/docs/address-autocomplete/で説明しているとおりです。ただし、セッションのグループ化や結果の順位付けを含め、オートコンプリートのエンドポイントの具体的な挙動は、Googleの2段階モデルと1対1で一致すると想定するのではなく、自社の住所データとユーザーの利用パターンで直接テストする価値があります。候補から詳細へのフローの構成はプロバイダーによって異なり、その構造の違いが、個々のフィールド名よりも、ここでの実際の移行作業の最大の部分になるのが普通です。
この移行のための実践的な手順です。
- 現在の実装で予測候補の後に詳細を取得する2段階のパターンが必要なのか、それとも1回の呼び出しで済む候補エンドポイントのほうがフロントエンドのコードを実際に簡素にできるのかを整理します
- Googleのインフラに合わせて調整した値を使い回すのではなく、自社のネットワーク環境における新しいエンドポイントの実際の応答時間に対して、デバウンスと最小文字数の設定をテストします
- 予測候補のリストが空で返ってきた場合や結果が1件だけの場合に、UIがどう対応するかを確認します。順位付けの挙動はプロバイダー間で大きく異なるため、フォールバックのUXが複数の候補を受け取ることに依存すべきではありません
新しいエンドポイントの認証は、キーをX-API-Keyヘッダー、Authorization: Bearer、HTTP Basic認証、クエリパラメータのいずれかで送る形で動作します。キーなしで1日あたり2,500リクエストが無料、さらにキーごとにネットワーク単位でカウントされる1日あたり2,500リクエストが無料で、それを超えると料金は1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキーとなり、他のすべてのエンドポイントと同じ料金です。
ほとんどのキー入力がリクエストを発生させるため、オートコンプリートの呼び出しは実際のジオコーディングの呼び出しに比べて量が多くなりがちです。本番トラフィックの最初の週に驚くことがないよう、リリース日を確定する前に、想定される1日の量を無料枠とリクエストあたりの料金に照らして見積もっておく価値があります。