Всем привет, на связи Андрей!

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

Разные сервера — единый механизм

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

REST API — архитектурный стиль, определяющий правила взаимодействия между клиентом и сервером, используя протокол HTTP. Это гибкий и масштабный метод и для нашего проекта подошел больше. «ПроПаллиатив» — сложный и большой проект, в котором выгодно разделить Front и Back на два сервера:

Фронтенд-сервер для обработки пользовательских запросов
Бэкенд-сервер для работы с данными

Принцип работы прост: при запросе пользователя фронт обращается к бэку, который извлекает необходимые данные из базы и возвращает их в формате JSON.

Изучили за два дня

Мы с командой сели и за два рабочих дня разобрались и поняли, как действовать.

Этапы работ:

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

Развернули бэк-сервер, разработали структуру базы данных.

Большой документ с дета��ьной структурой блоков — Большой документ с детальной структурой блоков

Кастомизировали 1С Битрикс под специфические требования проекта: прописали структуру инфоблоками и хайлоуд-блоками, реализовали API-методы.

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

Хайлоуд-блок — это специальный инструмент для работы с большими наборами данных в условиях высоких нагрузок.

API-метод — это конкретная операция или функция, которую можно выполнить, обратившись к сервису через его API (интерфейс программирования приложений)

Развернули фронт-сервер: настроили так, чтобы все элементы отдавались корректно.
Протестировали взаимодействия, проверили, откорректировали

Сложно, но можно

1С-Битрикс предлагает встроенный механизм авторизации и регистрации на сайте.

Авторизация старых юзеров (перенесенных со старого сайта на Wordpress)

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

Мы реализовали систему на основе Json-Web-токенов и у нас получилось:

Контролировать доступ к материалам.
Обеспечить безопасность пользовательских данных.
Оптимизировать работу с запросами.

Какой плагин использовали?

Для генерации токенов доступа мы использовали php-билиотеку lcobucci-jwt .Почему этот плагин? Удобная в пользовании, легко усвоить новичку, легко предоставляет методы шифрования, есть все готовые методы для проверки достоверности токенов.

Процесс авторизации работает так:

Вход в систему:

Пользователь вводит email и пароль
Нажимает кнопку «Войти»

Проверка данных:

Система отправляет запрос на проверку
Если данные верны, создаются два токена: Access-token (действует 60 минут), Refresh-token (действует 5 лет).

После входа:

Пользователь попадает на главную страницу
Система проверяет токены при каждом запросе

Работа с токенами:

При истечении access-token система использует refresh-token для получения нового
Если оба токена неверны — доступ блокируется

Финальная проверка:

При успешной проверке определяются права и группы пользователя
Система предоставляет доступ согласно настройкам пользователя

Еще одна сложность проекта это работа с контентом. Как вы помните, его огромное количество и он разнообразен по формату и структуре: текстовые статьи, видеоматериалы, слайдеры, подложки, блоки «важно», «скачать», «читать книги».

За короткий срок мы перенесли весь контент со старого сайта на новый, но В РУЧНУЮ. Что? Как? Не могли автоматизировать?

Могли, конечно, но на разработку корректного автоматизированного процесса ушло бы еще больше времени. Кроме полноценной разработки, пришлось бы потом также вручную проходиться по каждой статье и проверять. Это очень смело — переносить «ручками» более 1000 материалов, но надежнее. Что-то, конечно, перенесли парсерами: справочники и карту учреждений, например.

Научили клиента управлять своим сайтом

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

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

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

И на человеческом языке мы создавали гайды, добавляли туда мемы и простые слова:

И если что-то неудобно в интерфейсе, слушали и меняли под запросы.

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

Где ошибки? А их нет

Ошибки могут быть связаны с производительностью: пиковые нагрузки, большие данные, много привязанных статей. Это все может давать сбой. Для стабильной работы мы:

Загрузили все на мощное «железо»
Использовали ядро D7 для повышения производительности.

Пример программного кода запроса к базе данных на ядре D7

Внедрили систему кэширования.

Пример кэширование запросов к базе данных

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

Оптимизировали работу с базами данных.
Разделили нагрузку между серверами.

Премия «Самый сложный блок портала»

Решили с командой на эту тему разогнать, в шутку, конечно, но может вам будет интересно.

1 место блок «Статьи»

Много времени ушло на оформление: единообразие, тэги, рекомендуемые статьи, связка с личным кабинетом и возможностями читателей. Например: неавторизованные читают то, что мы им предлагаем, исходя из истории их просмотров, авторизованные — сами решают, что они будут читать, отмечая интересные темы в ЛК.

Авторизованные — сами решают, что они будут читать, отмечая интересные темы в ЛК

История просмотров тем для неавторизованных юзеров хранится у нас хайлоуд-блоке. На основе данных из этого хайлоуд-блока мы строит рекомендательную систему для анонимных юзеров. Т.е. определяем, какие статьи им показывать на главной. Когда какой-то анонимный юзер заходит на сайт. То фронт ему присваивает идентифик��тор. И далее мы при просмотре этим юзером детальных статей, запоминаем тему этих статей.

В этой таблице у нас хранится идентификатор анонимного юзера

2 место блок «Библиотека и подборка статей»

Тут много настроек и много различных параметров. В больших подборках: множество параметров по специалистам. В маленьких подборках: конкретная тема.

Система работает так:

Когда пользователь без авторизации заходит на сайт, фронтенд передаёт бэкенду специальный идентификатор (X-uuid-user).
Если такой пользователь читает статью, сервер запоминает:

какой у пользователя идентификатор;
какую тему он читает;
сколько раз он читал статьи этой темы.
3. Когда пользователь возвращается на главную страницу, система анализирует:

его идентификатор;
какие темы он чаще всего читал.

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

Главная страница формируется из интересов пользователя

3 место «Фильтр»

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

Существует три состояния поиска:

1) Я кликнул по строке поиска и вижу историю своих предыдущих запросов

2) Начал набирать и вижу предварительные результаты поиска

3) Я нажал поиск, нажал enter, и перешел на страницу «Результаты поиска»

4 место «Интерактивная карта паллиативной помощи»

Это карта с более чем 2000 учреждений паллиативной помощи. Она автоматически определяет местоположение пользователя или центрируется на Москве.

Основные функции:

Фильтры по типу учреждений и получателям помощи (можно выбрать несколько параметров)
Поиск по названию учреждения с автоматической центровкой на результат;
Маркеры обновляются при изменении фильтров или поиска;
Адаптивность для мобильных устройств.

Карта работает быстро благодаря:

Кластеризации маркеров при увеличении масштаба;
Оптимизированной загрузке карточек (по 50 штук).

На карте есть два вида отображения информации:

Карточки слева с данными об учреждени;
Маркеры на самой карте;

При клике на карточку или маркер открывается подробная информация об учреждении.

В заключении

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

Хотите узнать больше о технических деталях проекта? Пишите в комментариях — с радостью отвечу на ваши вопросы.

Разработка просветительского портала «ПроПаллиатив»: взгляд изнутри