Комментарии

Мы ждали и оттягивали создание социальной сети до момента когда ДСТ выпустят модуль рекламной биржи для монетизации социальной сети, ведь без монетизации данное предприятие как создание собственной соцсети по факту безсмысленное и затратное, с монетизацией это уже другое дело. Советую всем кто приобретает или разрабатывает соцсеть, сразу брать модуль рекламной биржи

Раньше собственная социальная сеть была очень дорогостоящим и рисковым предприятием, сейчас же можно купить просто коробку, купить модуль рекламной биржи для дальнейшей монетизации, снять сервер и уложиться в сумму не более чем 1 миллион рублей — удобно

Главное по моему мнению это оптимизация баз данных и устранение узких мест в хранении и доставке контента так как все социальные проекты и сервисы, в том числе и соцсети держатся именно на трансляции контента пользователям, то что в ДСТ платформ данные функции встроены это приятно и правильно

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

В начале ДСТ CRM показалась очень сложной и через мерной, но по совету менеджеров решили внедрения функций по этапно и постепенно, через 3 месяца уже не знаем что бы делали без неё

Сейчас время экосистем, так как это не только удобно но и дает организации преподнести все свои продукты в рамках единой платформы, что несомненно удобно и выгодно

Спасибо интересно, сейчас в нашей компании решаем на какой технологии строить экосистему и скорее всего расмотрим либо Ларавел, либо ДСТ платформ

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

Об Ангуларе много слышал и наши айтишники о нем все время говорят, но как по мне слишком сложен для российских реалий, нам нужно что по проще и по скромнее

Честно говоря все эти новомодные фреймворки слишком не приминимы в Российских реалиях, тут людям нужно что по проще и по скромнее

Хорошая статья, плюсую

Хотелось бы почитать о монетизации маркетплейса более подробно, какие есть варианты и способы, заранее благодарю

Хорошая статья, тоже считаю что сейчас время нишевых маркетрлейсов, так как обще тематические уже монополизированны и понятно кем

Насчёт: Существует два варианта, как вы можете создать онлайн-маркетплейс: написать код с нуля, например, на современном фреймворке Laravel или использовать готовую платформу, например, DST Platform с индивидуальной доработкой функционала.

На Laravel конечно это можно создать, вот только автор не написал что для этого понадобится от года до полтора времени, что совершенно по моему не рационально

Тут сразу можно добавить что еще недостаточно гибкая архитектура

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

За пример возьмем простой элемент «Документ», который обладает характеристиками:

тип;
дата формирования;
автор;
наличие подписи;
кем подписан.

Он хранится в разделе «Заявления», подраздел «Запросы на справку».

Поле «Кем подписан» связано с инфоблоком — справочником сотрудников. Предположим, что данные поступают из внешней базы данных. Стандартный механизм импорта данных не предусматривает возможности обновления — только стирание и запись заново.

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

Для двух-трех инфоблоков — не страшно, но когда их десятки, то происходит следующее:

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

Главное в Битриксе это проблемы масштабирования

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

Тяжелая интеграция с современными средствами разработки публичной части сайта (верстки)

Современные решения: VueJS, Angular, React и т. п. позволяют ускорить и разработку сайта, и саму работу. Интеграция с 1С-Битрикс возможна, но она, наоборот, увеличивает время разработки.

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

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

Типичная ситуация, когда знакомишься с новым проектом на Битрикс, первым же делом лезешь в php_interface, чтобы посмотреть сколько костылей поверх Битрикса поставили предыдущие разработчики. А почему? А потому что без них нельзя, писать модуль для расширения стандартного функционала будут только мазохисты.

И да, после меня в php_inerface останется ещё пара костылей, так принято, такие у нас традиции…

Докину ещё парочку «остроумных инженерных решений»:

1. Если в публичке в константе SITE_ID содержится id сайта, то в админке эта константа будет содержать id языка ( то есть «ru» вместо «s1» ).

2. (скорее всего, следствие из п.1) в админке не подключаются файлы раздельных init.php для сайтов ( то есть, например, /local/php_interface/s1/init.php )

3. некоторые методы в классах ядра объявлены как final, так что нельзя просто взять, отнаследоваться и переопределить; приходится подниматься выше по цепочке наследования и копипастить не совсем нужное.

Вот мои не «типичные аргументы о недостатках платформы»:

Инфоблоки без сомнения являются «сердцем» Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д.
А потом попробуем получить инфоблок — по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) — нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?

О, документация, любимица всех битриксойдов! Получение списка элементов инфоблока, чуть ли не основной метод Битрикса — в первом же примере кода ошибка.
Описание части методов вообще утрачено, пример.

Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас «ко-пилоты» и BI-аналитика в последнем обновлении.

Про обновления, кстати. В статье ошибкой номер 1 указано «создание самописных компонентов». А вот без самописных компонентов на чистом Битрксе, да на том же Аспро — ставишь обновление — пропадают цены у товаров. Купить ничего нельзя, в корзину добавить нельзя, все товары недоступны — это так называемая обратная совместимость. Каждое обновление как пороховая бочка — сперва на тесте, потом на тесте теста, потом тестирование теста… ну вы поняли. В итоге придумали параметр «COMPATIBLE_MODE», везде пойди проставь, при обновлении-то нельзя автоматически это сделать.

Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь — к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок «сопутки» — так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.

Компанию по email получить нельзя… Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.

Или вот еще, допустим, была у вас на сайте форма, создающая лиды в портале. Простой понятный процесс — форму заполнил, лид создался. Обновляешь портал — файлы из формы не грузятся. А почему? Потому что выпилили загрузку файлов в лидах! Как говорится в статье, «встает вопрос «Кто виноват?» »…

Ух наболело, разошелся я что-то. Вот вам последняя загадка.

Как называется таблица в которой хранится URL сайта (для многосайтовости)?
Варианты:
1. b_site
2. b_url
3. b_domain
4. b_lang