Перенос автоматизации Zapier или Make на новый хост геокодирования
No-code автоматизации с шагом геокодирования требуют иного подхода к миграции, чем собственный код. Вот как провести такой переход.
Тревожные признаки того, что вы привязаны к проприетарному формату
Привязка к поставщику редко возникает в результате одного решения. Она накапливается постепенно, по одному удобному обходному пути за раз, пока кодовая база, начинавшаяся как разумная интеграция с одним провайдером, незаметно не становится почти неотделимой от этого провайдера. Несколько конкретных паттернов стоит научиться распознавать как тревожные признаки, потому что каждый из них по отдельности в момент появления кажется безобидным.
Точные названия полей провайдера используются по всей вашей собственной модели данных. Если схема вашей базы данных, ответы вашего внутреннего API и код фронтенда используют именование полей конкретного провайдера, formatted_address, display_name или как там этот провайдер их называет, вместо ваших собственных названий, один раз преобразованных на границе, значит, каждый слой вашего приложения впитал зависимость от соглашений одного поставщика.
Особенности конкретного провайдера обходятся в бизнес-логике, а не изолированы на границе интеграции. Если обходное решение для особенности того, как один провайдер форматирует пограничный случай адреса, живёт внутри общей бизнес-логики, а не внутри узкой функции, которая общается с этим провайдером, миграция означает поиск и распутывание этого обходного решения в коде, который на первый взгляд никак не связан с геокодированием.
Никто не может быстро ответить, сколько мест в кодовой базе ссылаются на провайдера по имени. Если ответ на вопрос «где мы зависим от этого поставщика» требует тщательного аудита, а не быстрого и уверенного ответа, эта неопределённость сама по себе является признаком привязки, поскольку означает, что зависимость распространилась дальше, чем кто-либо активно отслеживал.
Конкретные типы объектов клиентской библиотеки используются в сигнатурах функций в других частях кода. Если функции, не связанные с геокодированием, принимают тип ответа SDK конкретного провайдера в качестве параметра, система типов этого провайдера фактически стала частью системы типов вашего приложения, и её удаление требует изменения каждой функции, которая на неё ссылается, а не только кода геокодирования.
Миграция ни разу не тестировалась, даже частично, за все годы работы интеграции. Интеграция, которая теоретически может перейти к другому провайдеру, но ни разу не проверялась с ним на практике, по сути мало чем отличается от интеграции, которая вообще не может никуда перейти, пока кто-нибудь действительно это не проверит.
Ни один из этих паттернов сам по себе не катастрофичен, и большинство интеграций долгое время демонстрируют хотя бы один из них без реальных последствий. Смысл в том, чтобы их распознавать, заключается в возможности сделать привязку к поставщику осознанным и приемлемым компромиссом, а не случайным, который никто не выбирал. Иногда удобство стоит этой связанности, особенно в небольшом проекте, где полная миграция обошлась бы в больше инженерного времени, чем стоит гибкость. Проблема возникает, только когда привязка складывается незаметно и обнаруживается в самый неподходящий момент, во время вынужденной миграции со сжатыми сроками, а не признаётся и принимается намеренно заранее.
Если для провайдера, от которого вы сейчас зависите, уже существует совместимый хост, часть этого риска естественным образом ниже: 17 совместимых хостов означают, что как минимум один вероятный путь миграции вообще не требует распутывать привязку на уровне полей, достаточно сменить хост и ключ. Это разумная страховка даже для интеграции, которую вы не планируете переносить в ближайшее время.