Несколько лет назад я обсуждал с клиентом новый проект. Суть такова: есть компании-производители, которые хотят промоутить свои товары через кешбек или какие-то бонусы за покупки. Делается сайт (не нами), сайт рекламируется, человек туда заходит, загружает фото чека, qr-кода или другой документ подтверждающий покупку, потом фото идет к нам, наша система его валидирует и сообщает результат назад. Вопрос заключался в том, каким образом обеспечить сайтоделам максимальную простоту интеграции нашей системы.
Я предложил, чтобы мы поставляли API (он у нас был), а партнёры пусть нам грузят фотки самостоятельно, используя API. Дока есть, мануал есть, бери и пользуйся. Все безопасно и надежно.
Клиент предложил подумать еще, как можно упростить процесс, например сделать виджет который партнёры могли бы встроить себе на сайт и чтобы работало само.
Я воспротивился, потому что не видел хорошего технического решения этой задачи, но клиент настоял на том, чтобы мы сделали виджет, который бы встраивался в сайт просто добавлением одной строки js/css. Как какой-нибудь intercom или всевозможные его аналоги. Но как бы сайт партнёра узнавал о том, что пользователь загрузил нам данные? Ведь виджет должен быть универсальным, работать везде, а вызовы мы можем делать только на наше API. Если все делать на клиенте, то можно подделывать данные, короче я призадумался. Решение этой проблемы мы нашли, в том числе как сделать это ± безопасно, я посадил фронтендеров за jQuery (потому что виджет должен работать везде) и спустя пару месяцев мы выкатили рабочий код.
Сейчас я понимаю, что это было важнейшее решение по тому продукту, а я поступил очень недальновидно и по-джуниорски, сопротивляясь предложениям клиента и заняв техноцентричную позицию. То, что мне казалось техническим костылём, на практике оказалось успешным, удобным и безопасным решением. Наш виджет добавлялся буквально двумя строками JS, это могли осилить любые разработчики, подробная дока объясняла как его инициализировать и кастомизировать, и в принципе до меня дело доходило редко. Большинство веб-студий справлялись со всем сами. В том году я его переписал (нужно было добавить новую функциональность), работает на куче сайтов до сих пор и еще будет работать.
Простота и бесшовность интеграции невероятно важна. Никто не будет качать какие-то библиотеки, делать настройки или добавлять зависимости себе в проект. Все хотят чтобы пара строчек и все работало. И не ломалось.
Среди равных двух выигрывает тот продукт, у которого больше интеграций с уже существующими решениями. Жизнь слишком коротка, чтобы пилить кастомную интеграцию. Пользователь хочет нажать кнопку и получить ценность уже. Запрограммировать-то все могут, а нам пожалуйста предоставьте no-code.
Примерно в то же время в другом стартапе обсуждали похожую штуку—виджет, который бы встраивался на сайт и добавлял к нему некую функциональность типа легковесной CRM. Мы уже год как делали мегасложный продукт, и вдруг оказалось что этот смехотворный виджет, состоящий из двух полей и одной кнопочки, является едва ли не основой бизнеса.
Никому не нужно ваше кастомное поделие, куда надо интегрироваться и переносить данные, никому не интересна еще одна система. Сделайте пожалуйста, чтобы я мог добавить вашу кнопку себе на сайт или в приложение, и желательно чтобы мне не нужно было ничего настраивать.
Никому не нужен еще один формат конфигурации. Я раздумываю про свой PaaS и понимаю, что если я не сделаю бесшовную интеграцию с docker-compose, куберовскими манифестами, helm-чартами, то никто ко мне не пойдет. Никто не будет изучать еще один ямль в довесок к той тройке что он уже знает. Никто не будет мигрировать свою инфраструктуру, если это будет стоить больше чем 10 минут времени. Людям нужно дать возможность использовать существующие решения и языки, чтобы они могли попробовать и оценить ваш продукт за 5 секунд, просто залив туда свои существующие конфиги. Как бы мне не нравились костыли, компиляторы из одного в другое и адаптеры, это нужно делать.
Другой пример это экосистема JVM. Почему она так хороша? Потому что за 20 лет написано библиотек и решений под любую задачу. Поэтому новым языкам на JVM не нужно ничего делать заново. Выучил синтаксис, базовые концепции и вперед—бери и пользуйся тем, что уже сделано. Scala, Kotlin, Clojure, другие языки получают большое преимущество—им не нужно переизобретать велосипед. JS туда же…
Напоследок расскажу про махровые времена. Когда я работал в энтерпрайзе, то существенной частью любого проекта была т.н. команда интеграции и миграции. Эти ребята брали существующие системы, установленные у заказчика (телеком оператора) и писали конвертеры чужих XML в наши, чужих таблиц в наши, да еще и в обе стороны. Естественно, со временем накопилась некая база типовых интеграций, потом был разработан визуальный конструктор позволяющий накликивать маппинги между XMLями и таблицами, потом джобы синхронизации и реконсиляции, короче полный набор. У заказчика уже стоит вагон систем, а тут приходим мы и говорим "щас мы тебе покажем все в нашей системе". Туда сюда подключаем эти самые интеграции—и—оп—все его продукты, клиенты, заявки и тд видны уже у нас. Я всегда надменно смотрел на этих ребят потому что то была обезьянья работа—сиди да и клепай маппинги которые тебе бизнес-аналитик сказал делать. Но на самом деле они занимались едва ли не важнейшей частью проектов. Потому что новая система без актуальных данных никому не нужна.
Интеграции имеют колоссальное значение. Особенно, когда на рынке миллион разных продуктов которыми люди уже пользуются и в которых люди уже накопили данные.
Это очень неблагодарная работа. Я ненавижу поддержку других форматов, конвертацию туда-сюда, особенно если данные напрямую не маппятся. Но это нужно делать, иначе—никак.
Сподобалось? Долучайтеся до мого телеграм каналу: https://t.me/full_of_hatred