Когда ко мне приходит клиент с идеей новой системы, в первые полчаса разговора почти всегда звучит фраза «а ещё нам нужно, чтобы...». Нужно принимать оплату картой. Нужно отправлять посылки и видеть, где они едут. Нужно звонить клиентам прямо из карточки. Нужно, чтобы бухгалтерия получала документы без ручного переноса. Нужно, чтобы нейросеть разбирала входящие письма. И где-то в этот момент у клиента в глазах появляется лёгкий ужас: неужели всё это придётся программировать? Не придётся. Почти всё это уже кто-то сделал, отладил и сдаёт в аренду. Мост между Вашей системой и чужими возможностями называется API.
Ваше приложение не должно быть островом
Я люблю сравнивать программную систему с городом. Можно построить город, который всё производит сам: свой хлеб, своё электричество, свою воду, свои кирпичи и даже свою валюту. Исторически такие города существовали, их называли крепостями, и жилось в них, мягко говоря, тесно. Современный город устроен иначе: он подключён к энергосети, к водопроводу, к железной дороге, к банковской системе. Он не производит электричество в каждом подвале, он покупает его по проводам и занимается тем, что у него получается лучше всего.
С системами то же самое. Писать собственный платёжный шлюз, собственную картографию или собственную телефонию для небольшой компании так же разумно, как строить в подвале офиса электростанцию. Можно, конечно. Будет очень гордо, очень дорого и очень ненадёжно. Банк, логистический оператор или облачная телефония занимаются своим делом годами, у них тысячи клиентов, которые уже наступили на все грабли. Подключаясь к ним через API, Вы получаете этот опыт по подписке, а свою энергию тратите на то, что отличает именно Вашу компанию.
Что дают интеграции на практике
Самый очевидный эффект это экономия на разработке. Функциональность, которую пришлось бы строить месяцами, подключается за дни. Но для меня важнее другой эффект, менее заметный: исчезает ручной перенос данных между системами. В любой компании, которую я видел изнутри, есть люди, чья работа частично состоит в том, чтобы смотреть в один экран и печатать в другой. Номер накладной из сайта перевозчика в учётную систему. Сумму платежа из банковской выписки в заказ. Статус из одной таблицы в другую. Это самая скучная, самая ошибочная и самая незаметная работа в бизнесе, и именно её API убирает полностью.
Типичный набор внешних ресурсов, с которыми мы работаем почти в каждом проекте:
- платёжные системы и банки: приём оплат, сверка поступлений, выставление счетов;
- службы доставки: создание отправлений, печать накладных, отслеживание статусов;
- телефония и мессенджеры: звонки из карточки клиента, запись разговоров, уведомления;
- карты и геоданные: адреса, расстояния, маршруты, зоны доставки;
- нейросети: разбор документов, классификация обращений, черновики ответов, поиск по базе знаний;
- маркетплейсы, рекламные кабинеты, бухгалтерские сервисы и всё, что живёт снаружи, но влияет на Ваши деньги.
Обратная сторона: Вы живёте в чужом доме
Было бы нечестно рассказывать только про хорошее. Интеграция это зависимость, и к ней нужно относиться как к любой зависимости: трезво. Внешний сервис может поменять формат ответа, поднять цены, ввести лимиты, на несколько часов лечь или вообще закрыться. Я видел систему, которая работала идеально три года, а потом сервис, от которого она зависела, тихо выключил старую версию API, и в понедельник утром у компании перестали создаваться заказы. Никто не виноват, это просто погода в интернете.
API это не розетка, в которую воткнул и забыл. Это договор с соседом, и соседи иногда переезжают.
Поэтому интеграции мы проектируем по нескольким простым правилам. Внешний сервис никогда не должен быть единственным местом, где хранятся Ваши данные: всё, что важно, сохраняется у Вас. Каждая интеграция обёрнута в отдельный модуль-адаптер, чтобы при смене поставщика переписывать одну прослойку, а не половину системы. Ошибки внешних вызовов логируются и повторяются по правилам, а не теряются молча. И для критичных функций, таких как оплата, по возможности есть запасной вариант или хотя бы понятная ручная процедура на время сбоя.
Как понять, что пора интегрироваться
У меня есть простой тест. Посмотрите на рабочий день Ваших сотрудников и найдите момент, когда человек копирует данные из одного окна в другое. Если такой момент повторяется чаще десяти раз в день, это кандидат на интеграцию. Если от этого копирования зависят деньги, например сумма счёта или адрес доставки, то это не кандидат, а срочная задача: ошибка при ручном переносе рано или поздно обойдётся дороже, чем вся интеграция.
Второй тест: спросите себя, не пишете ли Вы с нуля то, что уже продаётся. Свой чат-бот, своя система рассылок, своё распознавание документов. Иногда это оправдано, если это ядро Вашего продукта и Ваше конкурентное преимущество. Но чаще это проявление инженерного тщеславия, которое я и сам в себе периодически ловлю за руку.
Что делать завтра
Составьте список всех внешних сервисов, которыми уже пользуется Ваша компания, даже если работа с ними идёт вручную. Рядом напишите, какие данные ходят туда и обратно и кто их переносит. Получится карта, по которой сразу видно, где люди работают живыми кабелями между системами. Начните с самого частого и самого денежного переноса.
В Systems мы делаем такие интеграции постоянно, и для нас это скорее сантехника, чем магия: важно правильно проложить трубы и поставить краны там, где их потом удобно перекрыть. А Fractal позволяет описать модели данных так, чтобы внешние сервисы подключались к уже понятной структуре, а не прорастали в систему хаотичными заплатками. Подключайте мир к своей системе, но держите ключи от своего дома у себя.
