Ограничения

Перед стартом проекта зафиксировали следующие ограничения:

• один единственный endpoint, который отдаёт всю информацию обо всех нужных данных для рендеринга страницы
• скорость ответа от бекенда - не более 100 миллисекунд при текущих нагрузках проекта на одной ноде
• изолированное окружение для запуска приложения в docker контейнерах
• возможность последующего встраивания в инфраструктуру заказчика
• использование Битрикс Управление Сайтом для управления контентом

Процесс работы

Создали рабочую группу и распределили обязанности.

В первую очередь договорились о контрактах API. Разработали схему данных для будущего API, согласовали её с командой frontend разработки, которая делала лендинг. В связи с тем, что это неполноценное REST API, решили не использовать OpenAPI для описания схемы и обмена знаниями, т.к. это могло бы растянуть сроки согласования. Вместо этого использовали обычный Google Docs для фиксации контракта.

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

После фиксации контракта мы распараллелили работы между инфраструктурой и разработкой.
У нас уже были наработки по docker окружению для проектов на 1С-Битрикс. Не самая тривиальная задача, но мы уже подходили к этому снаряду и знали, чего ожидать.
Мы подключили к решению задачи одного middle разработчика, который успешно применил эти наработки на данном проекте .

Пока разрабатывалась инфраструктура, другой middle разработчик воплощал в жизнь согласованные контракты в API. Ему была не нужна инфраструктура для старта работ, т.к. у нас есть несколько других вариантов запуска приложения. Данный проект хостился на нашем физическом сервере разработки - трудяге, который верно служит нам уже много лет.
К задаче реализации API подключили middle разработчика, который воплотил в жизнь хранилище данных для API, описав его автоматическое воссоздание с помощью миграций СУБД.
В связи с тем, что у нас всего один endpoint, который должен работать относительно быстро и обязан отдавать большой массив данных, важным становятся принципы кеширования и грамотной инвалидации этого кеша. На проекте успешно применили те подходы, которые предлагает Bitrix Framework. Для наших целей хватило файлового кеша на одной ноде с инвалидацией по тегу. Но у заказчика остаётся возможность переключиться на распределённый вариант с использованием Redis или Memcached.
При разработке этого приложения мы не использовали компоненты 1С-Битрикс, т.к. при данной реализации в них нет никакой нужды. Вместо этого обычный надёжный ООП код с MVC подходом на основе тех возможностей, которые даёт 1С-Битрикс.

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