Портал «Движение Первых»
- Клиент
- Движение Первых
- Тип проекта
- Миграция / 1С-Битрикс / Интеграции / Node.js
- Период разработки
- 2024–2025
- Сайт
- Загрузка…
О проекте
В 2024–2025 годах я руководил технической реализацией портала «Движение Первых» и разрабатывал backend на 1С-Битрикс. Создавал компоненты и модули, ролевую модель с согласованием публикаций, конструктор блоков, REST API и интеграционные шины на Node.js. Курировал дизайн и вёрстку, консультировал команду по разработке и интеграции с CMS.
Что было сделано
- Техническое руководство проектом и консультации команды по 1С-Битрикс
- Курирование дизайна, вёрстки и контроль качества фронтенда
- Backend-разработка и интеграция интерфейсов с CMS
- Кастомные компоненты и модули 1С-Битрикс
- Разветвлённая ролевая модель и управление статусами публикаций
- Согласование новостей и постов с уведомлением ответственной роли
- Конструктор блоков для контентного редактирования типовых страниц
- REST-методы для элементов и разделов инфоблоков
- Интеграционные шины на Node.js: получение, обработка и передача данных
- Интеграция форм, заявок и оповещений
В 2024–2025 годах я руководил технической реализацией всероссийского портала «Движение Первых» и разрабатывал его серверную часть на 1С-Битрикс. Совмещал работу тимлида и backend-разработчика: помогал команде освоить платформу, курировал дизайн и вёрстку, создавал компоненты и модули, ролевую модель, REST API и интеграционные шины на Node.js.
Исходная
Ко мне обратилась студия, которой предстояло реализовать крупный информационный портал на 1С-Битрикс. У команды ещё не было опыта разработки на этой платформе и создания информационных сайтов такого масштаба. Я подключился, чтобы взять на себя сложную серверную разработку, выстроить технический подход и сопровождать команду на пути к выпуску продукта в установленные сроки.
Задача
Мне нужно было реализовать многофункциональный портал с управляемыми страницами, новостями, разветвлёнными правами пользователей, согласованием публикаций и обменом с внешними сервисами. Одновременно — согласовать работу дизайнеров, верстальщиков и разработчиков с требованиями CMS, чтобы готовыми разделами могла пользоваться редакция.
Масштаб и контекст проекта
Проект включал переход с Django на 1С-Битрикс. Портал объединял новости, проекты, мероприятия, региональные и первичные отделения, а также информацию для участников, родителей и наставников. Мне предстояло работать с несколькими типами контента, разными правами сотрудников и данными, поступающими из внешних систем.
Поэтому я рассматривал задачу как разработку системы управления информацией. За каждой страницей должны были стоять понятная структура данных, редактируемые поля и правила доступа. Публичный интерфейс, административная часть и интеграции нужно было связать так, чтобы обновление материала проходило через предусмотренный для него сценарий.
Технические решения приходилось согласовывать с командой по ходу разработки. Я объяснял, как подготовить блок для интеграции с Битрикс, какие данные должен возвращать компонент и где должна находиться прикладная логика. Эта работа шла параллельно с моей разработкой модулей и сервисов обмена.
Моя роль в проекте
Как тимлид я задавал подход к разработке на 1С-Битрикс, консультировал команду по компонентам и шаблонам, участвовал в контроле качества фронтенда. Как backend-разработчик — лично реализовывал серверную логику, кастомные модули и компоненты, REST-методы и интеграционные шины.
На этапах дизайна и вёрстки я помогал согласовать интерфейс с возможностями CMS: какие данные нужны блоку, что редактор сможет менять и как блок будет подключаться к компоненту. Дизайн создавали дизайнеры команды; я курировал этот процесс и проверял пригодность решений для последующей интеграции.
Как проходила работа
1. Определил подход к реализации на 1С-Битрикс
Вместе с командой разбирал структуру портала и требования к его разделам. Помогал переводить задачи в понятные для платформы сущности: инфоблоки, компоненты, шаблоны, пользовательские группы и модули. Для разработчиков, впервые работавших с Битрикс, это задавало общий подход к интеграции.
2. Связал дизайн и вёрстку с будущей CMS
Курировал подготовку интерфейсов и проверял вёрстку на соответствие требованиям проекта и правилам интеграции в 1С-Битрикс. Консультировал команду по подключению данных, устройству шаблонов и использованию компонентов. Это позволяло решать вопросы редактирования контента ещё во время подготовки страниц.
3. Разработал backend и кастомные компоненты
Реализовывал серверную часть портала и компоненты для задач, которым не хватало стандартных возможностей платформы. Списки проектов, первичные отделения, медиа и баннерные блоки связывал с данными CMS. Для типовых разделов адаптировал шаблоны штатных компонентов под интерфейс портала.
4. Настроил роли и логику публикации
Разработал кастомные модули для разветвлённой ролевой модели. Статус новости или поста зависел от прав автора: материал мог быть опубликован либо передан на проверку вышестоящей роли. В маршрут согласования входило уведомление ответственного пользователя.
5. Подготовил инструменты редактирования страниц
Создал конструктор блоков для контентного редактирования типовых страниц. Подключил формы, заявки и уведомления. Редакционная работа должна была выполняться через инструменты портала, без постоянного обращения к разработчику для изменения текста и содержимого блоков.
6. Реализовал обмен с внешними сервисами
Написал отдельные REST-методы на стороне Битрикс и интеграционные шины на Node.js. Шина получала данные другого сервиса, обрабатывала их и передавала в инфоблоки портала. Так внешняя информация включалась в ту же систему управления контентом, с которой работала редакция.
Ролевая модель и управление публикациями
На большом информационном портале доступ к материалу и право его опубликовать — разные действия. Контент-мейкеру нужна возможность подготовить новость, редактору — проверить её, администратору — управлять доступом. Обычный пользователь работает с публичными возможностями сайта.
Ролевую модель я связал с изменением статуса материала. Если у автора не было права самостоятельной публикации, сохранение новости не делало её доступной посетителям: материал переходил на анализ к вышестоящей роли, которая получала уведомление. При наличии соответствующих прав использовался предусмотренный для этой роли путь публикации.
| Роль | Задача в системе |
|---|---|
| Администратор | Управление доступом и настройками в рамках предоставленных полномочий. |
| Редактор | Работа с публикациями и проверка материалов в пределах своей роли. |
| Контент-мейкер | Подготовка новостей и постов; публикация или передача на согласование в зависимости от прав. |
| Пользователь | Доступ к публичной информации и пользовательским сценариям портала. |
Для этой логики использовал события Битрикс при добавлении и обновлении элементов инфоблока. Ограничение действовало на стороне CMS: группа автора учитывалась при сохранении материала, а не только при отображении кнопок интерфейса.
Сценарий согласования новости
Ниже — путь материала для автора, которому требуется проверка перед публикацией. У других ролей маршрут определяется их полномочиями.
- Автор готовит материалНовость или пост сохраняется в системе.
- Роль задаёт маршрутМатериал передаётся на согласование.
- Ответственный проверяетПолучает уведомление и анализирует публикацию.
- Новость выходит на сайтПосле решения пользователя с нужными правами.
1. Подготовка материала
Контент-мейкер создаёт новость или пост и заполняет содержимое через CMS. На этом этапе материал находится в рабочем процессе редакции.
2. Проверка полномочий автора
При сохранении система учитывает роль пользователя. Для автора без права прямой публикации материал сохраняется без выхода в публичную часть.
3. Передача и уведомление
Новость отправляется на анализ вышестоящей роли. Уведомление сообщает ответственному, что в системе появился материал, требующий его внимания.
4. Проверка и публикация
Пользователь с соответствующими полномочиями проверяет материал и принимает решение о его публикации. Только после прохождения предусмотренного маршрута новость становится доступной читателям.
Компоненты и структура контента
У портала много разделов с разным типом данных. Новостям нужны списки и детальные страницы, проектам — собственная выборка, отделениям — представление структуры, медиа — галереи. Одного универсального шаблона для всех этих задач недостаточно.
Я разрабатывал собственные компоненты и адаптировал штатные под нужные сценарии. В реализации использовались инфоблоки, а для части баннеров, каруселей и медиа — Highload-блоки. Подключение данных и отображение в шаблоне должны были оставаться согласованными, чтобы редактор мог обновлять содержимое через CMS.
Эту же логику объяснял команде: готовую вёрстку нужно интегрировать с компонентом, его результатом и настройками. При проверке фронтенда смотрел на то, как интерфейс будет работать с реальными материалами портала и как его смогут сопровождать другие разработчики.
Страницы для участников и родителей: разные подборки информации на общей компонентной основе портала.
Конструктор блоков для типовых страниц
Типовые страницы должны были редактироваться контентной командой. Для этого я создал конструктор блоков: содержимое страницы представлялось отдельными частями, связанными с предусмотренными для них шаблонами.
Редактор работал с контентом блоков, а внешний вид задавался подготовленной вёрсткой и её интеграцией. Такой подход позволял обновлять информацию в рамках согласованного оформления и повторно использовать типовые решения в разных разделах.
Концепция обмена
Портал был частью системы внешних сервисов. Для обмена я разрабатывал промежуточные сервисы на Node.js — интеграционные шины. Они получали данные источника, обрабатывали их в своём контуре и затем загружали подготовленную информацию в 1С-Битрикс.
- Внешний сервисПередаёт исходные данные.
- Шина на Node.jsПолучает и обрабатывает информацию.
- REST API порталаПринимает запрос к данным CMS.
- 1С-БитриксСохраняет сведения в инфоблоках.
Шина служила связующим звеном между форматом внешнего сервиса и структурой инфоблоков. Обработка проходила до записи в CMS, а на стороне Битрикс оставались методы работы с элементами и разделами. Это давало понятную границу между получением внешних данных и управлением контентом портала.
Я отвечал за оба конца этой части обмена: обработку на Node.js и REST-методы на стороне сайта. Поэтому мог согласовать, какие поля передаются, в какой инфоблок они попадают и какое действие должно выполняться при актуализации информации.
Собственные REST-методы
Для интеграций написал методы получения, добавления, изменения и удаления новостей и других элементов инфоблоков. Работа не была привязана к одной новостной ленте: запрос указывал нужный инфоблок и данные операции.
| Операция | Что решает |
|---|---|
| Получение | Выборка списка или отдельного материала с фильтрацией, сортировкой и постраничной выдачей. |
| Добавление | Создание элемента в выбранном инфоблоке с содержимым и предусмотренными свойствами. |
| Изменение | Обновление полей, свойств, привязки к разделу и активности материала. |
| Удаление | Удаление указанного элемента в рамках выбранного инфоблока. |
В методы добавил проверки обязательных параметров и существования элемента в указанном инфоблоке, ответы о результате операции и об ошибках. Отдельные методы позволяли работать с разделами. Такой интерфейс обмена использовался для передачи и актуализации информации сторонними сервисами проекта.
Формы, заявки и уведомления
Подключал формы и заявки к серверной логике портала и интегрировал оповещения. Для пользователя это завершало сценарий обращения, а для ответственного сотрудника давало информацию о поступившем запросе.
Уведомления использовались и в редакционном процессе: передача публикации вышестоящей роли должна была сопровождаться оповещением. Это связывало изменение статуса материала с последующим действием человека, который отвечает за проверку.
Техническое руководство и контроль качества
Основная сложность моей роли была в сочетании разработки и помощи команде. Пока я реализовывал модули, API и шины, другим участникам нужно было двигаться по своим задачам и правильно интегрировать интерфейсы в новую для них платформу.
Я консультировал по подходам к разработке на 1С-Битрикс, проверял вёрстку и помогал разбирать вопросы подключения компонентов. Курирование дизайна и фронтенда позволяло учитывать требования CMS до того, как неподходящее решение попадёт в серверный шаблон.
Контроль качества включал соответствие вёрстки стандартам и её пригодность для работы с компонентами Битрикс. Важен был весь путь: данные в административной панели, результат компонента и интерфейс, который увидит посетитель.
Результат
За время работы над проектом я реализовал backend портала на 1С-Битрикс, кастомные компоненты и модули, ролевые маршруты публикации, конструктор контентных блоков и REST API. Для обмена с внешними системами разработал шины на Node.js, которые получали и обрабатывали данные перед загрузкой в CMS.
Редакторы получили инструменты для обновления типовых страниц и подготовки публикаций. Ролевая модель связала доступ к материалам с порядком их согласования и уведомлениями, а REST-методы обеспечили получение, добавление, изменение и удаление данных выбранных инфоблоков.
Параллельно я сопровождал команду на этапах дизайна, вёрстки и интеграции: консультировал по Битрикс, проверял фронтенд и помогал связывать интерфейсы с серверной логикой. В этом проекте моя ответственность охватывала и собственную разработку, и техническое руководство реализацией портала.
Портал доступен по адресу будьвдвижении.рф. Здесь описана моя работа над проектом в 2024–2025 годах.