Городской справочник организаций с картой: кейс разработки под ключ

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

Коротко: заказчику нужен был собственный городской справочник организаций с картой под конкретный город. Проблема - зависимость от чужих платформ и отсутствие контроля над контентом и монетизацией. Я построил карту с рубрикатором, поиском и админкой модерации. Результат - работающий продукт с заделом на несколько городов, языков и платные кабинеты бизнеса.

Проблема заказчика

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

• иметь собственную карту с организациями именно своего города, без зависимости от чужой платформы;
• управлять контентом - добавлять, редактировать и модерировать заведения самостоятельно;
• заложить возможность зарабатывать на размещении бизнеса в будущем;
• не платить за карту и картографические ключи, пока проект не вышел на окупаемость.

Требовалось не подобие существующего сервиса, а полноценный продукт с собственной базой данных, витриной и админкой, спроектированный под конкретный город и конкретную бизнес-модель заказчика.

Какое решение предложил

Я предложил разделить продукт на публичную витрину и админку, и построить все на связке FastAPI и асинхронной PostgreSQL на бэкенде, React с картографической библиотекой Leaflet на фронтенде. Такой выбор дал три вещи сразу: бесплатную карту-подложку без платных ключей, гибкость в верстке карточек и рубрикатора, и возможность в любой момент заменить подложку на другую через настройку, если у заказчика появятся иные требования.

Ключевое архитектурное решение - проектировать сразу с прицелом на очереди развития. Базовая очередь (карта, справочник, админка с модерацией) была сделана и сдана в бою. Но модели данных, структура таблиц и API с самого начала учитывали то, что появится позже: кабинеты бизнеса с платными тарифами, отзывы и рейтинги, добавление новых городов из админки. Это избавляет заказчика от переписывания системы, когда он захочет расти.

Карта с кластеризацией

Центр продукта - интерактивная карта. Каждое заведение отмечено каплевидным маркером, цвет которого зависит от категории: так пользователь визуально различает кафе, аптеки, магазины и сервисы, не читая подписи. При отдалении карты одиночные маркеры объединяются в кластеры с числом заведений внутри - это стандартный прием, без которого карта с сотнями точек превращается в кашу.

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

Рубрикатор и фильтры

Рубрикатор сделан в стиле крупных справочников: десятки топ-рубрик (еда, красота, медицина, авто, услуги и так далее) и подрубрики внутри каждой. На главном экране - сетка категорий с иконками, чтобы пользователь мог сразу перейти к нужному разделу, а не искать через поиск.

Поверх рубрикатора добавлены быстрые фильтры, которые реально влияют на поведение пользователей: "открыто сейчас" отсекает закрытые в моменте заведения, а фильтры по удобствам (например, наличие определенных условий у заведения) сужают выдачу под конкретный запрос. Иконки категорий взяты из открытого набора и хранятся в базе как имя иконки, а не как эмодзи или картинка - это упрощает смену визуального стиля в будущем без миграции данных.

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

Поиск и карточки организаций

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

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

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

Админка и модерация

Вся содержательная часть - организации, категории, города - управляется через отдельную админку. Заказчик и его команда могут добавлять и редактировать заведения, распределять их по рубрикам, отклонять или подтверждать записи через модерацию. Это снимает с меня как с разработчика обязанность вручную наполнять базу и дает заказчику полный контроль над контентом.

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

Задел на мультигород и монетизацию

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

Мультиязычность я заложил не как отдельную "версию сайта", а как свойство самих данных: у названий и подписей может быть несколько языковых вариантов, и витрина выбирает нужный в зависимости от языка пользователя. Это принципиально дешевле в поддержке, чем держать параллельные копии контента, и позволяет запускать новый язык без пересборки. Для города, где живут люди с разными языками, или для последующего выхода в другой регион это дает заказчику готовую основу, а не обещание "когда-нибудь переделаем".

Для будущей монетизации в модели данных уже предусмотрен адаптер оплаты - пока это заглушка, но структура таблиц и связи между организацией и ее тарифом готовы к тому, что в следующей очереди появятся платные кабинеты бизнеса с расширенными возможностями размещения. Логика очередей развития здесь такая: сначала боевая базовая версия, которая уже приносит пользу городу, а затем поэтапно - кабинеты бизнеса, отзывы и рейтинги, самостоятельное добавление городов. Каждая следующая очередь опирается на уже существующие модели, а не ломает их. Это тот случай, когда проектирование "на вырост" экономит заказчику существенные деньги и время в будущем, потому что не требует переписывания ядра системы.

Стек и почему именно он

На бэкенде я выбрал FastAPI и асинхронную PostgreSQL с фоновыми задачами. Асинхронность важна именно для справочника: карта и поиск порождают много коротких запросов, и синхронный сервер быстро уперся бы в ожидание базы. Фоновые задачи вынесены отдельно, чтобы тяжелые операции - пересчеты, обработка данных, будущие интеграции - не блокировали ответы пользователю.

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

Частые вопросы

Как сделать свой городской справочник организаций с картой? Нужны три части: интерактивная карта с маркерами и кластеризацией, рубрикатор с поиском и фильтрами, и админка для управления контентом. В моем кейсе это связка FastAPI и PostgreSQL на бэкенде и React с Leaflet на фронтенде, а город изначально спроектирован как отдельная сущность, чтобы позже добавлять новые города через админку.

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

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

Сложно ли добавить второй город в такой справочник? Нет, потому что город изначально спроектирован как отдельная сущность в базе. Добавление нового города - это операция через админку, а не доработка кода.

Как быстро можно запустить платные кабинеты для бизнеса? Модель данных и адаптер оплаты уже заложены как заготовка, поэтому подключение реальной оплаты и личного кабинета бизнеса - это следующая очередь разработки, а не пересборка всей системы.

Какой стек выбрать для геосервиса с картой и поиском? Для карты с сотнями точек и живым поиском хорошо подходит асинхронный бэкенд (FastAPI и асинхронная PostgreSQL с фоновыми задачами) и React с Leaflet и кластеризацией на фронтенде. Такой набор дает бесплатную карту без платных ключей, быстрые подсказки в поиске и запас по нагрузке при росте числа городов и заведений.

Коротко о главном

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

Если вам нужен похожий сервис - городской справочник, отраслевой каталог с картой или геосервис под конкретный регион - готов обсудить задачу и собрать под ключ.