ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
PositionStackからの移行
PositionStackは、ジオコーディングAPIとしてはこれ以上ないほどシンプルです。access_keyクエリパラメータが1つと、JSONのdata配列があり、各要素にはlatitude、longitude、labelと、深くネストした構造ではなくフラットないくつかの住所フィールドが含まれます。このフラットさこそ、小規模なチームが最初にPositionStackを選んだ理由であることが多く、最初の呼び出しを成功させるまでに学ぶことが少なくて済みます。
意図的にシンプルに作られたAPIからの移行で、複雑さを再び持ち込むべきではありません。これは全面的な書き直しではなく互換性に基づくアプローチを取る場合の、まさに中核となる要件です。始める前に問うべきなのは、新しいプロバイダーの互換ホストが本当にそのフラットさを維持しているのか、それとも複雑さをプロセスの別の場所に移しただけなのかという点です。
My GeocodeのPositionStack互換ホストは、data配列とそのフラットなフィールド構造を、latitude、longitude、labelという名前に至るまで正確に再現しており、PositionStack本来のレスポンスと異なるのは著作権、利用規約、プライバシーに関する文言だけです。リファレンスは/compatibility/positionstack/にあります。このAPI向けに構築された多くの連携では、data[0].latitudeを読み取るコードはホストとキー以外に変更の必要がありません。
切り替え前に確認すべき点の短いリストです。
- コードがPositionStack独自のエラーレスポンスに結び付いた特定のHTTPステータスコードのパターンを確認していないか。エラーの形式は/docs/errors/で別途説明しているので、直接比較する価値があります
access_keyというパラメータ名がどこかにハードコードされていないか。新しいホストはキーをX-API-Keyヘッダー、Authorization: Bearerヘッダー、HTTP Basic認証でも受け付けるため、移行の機会にクエリパラメータから切り替えることもできます- クライアントサイドのコードがキーを直接露出していないか。どのプロバイダーに移るかにかかわらず、この呼び出しをサーバーサイドのプロキシの背後に移す良い機会です
どちらのアプローチも手間の少なさを重視しているため、ここでのコスト比較は本当にシンプルです。My Geocodeでは、キーなしで1日あたり2,500リクエストが無料で、さらにキーごとにネットワーク単位でカウントされる1日あたり2,500リクエストが無料になり、それを超えると1リクエストあたり€0.0001のプリペイドクレジット、または月額€50のUnlimitedキーとなります。この互換ホストを含むすべてのエンドポイントが同じ料金なので、大量処理や高ボリュームのPositionStackのワークロードを移した後に、別途計算し直す必要はありません。
サイド用のアカウントで想定していた規模を超えて成長した小規模プロジェクトにとって、この種の移行はプロジェクトというより、たいてい午後の半日ほどのテストで済みます。ステージングのビルドを新しいホストに向け、住所のサンプルを比較し、形が一致していれば、切り替え自体は設定の変更だけです。