Перенос автоматизации Zapier или Make на новый хост геокодирования
No-code автоматизации с шагом геокодирования требуют иного подхода к миграции, чем собственный код. Вот как провести такой переход.
Как справляться с различиями в схеме ответа при миграции
Даже самый тщательно подобранный провайдер на замену будет отличаться от исходного хотя бы в нескольких мелочах, и найти эти различия до того, как они проявятся в продакшене, совсем не то же самое, что обнаружить их после того, как клиент сообщит об ошибке. Структурированный подход к сравнению схем выявляет большинство таких различий рано, дёшево и без лишнего шума.
Полезно начать с разделения различий на три категории, поскольку каждая требует своей реакции:
Различия в наличии полей. Поле, которое читает ваш код, может присутствовать в ответе одного провайдера и отсутствовать или присутствовать только при определённых условиях в ответе другого. Эту категорию проще всего выявить статическим сравнением: возьмите пример ответа от каждого провайдера для одних и тех же входных данных и напрямую сравните списки полей.
Различия в типе или формате полей. Одно и то же по смыслу значение может быть представлено по-разному: координата как два отдельных числовых поля или как одна общая строка, оценка достоверности как число от 0 до 1 или как категория («high», «medium», «low»), либо метка времени в совершенно другом формате. Чтобы выявить такие различия, нужно читать фактические значения, а не только названия полей.
Смысловые различия при одинаковых названиях полей. Это самая сложная категория, когда два провайдера используют одно и то же название поля, но вкладывают в него немного разный смысл, например поле «accuracy», которое один провайдер рассчитывает по совпадению компонентов адреса, а другой по совершенно другой внутренней методике. Сравнение только по названиям полей этого не выявит; нужно понимать, что на самом деле означает значение в каждой системе, обычно для этого приходится внимательно читать документацию обоих провайдеров, а не предполагать, что общее название подразумевает общий смысл.
Практический процесс: возьмите репрезентативную выборку реальных исторических запросов, в идеале охватывающую как минимум самые частые шаблоны запросов и известные вам сложные пограничные случаи, прогоните их через старого и нового провайдера и сравните результаты систематически, а не на глаз по нескольким примерам. Автоматизация этого сравнения, пусть даже в виде простого скрипта, который помечает любое структурное или существенное различие в значениях, стоит затраченного на настройку времени для любой интеграции, кроме совсем небольшой.
Совместимые хосты My Geocode созданы специально для того, чтобы свести к минимуму первые две категории различий с провайдером, которого воспроизводит каждый из них: наличие и формат полей совпадают в точности, кроме текстов об авторских правах, условиях и конфиденциальности, что описано для каждого хоста на странице /docs/compatibility/. Остаётся третья категория, смысловые различия при общем названии поля, и именно её стоит проверять напрямую даже при использовании совместимого хоста, поскольку совпадение формата никогда полностью не гарантирует совпадения лежащей в основе методики.
Заложить реальное время на эту работу по сравнению до того, как миграция будет считаться завершённой, а не считать достаточным успешный тест нескольких распространённых адресов, это один из самых надёжных способов избежать тонкой проблемы с качеством данных, которую замечают только через несколько недель, а до её настоящей причины докапываются ещё дольше.