Некоторое время назад нами был разработано и опубликовано приложение Финансовый учет для облачного «Битрикс24». В этом материале мы хотим поделиться как мы занимались портированием его на коробку «Битрикса», почему так решили делать и с какими сложностями столкнулись.
Вступление или с чего началось
Как часто это бывает, его мы делали изначально для собственных целей, преследуя желание управлять финансами внутри нашей компании. Понимать куда мы тратим деньги, сколько мы зарабатываем как компания, минимизировать кассовые разрывы за счет планирования трат и все отсюда вытекающие. При этом данный функционал мы хотели получить, не выходя за контур привычной корпоративной среды внутри нашего Битрикс24.
В целом все получилось неплохо. И было принято решение опубликовать его для массового пользования. За все время работы модуля мы занимаемся его непрерывным улучшением. Опираемся уже не только на свои потребности, но и на обратную связь наших постоянных пользователей, с кем мы стараемся поддерживать тесную связь, узнаем, как и что они делают, чтобы выстраивать логические цепочки пользовательского опыта. Ведь мы техническая компания и у нас есть проф деформация, поэтому то, как мы видим свою программу часто не стыкуется с тем, как ее видят пользователи других специальностей – менеджеры, бухгалтера, финансовые руководители и владельцы компаний.
Формирование задачи
В этом году к нам пришел запрос о развертывании Финансового учета на коробочном Битриксе. На первый взгляд, это не проблема, ведь коробка уже умеет поддерживать REST API и маркет. Можно легко поставить любой модуль для облака на коробку. Но был нюанс.
Стремясь к максимально адаптивной архитектуре нашего приложения, возможности быстрого развития, накатывания обновлений и быстрого исправления ошибок, мы воссоздали ее так, что все данные мы хранили в базе клиентских порталов, а вот исполняемые файлы и скрипты работающего механизма были размещены у нас.
На наш взгляд данная структура вполне оправдана. Если пользователи доверяют защитному контуру корпоративной среды Битрикса, пусть там все данные и хранится, зачем нам брать на себя дополнительное хранение этих данных? А что касается исполняемых файлов – это просто работающие скрипты, ценность которых знаем только мы. И сохранением возможности прямого доступа к ним, мы давали пользователям всегда актуальный готовый продукт без мучения с вопросами обновления и совместимости версий.
Чем же наша архитектура не подошла клиенту на коробке? А тем, что не только данные, но и сами программные файлы должны были оставаться внутри, без необходимости внешней связи со сторонними серверами. Логика, конечно, в этом есть, особенно если внедрением занимается партнер, ведь имея под контролем всю программу, ее можно улучшать, дорабатывать и адаптировать точечно под конкретного заказчика.
Сложности портирования на коробку
Ограниченность в ресурсах
Первая сложность для нас — это ограничение ресурсной базы. Мы компания небольшая и есть текущий пул работ по заказчикам, который нельзя игнорировать, ведь это наш хлеб и наша репутация. Поэтому нельзя было просто взять и переписать код приложения. За пару лет работы оно у нас разрослось до некоторых масштабов, мы придумывали и внедряли интересные на наш взгляд технические связки и разные микросервисы. Отказываться от всего этого и переписывать большую часть кода мы не только не хотели, но и не могли себе позволить, если быть откровенными.
Мы хотели, чтобы можно было взять полностью работающий программный пакет и разместить его один-в-один на коробку. Сама идея эта позволяла заниматься улучшение приложения в рамках одной сборки и легко клонировать все обновления на обе платформы (облако и коробка).
После ряда экспериментов это получилось. Немного доработали ядро самого приложения, а большая часть работы ушла на воссоздания некоторого рода адаптивной среды в самом коробочном модуле. При этом сохранилась вся гибкость, ведь мы понимаем что владелец коробки может дорабатывать и улучшать программу под свои тонкие задачи – тем более что возможностей для идеи на коробочной версии Битрикса ограничиваются только техническим опытом разработчика, в отличии от облака, где множество ограничений.
Даже при получении новой версии модуля, создается отдельная ветка сборки, такая мини система контроля версий. Можно управлять какие ветки подключать, создавать свои, менять их и управлять модернизацией.
Сюрпризы от Битрикс24
Время выпуска работающей первой версии для коробки совпало с интересной новостью от 1С-Битрикс, где они сообщили, что теперь «Локальные приложения» и REST API будут платными.
Мы сначала не придали этому значения, наверняка это все для облачной версии. Но какого было наше удивление, когда оказалось, что на коробке REST API тоже будет платным. Почему? Все локально же, никаких нагрузок на сервера компании Битрикс создаваться не должно. Зачем вы так?
Конечно, наше негодование ни на что не влияет. И так получилось, что клиентам при покупке нашего модуля для коробочного портала надо еще иметь активную подписку на Маркетплейс, иначе апишка не будет работать и как следствие приложение тоже.
Основательно решить эту проблему мы не смогли. Пока просто опираемся на предположение, что вероятнее всего у большинства владельцев коробки будет подписка Маркетплейса. А в дополнении сделали триал версию на месяц, чтобы заказчики могли поставить приложение и проверить будет ли оно у них работать, чтобы не было сюрпризов после покупки, что чего-то не хватает.
В перспективе мы думаем доработать сам коробочный модуль до своего обработчика REST API, который бы принимал запросы формата Битрикс24 и адаптировал бы их под бесплатный встроенный API ядра D7.
Тут было бы интересно узнать ваше мнение со стороны, как вы восприняли новость о платном REST API? Будет ли это препятствием для установки нашего приложения или все же все владельцы коробки постепенно все же перейдут на подписку Маркетплейс и это станет некой базой?
Нелегальное копирование
Наверно об этом думает любой разработчик создавай свой программный продукт. Даже самый маленький. Простое желание, чтобы твой труд оплачивался и желание защитить свое авторство.
Если в облачной архитектуре наши скрипты под защитой, ведь доступ к исходникам имеем только мы. То в коробке код открыт и естественное стремление его защитить.
Для начала решили опираться на базовую систему защиты самого Битрикса. Их система установки модулей, выписка купонов и все вытекающие, выглядит хотя бы проверенной временем. И несмотря на то, что она платная даже если ты сам выписываешь купон на свое решение, содержать и придумывать свою такую систему сейчас было бы дороже и дольше.
Вторая опора это партнерское сотрудничество. Продукт становится сложным, много связей, сущностей, логики. И та короткая выгода, которую получаешь при пиратском копировании модуля, теряется при внедрении и настройки. Ведь при наличии лицензии, мы оказываем бесплатную поддержку по внедрению, предоставляем постоянные обновления и улучшения, можем помочь при доработках по схеме white label. Ну и в целом купить наше решение партнеру дешевле, чем делать самим.
По итогу и партнер и мы зарабатываем одинаково, а нелегальное копирование модуля скорее создаст больше проблем, чем реальной выгоды.
Но вопрос защиты до конца не закрыт. Все равно думаем какие есть еще тонкие места, о которых надо беспокоиться. Как думаете достаточно ли того, что уже сделано? Был ли у вас опыт защиты своих модулей на коробочном Битриксе от нелегального копирования?
Итоги
Приложение опубликовано, но учитывая его особенности и стоимостной порог вхождения, а также того, что коробочных Битриксов значительно меньше, чем облачных, обратной связи от пользователей не так много, в отличии от того же облачного решения, которым пользуются уже сотни компаний.
Несмотря на это, для нас кейс успешный. Мы отработали механику адаптирования нашего решения, у нас сформировались свои наработки, которые мы сможем использовать для других наших популярных облачных приложений. Ну и не менее важно, что мы смогли это сделать в рамках ограниченных ресурсов, не отрываясь от текущих задач, но сохранив дух экспериментальности маленькой компании.
