将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
迁移移动应用的地理编码调用
迁移直接从移动应用发出的地理编码调用，会带来一些纯服务器端迁移不必面对的限制，值得在开始之前把它们明确说出来，因为它们会改变整个计划的形态。
第一个限制是发布节奏。服务器端的更改在部署的那一刻即可生效。移动应用的更改则必须经过应用商店审核，之后的普及程度取决于用户是否真的更新，对许多应用来说，覆盖大多数已安装用户需要数周时间，覆盖所有人则可能需要更长时间。任何移动应用的迁移计划，都需要考虑同时运行两个提供商或两个版本的应用，而且持续时间比服务器迁移通常所需的更长。
第二个限制是凭据暴露。直接嵌入移动应用二进制文件中的 API 密钥，任何有心查看的人都可以提取出来，无论涉及哪个提供商，这都是一个安全考虑因素。如果您当前的集成是在客户端使用嵌入的密钥直接调用地理编码 API，那么迁移正是重新考虑这种模式、改为把调用放到您自己的后端之后的合适时机，尽管这会增加一点延迟和一些后端工作。
适用于大多数移动端迁移的几个实用步骤：
- 如果要将调用移到服务器端，请先设计新的后端端点，让移动应用与您自己的 API 通信，然后再考虑背后使用哪个提供商，从而将应用端的更改与提供商端的更改完全解耦
- 如果保留客户端调用，请为 API 主机和密钥使用构建时配置值，而不是将其硬编码，这样将来的迁移就不必再在整个代码库中查找并替换字面字符串
- 如果您计划在过渡期间同时支持两个提供商，请在仍在使用中的旧版应用上进行实际测试，而不只是测试最新构建，因为旧版应用调用即将停用的旧主机是一个现实的场景，需要明确决定要继续支持它多久
My Geocode 的认证方式，即 X-API-Key 请求头、Authorization: Bearer 请求头、HTTP Basic 认证或查询参数，无论请求是直接来自移动客户端，还是由您自己的后端代理调用，都以相同的方式工作，因此这一特定决定（客户端还是服务器端）无论如何都不会限制可用的认证方式。每个响应都通过 X-Quota-Used 和 X-Quota-Reset 等响应头显示配额用量，相关文档见 /docs/rate-limits/，如果您能从请求发出的地方读取这些响应头，这对于监控移动端迁移的推出进度很有用。
移动端迁移比服务器端迁移更需要耐心，主要是因为发布和普及周期带来了一个无法通过加快工作来压缩的时间表。从一开始就规划更长的过渡窗口，可以避免对一个在结构上不可能那么快推进的过程抱有服务器端迁移那样的速度期望，从而免去由此带来的挫败感。