TL;DR: Мы разработали региональный туристический портал с нуля, без конструкторов. В основе — реляционная база данных, где маршрут это не текст, а массив GPS-координат, связанных с точками интереса. Карту мы собрали не на тяжёлом стандартном виджете, а на кастомной картографии с оптимизированной кластеризацией, а наполнять портал может пожилой владелец гостевого дома со смартфона, не зная ни строчки HTML.
К нам обратились с задачей сделать туристический портал региона, который не стыдно поставить рядом с федеральными проектами. Формулировка звучала амбициозно, но за ней стояла очень конкретная боль: почти все региональные турсайты выглядят и работают одинаково плохо. В этом материале мы от первого лица разбираем, как устроен такой портал внутри — от структуры базы данных до админки, которую наполняют люди на местах, — и почему мы принципиально не собираем подобные проекты на конструкторах.
Проблема: список ссылок вместо портала
Давайте честно опишем типичный региональный турсайт. Это длинная страница со списком ссылок и заголовков: «Достопримечательности», «Как добраться», «Где остановиться». Где-то в середине вставлена карта — как правило, тяжёлый стандартный виджет, который грузится через раз, а на телефоне подвисает или вовсе не открывается. Маршруты описаны абзацами текста: «двигайтесь на север, затем поверните у реки». Фотографии разного размера, часть ссылок ведёт в никуда. Пользователь заходит на такой сайт, за десять секунд не понимает, куда ему поехать и что там есть, и уходит — обычно в соцсети, где хотя бы есть живые фото и отзывы.
Корень проблемы не в дизайне, а в подходе. Такой сайт — это витрина текста. Он ничего не знает про сам регион как про структуру: он не понимает, что такое маршрут, где находится точка интереса и как она связана с ближайшей турбазой. Поэтому он не может ничего предложить, посчитать или перестроить — он может только показывать буквы. Мы поставили себе обратную задачу: сделать портал, который оперирует не текстом, а данными. Тогда сайт превращается из брошюры в инструмент, который реально помогает спланировать поездку.
Архитектура и база данных
Всё начинается с модели данных. Мы заложили реляционную базу на PostgreSQL и описали регион через связанные сущности: «Маршруты», «Точки интереса» (POI), «Турбазы» и «Гиды». Это не просто таблицы для хранения текста — это описание того, как устроен регион с точки зрения путешественника.
Ключевое решение — как мы храним маршрут. В обычном сайте маршрут это абзац. У нас маршрут — это массив GPS-координат, последовательность точек на местности, связанная с точками интереса вдоль пути. То есть маршрут физически знает, через какие водопады, смотровые площадки и стоянки он проходит, где рядом турбаза и какой гид его водит. Благодаря этой связности портал умеет то, чего не умеет список ссылок: он может показать маршрут на карте линией, посчитать, что находится поблизости, и предложить альтернативу.
Отсюда вырастает главная пользовательская фича — маршрут можно перестроить под себя в один клик. Человек берёт готовый маршрут, убирает точку, которая ему неинтересна, добавляет турбазу, где хочет заночевать, — и портал пересобирает маршрут заново, потому что под капотом это операция над данными, а не переписывание текста руками редактора. Пользователь конструирует свою поездку, а не читает чужую инструкцию. Реляционная модель здесь не техническая роскошь, а то единственное, что вообще делает такое поведение возможным.
Кастомная картография вместо тяжёлых виджетов
Карта — сердце любого турпортала, и именно на ней проваливается большинство проектов. Стандартный путь — вставить готовый тяжёлый виджет карты. Он быстро появляется на странице, но дорого обходится: медленно грузится, тянет за собой лишний вес, плохо стилизуется под бренд и начинает захлёбываться, когда точек становится много. Мы пошли другим путём и собрали кастомную картографию на легковесных движках вроде Leaflet или Mapbox.
Первое, что это дало, — внешний вид. Мы подключили кастомные тайлы и стилизацию под брендбук региона, чтобы карта выглядела частью портала, а не чужим сервисом, вставленным в чужой рамке. Цвета, подписи, акценты — всё в единой айдентике. Карта перестаёт быть техническим элементом и становится лицом проекта.
Второе и более важное — производительность. Настоящий вызов начинается, когда на карте не десять точек, а пятьсот: POI, турбазы, гиды, объекты вдоль всех маршрутов. Если вывалить их все разом, браузер телефона начинает захлёбываться при зуме и перетаскивании. Мы решаем это оптимизированной кластеризацией маркеров: близкие точки при отдалении сворачиваются в компактные группы с числом объектов, а при приближении плавно раскрываются. Мы отдельно вылизывали момент зума — самый нагруженный сценарий, — чтобы даже на среднем смартфоне карта оставалась плавной и не подвисала. Для туриста, который планирует поездку с телефона в дороге, это разница между «пользуюсь» и «закрыл и ушёл».
Админка для нетехнологичного пользователя
Даже идеальный портал мёртв без свежего контента. А наполняют туристический портал не программисты, а люди на местах: сотрудники администрации, владельцы гостевых домов и турбаз, гиды. У них нет технического бэкграунда, и заставлять их разбираться в разметке — верный способ получить пустой сайт через месяц после запуска. Поэтому админку (CMS) мы проектировали как отдельный продукт со своим требованием: она должна быть понятна человеку, который никогда не слышал слова «HTML».
Наш внутренний критерий звучал так: пожилой человек, который сдаёт жильё, должен со своего смартфона загрузить фотографии и обновить цены сам, без звонка администратору и без чьей-либо помощи. Всё, что можно спрятать, мы спрятали. Вместо технических полей — простые понятные формы: загрузить фото кнопкой, вписать цену в поле, отметить объект на карте, поставив точку пальцем. Никаких тегов, никаких настроек, которые можно случайно сломать. Интерфейс прощает ошибки и ведёт пользователя по шагам.
Такой подход к CMS решает главную долгосрочную проблему региональных порталов — актуальность. Когда обновить информацию может любой владелец гостевого дома прямо со смартфона, данные на портале остаются живыми: цены совпадают с реальностью, фото свежие, новые объекты появляются сами. Портал перестаёт зависеть от одного перегруженного администратора и начинает наполняться силами всего региона. Именно ради этого — чтобы система жила и после сдачи проекта — мы и вкладываемся в простоту админки не меньше, чем в красоту витрины.
Отдельно стоит сказать про производительность и мобильный сценарий, потому что турпортал чаще всего открывают со смартфона прямо в дороге, где связь нестабильна. Мы оптимизируем портал так, чтобы ключевые экраны — карточка маршрута, карта, список объектов рядом — грузились быстро даже на слабом сигнале и не заставляли пользователя ждать. Изображения отдаются в адаптивных размерах под конкретный экран, данные подгружаются порциями по мере необходимости, а карта не тянет весь массив точек сразу. Это не косметика, а вопрос выживаемости продукта: турист, у которого портал завис на въезде в горы, больше туда не вернётся. Быстрый и лёгкий портал, работающий даже на среднем телефоне в неидеальных условиях, — обязательная часть задачи, а не приятное дополнение к красивой витрине.
Частые вопросы
Почему нельзя собрать турпортал на конструкторе сайтов? Конструктор оперирует блоками текста и картинок, а не данными. В нём маршрут — это абзац, а не массив координат, поэтому вы не сделаете ни живой перестройки маршрута, ни связи POI с турбазами, ни нормальной кластеризации пятисот точек на карте. Конструктор годится для визитки, но не для портала, который должен что-то считать и предлагать.
Зачем своя карта, если есть готовые виджеты? Готовые тяжёлые виджеты медленно грузятся, плохо стилизуются под бренд и подвисают при большом числе точек. Кастомная картография на легковесных движках даёт и внешний вид под брендбук, и производительность на слабых телефонах за счёт оптимизированной кластеризации маркеров.
Справятся ли с наполнением люди без технических навыков? Да, это и есть цель админки. Мы прячем всю техническую сложность за простыми формами: загрузить фото кнопкой, вписать цену, отметить точку на карте пальцем. Ориентир — чтобы пожилой владелец жилья обновил данные со смартфона сам, без знания HTML.
Почему в основе именно PostgreSQL и реляционная модель? Потому что турпортал — это про связи: маршрут связан с точками интереса, точки с турбазами и гидами. Реляционная база честно описывает эти связи и позволяет строить операции над ними — перестроить маршрут, найти ближайшие объекты. Без такой модели портал остаётся набором отдельных страниц.
Коротко о главном
Хороший туристический портал региона отличается от плохого не картинками, а тем, что внутри. Мы строим его на реляционной базе, где маршрут это живой объект из GPS-координат и связанных точек интереса, а не абзац текста. Карту собираем сами — со стилизацией под брендбук и кластеризацией, которая не роняет телефон на пятистах точках. А наполнять всё это может любой человек на местах прямо со смартфона.
Именно поэтому мы не собираем такие проекты на конструкторах: они не умеют работать с данными, а без данных портал превращается в тот самый список ссылок, из которого пользователь уходит в соцсети. Если вам нужен портал федерального уровня качества, разработанный с нуля под задачи региона, — приходите, разложим проект на понятные этапы и доведём до запуска.