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

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

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

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

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

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

• Бэкенд-сервер для работы с данными

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

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

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

Этапы работ:

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

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

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

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

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

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

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

• Протестировали взаимодействия, проверили, откорректировали

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

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

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

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

• Контролировать доступ к материалам.

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

• Оптимизировать работу с запросами.

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

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

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

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

• Пользователь вводит email и пароль

• Нажимает кнопку «Войти»

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

• Система отправляет запрос на проверку

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

3. После входа:

• Пользователь попадает на главную страницу

• Система проверяет токены при каждом запросе

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

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

• Если оба токена неверны — доступ блокируется

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Загрузили все на мощное «железо»

• Использовали ядро D7 для повышения производительности.

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

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

• Оптимизировали работу с базами данных.

• Разделили нагрузку между серверами.

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

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

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

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

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

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

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

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

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

2. Если такой пользователь читает статью, сервер запоминает:

• какой у пользователя идентификатор;

• какую тему он читает;

• сколько раз он читал статьи этой темы.

  3. Когда пользователь возвращается на главную страницу, система анализирует:

• его идентификатор;

• какие темы он чаще всего читал.

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

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

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

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

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

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

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

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

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

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

• Фильтры по типу учреждений и получателям помощи (можно выбрать несколько параметров)

• Поиск по названию учреждения с автоматической центровкой на результат;

• Маркеры обновляются при изменении фильтров или поиска;

• Адаптивность для мобильных устройств.

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

• Кластеризации маркеров при увеличении масштаба;

• Оптимизированной загрузке карточек (по 50 штук).

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

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

• Маркеры на самой карте;

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

В заключении

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

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