My Geocode

Миграция

Миграция вызовов геокодирования в мобильном приложении

· 3 мин чтения · My Geocode · #mobile#geocoding#migration#ios#android

Миграция вызовов геокодирования, которые выполняются прямо из мобильного приложения, добавляет несколько ограничений, с которыми чисто серверная миграция не сталкивается, и их стоит чётко назвать до начала работы, поскольку они меняют структуру плана.

Первое ограничение касается ритма релизов. Изменение на сервере может заработать в момент развёртывания. Изменение в мобильном приложении должно пройти проверку в магазине приложений, а затем его распространение зависит от того, обновят ли пользователи приложение. У многих приложений охват большинства установленной базы занимает недели, а охват всех может занять значительно больше времени. Любой план миграции мобильного приложения должен учитывать, что двух поставщиков или две версии приложения придётся поддерживать параллельно дольше, чем обычно требует серверная миграция.

Второе ограничение касается раскрытия учётных данных. API-ключ, встроенный прямо в бинарный файл мобильного приложения, может извлечь любой, у кого есть желание поискать, и это вопрос безопасности независимо от поставщика. Если ваша текущая интеграция вызывает API геокодирования прямо с клиента со встроенным ключом, миграция станет подходящим моментом, чтобы пересмотреть эту схему и перенести вызов за собственный бэкенд, пусть это и добавит немного задержки и немного работы на бэкенде.

Несколько практических шагов, применимых к большинству мобильных миграций:

  • Если вы переносите вызов на сервер, сначала спроектируйте новый эндпоинт бэкенда и переведите мобильное приложение на работу с вашим собственным API, а уже потом думайте о том, какой поставщик стоит за ним, полностью отделив изменения в приложении от смены поставщика
  • Если вызов остаётся на клиенте, задавайте хост API и ключ через конфигурационное значение на этапе сборки, а не жёстко в коде, чтобы будущая миграция снова не требовала искать и заменять строковый литерал по всей кодовой базе
  • Если вы планируете поддерживать обоих поставщиков в переходный период, тестируйте на реальных старых версиях приложения, которые ещё используются, а не только на последней сборке, поскольку старая версия приложения, вызывающая старый хост, который скоро будет выведен из эксплуатации, представляет собой реалистичный сценарий, требующий явного решения о том, как долго его поддерживать

Варианты аутентификации My Geocode (заголовок X-API-Key, заголовок Authorization: Bearer, HTTP Basic auth или параметр запроса) работают одинаково, отправлен ли запрос прямо с мобильного клиента или через ваш собственный бэкенд, проксирующий вызов, поэтому это конкретное решение (клиент или сервер) никак не ограничивает доступный способ аутентификации. Расход квоты виден в каждом ответе через заголовки вроде X-Quota-Used и X-Quota-Reset, описанные на странице /docs/rate-limits/. Это полезно для отслеживания хода мобильной миграции, если у вас есть доступ к этим заголовкам там, откуда отправляются запросы.

Мобильные миграции вознаграждают терпение сильнее, чем серверные, в основном потому, что цикл релизов и обновлений задаёт сроки, которые нельзя сократить, работая быстрее. Если с самого начала заложить более длинное переходное окно, вы избежите разочарования от ожидания темпа серверной миграции от процесса, который по своей структуре не может идти так быстро.

Ещё в разделе «Миграция»