Shelpy: агрегатор приютов для животных — кейс с хакатона Kodik Launchpad

Shelpy: агрегатор приютов для животных — кейс с хакатона Kodik Launchpad

Идею подсказал случайный TikTok: приют просил помощи, в комментариях люди спрашивали «куда переводить», а реквизитов не было ни в шапке профиля, ни в описании. Проверил ситуацию по России шире — у большинства приютов либо нет сайта вообще, либо есть, но старый и неудобный. Единой точки, где можно посмотреть питомцев из разных приютов и написать напрямую, не нашлось. На хакатоне Kodik Launchpad решил закрыть именно эту дыру — так появился Shelpy.


Что это


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


Ключевой сценарий с обеих сторон:


1. Пользователь находит приют на карте или в каталоге, фильтрует питомцев по виду/возрасту/породе.

2. Открывает карточку животного, пишет приюту в чат внутри сервиса — без перехода в мессенджер и поиска контактов.

3. Либо нажимает «Пожертвовать» — и видит реальные реквизиты приюта (телефон для перевода по СБП с указанием банка, либо номер карты), которые приют один раз ввёл в своём профиле. Это прямое решение исходной проблемы: больше не нужно искать реквизиты в комментариях под постом — они всегда на странице приюта.

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


Архитектура и стек


Технически это классический монолит на Node.js, без лишней сложности — на хакатонных сроках она того не стоила.


Backend: Express 4, роуты разложены по доменам — `auth`, `shelters`, `pets`, `favorites`, `chat`, `donate`. Каждый модуль отвечает за свою зону, никакого «всё в одном файле».


src/

routes/ — auth, shelters, pets, favorites, chat, donate

middleware/ — auth, rateLimiter, upload

config/ — db.js (слой доступа к данным)

validators/


Хранилище: сейчас JSON-файлы через собственный слой доступа (`src/config/db.js`). Сознательно вынес его в отдельный модуль, чтобы миграция на SQLite/PostgreSQL потребовала переписать только этот слой, а не бизнес-логику в роутах.


Frontend: SPA на vanilla JS с hash-роутингом, без сборки и фреймворков — Tailwind CDN для стилей, Leaflet для карты. Решение осознанно простое: для объёма фронтенда, который нужен был к дедлайну, сборка и React дали бы больше накладных расходов, чем пользы.


Файлы: Multer с ограничением по размеру и MIME-типу — под фотографии питомцев.


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


Безопасность


Сервис работает с персональными данными и (пока в виде заглушки) с донатами, так что закрыл базовые пункты сразу, а не потом:


- пароли — только через bcrypt-хеши, plain text не хранится; политика пароля — минимум 8 символов, обязательно буквы и цифры;

- Helmet — стандартные защитные HTTP-заголовки;

- rate-limit на логин — ограничение попыток за 15 минут против брутфорса;

- реквизиты приюта (телефон+банк для СБП или номер карты) валидируются на бэкенде отдельной функцией — формат телефона (11 цифр), длина номера карты (16–19 цифр), обязательное поле банка при указании телефона;

- валидация остальных входных данных (email, телефон, длины строк) на бэкенде — фронтовая валидация не единственный барьер;

- секреты и конфиг только через `.env`, ничего не захардкожено в репозитории.


Что не успел и куда двигаться дальше


Это прототип с демо-данными (26 приютов, 21 питомец, роли «приют» и «пользователь» для входа), а не production-сервис. В приоритете после хакатона:


- миграция хранения с JSON на нормальную БД;

- приём донатов сейчас работает как прямая передача проверенных реквизитов приюта — без реального платёжного шлюза; следующий шаг — подключить эквайринг или СБП-интеграцию, чтобы перевод происходил прямо в интерфейсе;

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


Как использовал Kodik


Разворачивал Shelpy на хостинге Kodik — не пришлось отдельно настраивать сервер и деплой с нуля, что для хакатонных сроков было критично.


Репозиторий: https://github.com/3xstar/Shelpy