Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Почему миграция должна занимать полдня, а не квартал
Проект миграции, который оценивают в квартал инженерного времени на смену поставщика данных о местоположении, обычно не является кварталом действительно необходимой работы. Это квартал работы, созданной проектными решениями, принятыми годами ранее: проприетарный формат ответа, который приходится распутывать поле за полем, SDK, вызовы методов которого разбросаны по кодовой базе в никем не задокументированных местах, обработка ошибок, построенная вокруг специфических кодов статуса одного провайдера. Ни одна из этих сложностей не присуща самой идее поиска адреса или IP. Всё это унаследовано от решений, которые сделали исходную интеграцию удобной ценой того, что будущая миграция стала дорогой.
Мы создали 17 совместимых хостов именно для того, чтобы этот квартал стал ненужным для всех, чья существующая интеграция уже работает с одним из форматов этих провайдеров. Если ваш код вызывает эндпоинт известного API геокодирования или IP и разбирает его специфический формат ответа, чтобы направить этот же код на наш соответствующий совместимый хост, должно быть достаточно заменить базовый URL и API-ключ, а не переписывать логику разбора, которая годами исправно работала. Аутентификация принимает ключ в заголовке, в виде bearer-токена, через HTTP Basic auth или в параметре запроса, поэтому любой способ, который уже использует ваш код, скорее всего, уже поддерживается.
Миграция за полдня не то заявление, которое мы делаем легкомысленно, потому что точно знаем, сколько усилий с нашей стороны потребовалось, чтобы это стало правдой: повторить формат ответа другого провайдера поле за полем, проверить его на реальных запросах и сохранять этот формат стабильным, чтобы у существующего кода клиента не было причин заметить какую-либо разницу, кроме того, куда уходит запрос. Эта работа перенесена на нас заранее именно для того, чтобы её не приходилось повторять ниже по цепочке, в кодовой базе каждого клиента, который хочет проверить, стоит ли переходить.
Более широкая мысль выходит за рамки наших совместимых хостов: миграция длиной в квартал это диагностическая информация о предыдущей интеграции, а не естественное свойство смены провайдера вообще. Если уход от провайдера требует многомесячного проекта, кто-то где-то выиграл от существования этого трения, независимо от того, создавалось ли оно намеренно. Провайдеру, действительно уверенному в своих данных, ценах и надёжности, незачем усложнять уход, ведь вся его позиция должна состоять в том, что клиент, который попробует продукт, не захочет уходить, а не в том, что уйти слишком дорого, чтобы даже пытаться.
Мы предпочитаем соревноваться в том, стоит ли продукт того, чтобы с ним остаться, при честной оценке, в тот же день, когда клиент мог бы так же легко уйти. Чтобы такой день стал возможен, нам пришлось вложить реальные инженерные усилия. Мы считаем, что эти усилия нужно было потратить, и что любой провайдер, не желающий их тратить, втихую сообщает вам кое-что о том, насколько он на самом деле уверен в том, что продаёт.