DEV Community

shurichu
shurichu

Posted on

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

Top comments (0)