Кейс: два сайта - одна корзина. Многосайтовость на Битриксе в 2014м году.

Скажу сразу: по меркам 2014 года я бы назвал этот проект немного опередившим свое время, относительно сложным и достаточно прогрессивным. Но были в нем и определенные недостатки. Подробности рассказываю в этой статье.

Приятного чтения!

Ресторан New York, стиль: "Американский дайнер". Делали дорогущие, но топовые бургеры до того, как это стало мейнстримом.

Ресторан СушиМин, японская кухня классическая, но уровня именно ресторана.

Ресторанов по городу несколько, компания одна, служба доставки единая. В некоторых локациях присутствовали оба ресторана сразу, каждый в отдельном зале. Именно это и послужило причиной, по которой появились желающие заказать доставку одновременно из обоих ресторанов.

Особенно это касалось компаний друзей. Ну или влюбленная пара под вечерний просмотр фильма решает заказать вкусноты. Брутальный бородатый ойтишнег желает насладиться порцией филадельфии с авокадо 🍣, а его хрупкая спутница голодна настолько, что готова схомячить огромный мясной бургер 🍔 и закусить картошкой фри 🍟.

Кстати, на тот момент еще не было никаких деливери и прочих клабов, в народе именуемых агрегаторами доставок.

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

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

В итоге на любом сайте можно оформить один заказ из трех разных меню (в процессе добавился еще и китайский ресторан).

Сайты - модные в то время одностраничники. Верстка должна быть обязательно адаптивной, и на относительно слабеньких смартфонах тех лет (iPhone 5 был в ходу, а шестерка еще не вышла) сайт должен был выглядеть аки современное мобильное приложение.

Тут было два ключевых момента: верстка и меню.

Блоков много, все должно двигаться при изменении размеров окна браузера, и с параллакс-эффектом при скроллинге. Казалось бы, делай классический адаптив с относительными размерами и положением блоков (это когда все в %, а не конкретными цифрами).

Однако, заботливый дизайнер не преминул прислать варианты макетов чуть ли не под каждое разрешение экрана, что было конечно неплохо, но накладывало большие ограничения на применение технологий классической ныне адаптивной верстки, которая на тот момент существовала всего пару лет (до этого популярностью пользовались облегченные мобильные версии сайтов).

Прислал и потребовал pixel-perfect верстку под каждый свой макет. За что попал в мою личную немилость, но это никого не волновало и к делу не относится.

В итоге вместо краткого заточенного под адаптив css-файла мы получили чуть ли не мегабайтную (это много для такого проекта) простыню с раздутыми до неприличия @media, в которых до пикселя прописывалось положение каждого элемента.

Здесь выручил мой любимый 1С-Битрикс и его многосайтовость. В 2014м единицы разрабов понимали, что это за технология и как с ней работать, но я нашел под проект подходящего человека, который приехал ко мне в офис, достал из рюкзака бубен и лик сатаны и начал ваять. К концу проекта он постарел лет на 10 и заметно поседел.

Но результат был достигнут: единая админка и ajax-корзина для двух разных сайтов, находящихся на разных доменах. Внутри это выглядело как отдельные инфоблоки для каждого сайта.

Битриксовый и без того перегруженный компонент корзины с заметными зависаниями обрабатывал элементы из трёх разных инфоблоков, применяя к ним правила работы с корзиной, попутно выдавая в консоль ошибки. Ругался, но отрабатывал.

Заказы формировались и падали на почту логистам компании, которые уже дальше думали, как собрать заказ из двух ресторанов, находящихся в двух разных районах города и доставить в третий. Но это уже их кейс, а не мой.

В современных реалиях никто не стал бы делать два разных сайта для одной службы доставки. Потому что это усложняет бизнес-процесс вместо того, чтобы упрощать. Сделали бы единый легкий и user-friendly сайт доставки для сети ресторанов, наполнили его как классический каталог, проинтегрировали с 1С заказчика, чтобы максимально снизить количество ручного труда менеджеров и логистов по обработке заказов.

Хороший опыт, который, я надеюсь, больше никогда не пригодится в работе, поскольку такие большегрузные, перегруженные ajax-запросами проекты уже не кажутся актуальными. А современные фреймворки и библиотеки позволяют закрывать большинство задач без бубнов и танцев.

А что с проектом сейчас? Его уже нет. Эти сайты проработали несколько лет, пока заполонившие все агрегаторы не сделали содержание собственной службы доставки нерентабельным.

Спасибо за внимание!