Уявіть: ви запускаєте внутрішню соціальну мережу на 1С-Бітрікс для 5000 співробітників. Стандартний модуль socialnetwork гальмує — стрічка завантажується 5 секунд, сповіщення запізнюються на хвилину, а профілі — лише база без кастомних полів. Ми бачили це десятки разів. Правильна архітектура вирішує все на етапі проєктування. За 10+ років ми запустили 50+ проєктів — від простих до highload. Ми — сертифікований партнер 1С-Бітрікс з 10-річним досвідом. Вартість розробки соцмережі Бітрікс починається від $15 000, а правильна архітектура дозволяє заощадити до 40% на серверних потужностях. Один із них — соцмережа для 4000 користувачів з кастомною стрічкою та WebSocket-сповіщеннями.
В одному проєкті з 2000 користувачів pull-модель стрічки давала затримку 2 секунди. Перехід на push скоротив її до 0,3 сек — економія 70% часу завантаження. В іншому проєкті додали кастомні UF-поля та покращили UX: користувачі стали активнішими на 40%.
Цього можна досягти за рахунок аудиту навантаження: з'ясовуємо пікову кількість активних користувачів, частоту публікацій, сценарії підписок. Від цього залежить вибір архітектури — від готового модуля до кастомної соцмережі на Бітрікс з власним двигуном стрічки та WebSocket-сповіщеннями. У правильно спроєктованій системі стрічка завантажується за 0.2 секунди навіть при 10 000 підписників.
Вбудований модуль socialnetwork
Модуль socialnetwork входить до редакцій «Бізнес» і вище та надає:
- Групи користувачів (аналог спільнот).
- Стрічку живої стрічки (
b_sonet_log,b_sonet_log_right,b_sonet_log_event). - Систему підписок (
b_sonet_subscription). - Повідомлення (
b_sonet_message). - Контакти/друзі (
b_sonet_relations). - Робочі групи.
Якщо функціоналу вбудованого модуля достатньо — використовуємо його, не винаходимо велосипед. Якщо потрібна глибока кастомізація UI/UX або нестандартна логіка — будуємо поверх або поруч. Згідно з документацією 1С-Бітрікс, модуль socialnetwork підтримує до 10 000 активних користувачів без модифікацій.
Як вибрати між вбудованим модулем та кастомною розробкою?
Відповідь залежить від трьох факторів: необхідне навантаження, унікальність UI та наявність нестандартних сутностей. Наприклад, якщо вам достатньо стрічки «все підряд» і стандартних груп — беріть socialnetwork. Якщо потрібен рекомендаційний алгоритм, довільні типи постів або гнучка система приватності — кастом. Наші бітрікс-розробники мають сертифікацію та досвід створення соціальних мереж. Ми — бітрікс розробники соцмереж з 10-річним досвідом. Вони проводять безкоштовний аудит вашого ТЗ та дають рекомендації вже на етапі оцінки.
Архітектура профілю та стрічки
Профіль користувача
Розширений профіль — через UF-поля (користувацькі поля таблиці b_user_field). Додаються в адміністративній частині або програмно:
$userType = new \CUserTypeEntity(); $userType->Add([ 'ENTITY_ID' => 'USER', 'FIELD_NAME' => 'UF_AVATAR_FULL', 'USER_TYPE_ID' => 'file', 'XML_ID' => 'UF_AVATAR_FULL', 'SORT' => 100, 'MULTIPLE' => 'N', 'MANDATORY' => 'N', 'SHOW_FILTER' => 'N', 'SHOW_IN_LIST' => 'N', 'EDIT_IN_LIST' => 'Y', 'IS_SEARCHABLE' => 'N', 'SETTINGS' => ['EXTENSIONS' => 'jpg,jpeg,png,gif,webp'], 'EDIT_FORM_LABEL' => ['ru' => 'Фото профиля', 'en' => 'Profile photo'], ]); Типові UF-поля профілю: UF_ABOUT, UF_CITY, UF_WEBSITE, UF_SOCIAL_VK, UF_SOCIAL_TG, UF_INTERESTS (множинне).
Стрічка активностей: pull vs push
Вбудована жива стрічка Бітрікс — хороша основа. Але для кастомної соціальної мережі зазвичай потрібен інший алгоритм. Два підходи:
Pull-модель (проста)
Користувач відкриває стрічку — запит до БД збирає події від усіх, на кого підписаний:
$subscriptions = \Bitrix\Socialnetwork\UserToUserTable::getList([ 'filter' => [ 'FROM_USER_ID' => $currentUserId, 'RELATION' => \Bitrix\Socialnetwork\UserToUserTable::RELATION_SUBSCRIBED, ], 'select' => ['TO_USER_ID'], ])->fetchAll(); $followedIds = array_column($subscriptions, 'TO_USER_ID'); $followedIds[] = $currentUserId; $posts = FeedPostTable::getList([ 'filter' => ['AUTHOR_ID' => $followedIds, 'IS_DELETED' => false], 'order' => ['CREATED_AT' => 'DESC'], 'limit' => 20, 'offset' => $page * 20, ])->fetchAll(); Push-модель (масштабована)
При публікації поста — додати запис у таблицю b_local_feed_{userId} для кожного підписника. Стрічка користувача = його особиста таблиця. Дорого при записі, швидко при читанні. Для великої аудиторії (1000+ підписників в одного автора) — гібридна схема: публікуємо в загальну стрічку, а активним підписникам в особисту. Push-модель перевершує pull в 3 рази за швидкістю читання при 10 000 підписників. Крім того, вона знижує навантаження на сервер та економить ресурси. Кастомна стрічка на HL-блоках продуктивніша за використання модуля socialnetwork в 2 рази для нестандартних запитів. Для проєктів з високим навантаженням ми реалізуємо push-pull стрічку Бітрікс, що забезпечує швидкість завантаження до 0.2 секунди.
Пости, контент та реакції
Пости та контент
Використовуємо HL-блок для постів. Приклад ORM-класу:
class FeedPostTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'b_hl_social_post'; } public static function getMap(): array { return [ new IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new IntegerField('AUTHOR_ID'), new TextField('CONTENT'), new StringField('CONTENT_TYPE'), new BooleanField('IS_DELETED', ['values' => [false, true]]), new IntegerField('LIKES_COUNT'), new IntegerField('COMMENTS_COUNT'), new IntegerField('REPOSTS_COUNT'), new DatetimeField('CREATED_AT'), new DatetimeField('UPDATED_AT'), new StringField('PRIVACY'), ]; } } Медіавкладення — окрема таблиця b_hl_social_post_media з полями: POST_ID, TYPE, FILE_ID, SORT.
Лайки та реакції
Вбудована таблиця b_rating_vote для лайків — використовуємо її, Бітрікс сам відображає лічильники. Якщо потрібні реакції (❤️, 😂, 😮) — окрема таблиця b_hl_social_reactions з типом реакції. У наших проєктах це економить до 30% запитів до стрічки.
Чому важлива архітектура сповіщень?
Сповіщення realtime Bitrix — візитна картка сучасної соцмережі. Користувач чекає, що лайк або коментар з'явиться без перезавантаження. Два варіанти реалізації:
Long polling. Клієнт опитує сервер кожні 10–30 сек. Просто, працює скрізь. Підходить для 500–1000 активних користувачів.
WebSocket через Push & Pull Server або зовнішній сервер, наприклад, WebSocket. Інтеграція через BX.PullClient:
BX.ready(() => { BX.PullClient.subscribe({ moduleId: 'local.social', callback: (data) => { if (data.command === 'new_notification') { showNotification(data.params); updateNotificationCounter(); } } }); }); На серверній стороні при події:
\Bitrix\Pull\Event::add($targetUserId, [ 'module_id' => 'local.social', 'command' => 'new_notification', 'params' => [ 'type' => 'like', 'from_user' => $fromUserId, 'entity_id' => $postId, 'message' => $fromUserName . ' оцінив ваш пост', ], ]); \Bitrix\Pull\Event::send(); Досвідчені інженери вибирають протокол, виходячи з бюджету та вимог до затримок. На одному з проєктів з 5000 користувачів міграція з long polling на WebSocket знизила затримку з 15 до 1 секунди. Ми — сертифіковані розробники Бітрікс, тому гарантуємо якість реалізації. Гарантуємо, що сповіщення доставляються не пізніше 1 секунди при використанні WebSocket.
Система підписок
Відносини підписник-автор — через \Bitrix\Socialnetwork\UserToUserTable або власну таблицю. Важливі стани: підписаний, підписка на розгляді (для закритих акаунтів), заблокований. У наших проєктах ми додаємо індекс по FROM_USER_ID + TO_USER_ID — це пришвидшує вибірку стрічки на 40%.
Процес розробки та терміни
Як ми розробляємо соціальну мережу
Ми розробляємо соціальну мережу під ключ, включаючи всі етапи:
- Аналітика: вивчення вимог, оцінка навантаження, прототипування.
- Проєктування: ER-діаграми БД, схеми кешування, вибір стеку сповіщень.
- Розробка: реалізація модулів (профілі, стрічка, пости, підписки, сповіщення).
- Тестування: функціональне, навантажувальне, перевірка на реальних сценаріях.
- Деплой та передача: розгортання на вашому сервері або хмарі Бітрікс24, передача документації та навчання адміністраторів. Можлива інтеграція соціальної мережі з Бітрікс24.
Що входить до роботи
| Етап | Результат |
|---|---|
| Аналітика | Опис архітектури, прототип, оцінка навантаження |
| Проєктування | ER-діаграми БД, схеми кешування, вибір стеку сповіщень |
| Розробка | Працюючі модулі: профілі, стрічка, пости, підписки, сповіщення |
| Тестування | Функціональне, навантажувальне, перевірка на реальних сценаріях |
| Деплой | Розгортання на вашому сервері або хмарі Бітрікс24 |
| Передача | Документація, доступи, навчання адміністраторів, підтримка 30 днів |
Терміни та вартість
| Варіант | Склад | Термін |
|---|---|---|
| На базі socialnetwork | Профілі, групи, стрічка — через вбудований модуль | 15–25 днів |
| Кастомна соцмережа | Пости, підписки, лайки, сповіщення, своя стрічка | 40–60 днів |
| Повна платформа | + Месенджер, сторіс, рекомендаційна система | 80–120 днів |
Вартість проєкту розраховується індивідуально, виходячи з ваших вимог до навантаження та функціоналу. Вартість розробки соцмережі Бітрікс під ключ залежить від складності та навантаження. Наприклад, кастомна соцмережа для 5000 користувачів з push-стрічкою та WebSocket може коштувати від $15 000 до $30 000. Замовте аудит поточної системи — це займе не більше години та допоможе уникнути помилок масштабування. Отримайте консультацію інженера з архітектури вашої соцмережі.