Созависимость сервисов по API: как не сделать свое приложение заложником чужой площадки

В нашей студии WebTeamStorm мы неоднократно сталкиваемся с задачами по интеграции тех или иных функциональных возможностей со стороны других сервисов. Эти задачи повсеместны и распространены, а работа с ними ведется на регулярной основе. Сейчас буквально невозможно представить, чтобы даже простой веб-сайт или мобильное приложение не требовали использования всевозможных API, будь то отправка email, push-уведомлений, оповещений в мессенджер или запрос к платежной системе.

Однако во всем этом изобилии распределенных зон ответственности крайне важно не попадать в сильную созависимость между площадками, которая может влиять на работу вашего ресурса. Разумеется, есть исключения — например, если ваш проект представляет собой аналитическую систему для рекламных партнерок, которая работает исключительно с данными из внешних источников. Но и в этом случае, а уж тем более в более автономных проектах, нужно учитывать: если сервисы сильно завязаны друг на друга, это может функционально сломать и ваш продукт.

Опыт из практики

Разрабатывая одно из мобильных приложений для химчистки, мы на этапе согласования получили установку: вся логика и бизнес-процессы осуществляются на стороне внешней CRM-системы АГБИС. Нашей задачей являлось только сделать прокладку из собственного сервера, который бы выполнял небольшие задачи, кэшировал часть данных, а также проходил валидацию для ряда специфических запросов.

Поначалу это более-менее работало. Однако, когда мы вышли в публичную среду, проблемы посыпались одна за другой.

Например, АГБИС изменили способ авторизации и добавили капчу. В результате недавно прошедшее модерацию приложение буквально лежало мертвым грузом вместе с пользователями, ведь они не могли авторизоваться. Пришлось в срочном порядке готовить фикс.

Далее изменилось условие оплаты — вернее, способ передачи данных о том, что заказ оформлен. Этот метод был встроен в сложную цепочку из порядка десяти последовательных действий, которая позволяла покупателю закрыть свой запрос по корзине. В итоге мы снова возвращаемся к ситуации, когда приложение лежит мертвым грузом.

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

Однако есть все же ряд советов, чтобы вы или ваши посредники не натыкались на подобные казусы.

Оценка для бизнеса перед реализацией

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

Для бизнеса здесь важно заранее понимать границы ответственности: какие данные и функции находятся под вашим контролем, а какие зависят от партнера. Стоит также выяснить, как сервис сообщает об изменениях API, насколько предсказуемо проходят обновления, есть ли резервные сценарии и что произойдет, если интеграция временно станет недоступна. Чем критичнее внешняя система для вашего продукта, тем больше внимания стоит уделить тому, чтобы ее сбой не превращался в остановку всего проекта.

Как снизить зависимость сервисов

1. Если делегируете функции — делегируйте их более децентрализованно.
   Возвращаясь к примеру выше, мы используем API-сервис для авторизации, хотя в целом можно сделать полностью автономную учетную запись на нашей стороне.
   При входе отправляется SMS-запрос. В таком случае лучше использовать более надежного проверенного сервис-партнера, чтобы он выполнял эту задачу.
   То есть правило простое: знаете, как сделать через другой сервис надежно — используйте его, если у вас действительно есть такая возможность. К сожалению, архитектура некоторых систем этого не позволяет.
    
2. Ваш проект — это база данных и главная площадка.
   Пусть все важные данные хранятся именно у вас. Лучше подтягивать необходимые записи из внешних CRM по факту или с определенным интервалом.
   Проверяйте стрессоустойчивость такого подхода — намеренно отключайте интеграцию, чтобы убедиться, что уже существующие данные будут доступны пользователям и клиентам без проблем.
    
3. Отложенная очередь запросов.
   Если вам нужно отправлять и согласовывать целостность данных — например, сообщить о новом заказе на вашей площадке либо об изменениях в нем — формируйте отдельное мини-приложение, которое отвечает за синхронизацию.
   Пусть отдельная программа отправляет данные и проверяет их корректность, позволяя вашему сервису оставаться атомарным.
    
4. Сохраняйте информацию об обмене данными.
   В случае если что-то пойдет не так, вы должны узнать об этом первыми. Настройте оповещения на случай сбоя между сервисами. Должны быть настроены отдельные системы логирования, которые позволяли бы быстро и точно разобраться, на каком шаге и в каком запросе произошел сбой.
    
5. Если есть альтернатива — предоставьте ее.
   Это редкий случай, но все же встречающийся на практике. Например, с платежными системами. Отслеживайте работоспособность интеграции: если она отвалилась, имеет смысл сразу предложить клиентам альтернативный способ оплаты.
   Такую же схему можно проворачивать и с иными возможностями — email, push, SMS и т. д.

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