Интересная метафора, но в нашем случае она работает иначе. Мы не приковывали Laravel к Битриксу. Скорее, Битрикс выступает фундаментом, на которой стоит инфраструктура контента и процессов, а Laravel это крыша, которая закрывает зоны, где нужна скорость, масштабируемость и современная архитектура.
Важно понимать: Битрикс у нас действительно выполняет роль ядра, но это ядро административного и контентного управления, а не ядро бизнес-логики. Поэтому когда полетело, упал именно слой, обрабатывающий большие объёмы данных, а не административная часть.
Laravel не прикован, он решает те задачи, к которым Битрикс архитектурно не отвечает по скорости и удобству. Мы просто перестали заставлять платформу быть тем, чем она никогда не была. Так что да: птица летает, но не потому что её приковали, а потому что ей наконец перестали мешать.
Спасибо за вопрос! Мы этот "последний шаг" действительно рассматривали, но реальность чуть сложнее, чем кажется со стороны. Битрикс в проекте остаётся не из-за ностальгии, а по практической причине. Мы вынесли наружу то, что ограничивало нас архитектурно, и оставили в ядре то, что решает организационные задачи. Текущий баланс позволяет идти вперёд, не разваливая ежедневную работу бизнеса.
И да, мы прекрасно понимаем все особенности Битрикса. Именно поэтому он теперь отвечает только за то, что делает хорошо, а не за то, что мешает жить.
Так что этот последний шаг - это не технический вопрос, а продуктовый. Когда затраты на перенос админки будут меньше, чем издержки от её сохранения, мы его сделаем. Но пока рациональнее держать Битрикс как административный слой, а не выбрасывать его ради красивого кода
Потому что реальность редко совпадает с идеальным кодом. Битрикс - не выбор разработчика, а данность бизнеса. Наша задача - не спорить с этой данностью, встроиться и помочь бизнесу
В пиковые часы держим около 250–300 rps на API-слой без деградации, при этом P95 остаётся в районе 150 мс. Архитектура спроектирована так, чтобы масштабироваться горизонтально - при необходимости спокойно выходим за 500 RPS без переработки логики. Для нас ключевой метрикой была не столько сырая пропускная способность, сколько предсказуемость отклика при росте нагрузки и синхронизации с битрой
Конечно, “невозможное” - это фигура речи 😊 Технически, да, связать Битрикс с чем угодно можно. Но в нашем случае подружить означало не просто связать API, а сделать так, чтобы Laravel взял на себя бизнес-логику, а Битрикс остался в роли CMS без ломки текущего функционала, очередей заказов и кэшей.
Что до тормозов - согласна, многое зависит от умения "готовить". Мы умеем. Просто иногда есть смысл перестать "готовить лучше" и пересмотреть кухню целиком. Наша цель была не доказать, что Битрикс плох или хорош, а показать, как из него можно выжать максимум, если он становится частью более гибкой архитектуры, смотреть на него не как на кусок кода, а как на бизнес-инструмент.
Допустим, но не стоит забывать, что технологии существуют для бизнеса, а не бизнес для технологий. Подавляющее число сайтов, особенно интернет-магазинов, делаются на PHP, а в реалиях СНГ — на Битрикс. Бизнес с ним знаком, бизнес его знает, бизнес ему доверяет, а плюсом Битрикс — сертифицированное отечественное ПО. А с нашими доработками и Битрикс начинает хорошо ладить с современными технологиями, позволяя гибко работать с микросервисами с API-First-подходом. И прошу, давайте не будем разводить холивар, PHP последние 10–15 лет уже хоронят, а он всё равно живее всех живых, и он востребован на рынке.
Добрый день! Да, конечно же, у нас есть такой опыт.
Тут всё зависит от проекта, но обычно мы идём двумя путями: полностью дублируем логику Битрикс в части правил работы корзины и купонов, либо реализуем логику, которая требуется клиенту и которая нестандартна для обычной Битрикс-логики.
В любом случае, реализовывать эти моменты вполне себе логично, так как мы уходим от монументализма Битрикс.
Что касается службы доставки, то она работает в виде отдельного сервиса с адаптером к разным типам доставок, вроде СДЭКа.
Интересная метафора, но в нашем случае она работает иначе. Мы не приковывали Laravel к Битриксу. Скорее, Битрикс выступает фундаментом, на которой стоит инфраструктура контента и процессов, а Laravel это крыша, которая закрывает зоны, где нужна скорость, масштабируемость и современная архитектура.
Важно понимать: Битрикс у нас действительно выполняет роль ядра, но это ядро административного и контентного управления, а не ядро бизнес-логики. Поэтому когда полетело, упал именно слой, обрабатывающий большие объёмы данных, а не административная часть.
Laravel не прикован, он решает те задачи, к которым Битрикс архитектурно не отвечает по скорости и удобству. Мы просто перестали заставлять платформу быть тем, чем она никогда не была. Так что да: птица летает, но не потому что её приковали, а потому что ей наконец перестали мешать.
Спасибо за вопрос! Мы этот "последний шаг" действительно рассматривали, но реальность чуть сложнее, чем кажется со стороны. Битрикс в проекте остаётся не из-за ностальгии, а по практической причине. Мы вынесли наружу то, что ограничивало нас архитектурно, и оставили в ядре то, что решает организационные задачи. Текущий баланс позволяет идти вперёд, не разваливая ежедневную работу бизнеса.
И да, мы прекрасно понимаем все особенности Битрикса. Именно поэтому он теперь отвечает только за то, что делает хорошо, а не за то, что мешает жить.
Так что этот последний шаг - это не технический вопрос, а продуктовый. Когда затраты на перенос админки будут меньше, чем издержки от её сохранения, мы его сделаем. Но пока рациональнее держать Битрикс как административный слой, а не выбрасывать его ради красивого кода
Потому что реальность редко совпадает с идеальным кодом. Битрикс - не выбор разработчика, а данность бизнеса. Наша задача - не спорить с этой данностью, встроиться и помочь бизнесу
В пиковые часы держим около 250–300 rps на API-слой без деградации, при этом P95 остаётся в районе 150 мс. Архитектура спроектирована так, чтобы масштабироваться горизонтально - при необходимости спокойно выходим за 500 RPS без переработки логики. Для нас ключевой метрикой была не столько сырая пропускная способность, сколько предсказуемость отклика при росте нагрузки и синхронизации с битрой
Конечно, “невозможное” - это фигура речи 😊
Технически, да, связать Битрикс с чем угодно можно. Но в нашем случае подружить означало не просто связать API, а сделать так, чтобы Laravel взял на себя бизнес-логику, а Битрикс остался в роли CMS без ломки текущего функционала, очередей заказов и кэшей.
Что до тормозов - согласна, многое зависит от умения "готовить". Мы умеем. Просто иногда есть смысл перестать "готовить лучше" и пересмотреть кухню целиком. Наша цель была не доказать, что Битрикс плох или хорош, а показать, как из него можно выжать максимум, если он становится частью более гибкой архитектуры, смотреть на него не как на кусок кода, а как на бизнес-инструмент.
Допустим, но не стоит забывать, что технологии существуют для бизнеса, а не бизнес для технологий. Подавляющее число сайтов, особенно интернет-магазинов, делаются на PHP, а в реалиях СНГ — на Битрикс. Бизнес с ним знаком, бизнес его знает, бизнес ему доверяет, а плюсом Битрикс — сертифицированное отечественное ПО. А с нашими доработками и Битрикс начинает хорошо ладить с современными технологиями, позволяя гибко работать с микросервисами с API-First-подходом. И прошу, давайте не будем разводить холивар, PHP последние 10–15 лет уже хоронят, а он всё равно живее всех живых, и он востребован на рынке.
Добрый день! Да, конечно же, у нас есть такой опыт.
Тут всё зависит от проекта, но обычно мы идём двумя путями: полностью дублируем логику Битрикс в части правил работы корзины и купонов, либо реализуем логику, которая требуется клиенту и которая нестандартна для обычной Битрикс-логики.
В любом случае, реализовывать эти моменты вполне себе логично, так как мы уходим от монументализма Битрикс.
Что касается службы доставки, то она работает в виде отдельного сервиса с адаптером к разным типам доставок, вроде СДЭКа.