История о том, как желание добавить загрузку фотографий в PWA‑приложение вылилось в пересмотр архитектуры, борьбу с дублированием трафика и внедрение прямой загрузки в MinIO с модерацией в Telegram‑боте.
Когда в нашем PWA‑приложении возникла задача добавить загрузку изображений, первое, что пришло в голову — классическая схема: клиент → бэкенд → S3. Но стоило копнуть глубже и учесть особенности PWA (офлайн, кэширование), несколько типов файлов с разными правами доступа и требования масштабирования, как наивное решение рассыпалось. В итоге мы пришли к архитектуре с presigned URL, разгрузили бэкенд и получили гибкую систему модерации. Делюсь этим опытом и ключевыми шишками, которые набил.
Задача
В PWA‑приложение требовалось добавить загрузку фотографий. Несколько типов:
Изображения для обработки нейросетями;
Превью для карточек (могут быть публичными или с ограниченным доступом);
Файлы, которые пользователь может удалить после обработки.
С самого начала было понятно, что функционал могут использовать не по назначению, поэтому нужна модерация. Вариант с мультимодальной моделью выглядел логично: очередь, воркер, классификация. Но на старте, в пилотном режиме, мы решили обойтись более простым решением — ботом в Telegram с ручным подтверждением.
Решение «в лоб» и почему от него отказались
Первая реализация была прямолинейной:
Клиент загружает файл на бэкенд.
Бэкенд сохраняет его в S3 (MinIO).
При отображении бэкенд проверяет права и проксирует файл с S3 обратно клиенту.
Сразу стали очевидны проблемы:
Двойной трафик — каждый загруженный мегабайт прокачивается через сервер дважды.
Забитые коннекты — при большом количестве клиентов быстро исчерпываются доступные соединения на бэкенде.
Нет CDN — классический CDN сложно прикрутить, потому что доступ определяется динамически в момент запроса.
Дорогое масштабирование — вынести проверку прав на отдельный сервер (S3 + прокси‑сервер с запросами к бэкенду) технически можно, но это лишние звенья и расходы.
Было ясно: схема с проксированием плохо ложится на PWA с офлайн‑кэшированием и фоновой синхронизацией. Нужно было искать более «нативный» для S3 подход.
Спасительный presigned URL
После изучения документации MinIO (и оригинального S3 API) выяснилось, что он поддерживает механизм presigned URL. Суть проста:
Для загрузки: бэкенд генерирует временную подписанную ссылку, по которой клиент может напрямую отправить файл в бакет. Права доступа и лимиты контролируются на этапе выдачи ссылки.
Для чтения: бэкенд по запросу клиента выдаёт временную presigned GET URL. Публичный доступ к файлам при этом не открывается.
Таким образом, трафик идёт напрямую между клиентом и S3, бэкенд остаётся только в роли «контролёра». Единственная дополнительная настройка, которая потребовалась — CORS для бакета. В MinIO это решается простым JSON‑файлом политики, загружаемым через API.
aws s3api put-bucket-cors --bucket $BUCKET_NAME --endpoint-url $S3_ENDPOINT --cors-configuration file://$PATH_TO_JSON
Файл конфигурации:
{
"CORSRules": [
{
"AllowedHeaders": ["*"],
"AllowedMethods": ["GET", "POST", "PUT"],
"AllowedOrigins": ["https://domain.ru"]
}
]
}
Как выглядит итоговая архитектура
Запрос на загрузку. Клиент просит у бэкенда URL для загрузки. Бэкенд проверяет лимиты (количество непромодерированных файлов, квота) и возвращает presigned PUT URL.
Загрузка напрямую. Клиент отправляет файл в S3 по этому URL. Если в процессе произошла ошибка (сеть отвалилась), то планировщик позже подчищает «осиротевшие» файлы.
Фиксация. После успешной загрузки клиент отправляет бэкенду идентификатор файла и обновляет сущность (например, карточку). Бэкенд ставит файл в очередь на модерацию.
Отображение. При запросе карточки клиент получает список изображений в формате: идентификатор + временная presigned GET URL. Если изображение уже закэшировано в локальном хранилище PWA — отображается кэш, если нет — клиент загружает его по ссылке и сохраняет в кэш для офлайна.
Такой подход не только убирает лишнюю нагрузку с бэкенда, но и естественно ложится на стратегию cache‑first в сервис‑воркерах PWA.
Модерация на коленке для пилота
В пилотном режиме мы не стали сразу подключать мультимодальную модель, а сделали ручную модерацию через Telegram‑бота:
Бот получает задачу, загружает thumbnail изображения и отправляет его в специальный чат с кнопками «Да/Нет».
Если модератор отклоняет фото, запись в базе помечается статусом «не пройдено».
При накоплении определённого лимита отклонённых файлов для пользователя временно блокируется возможность загрузки.
В будущем, при автоматической классификации, такая ручная проверка станет эскалационным контуром для спорных случаев.
Выводы
Переход на presigned URL дал нам:
Снижение нагрузки на бэкенд в разы — сервер больше не гоняет мегабайты туда‑сюда.
Простоту масштабирования — S3 и MinIO отлично справляются с большим числом параллельных соединений.
Совместимость с CDN — при необходимости можно легко раздавать публичные файлы через CDN, подписывая ссылки.
Естественную поддержку офлайн‑режима PWA — кэширование на клиенте работает без лишних прослоек.
Из неожиданных плюсов: схема с presigned URL оказалась понятной даже фронтенд‑разработчикам, которые раньше не работали напрямую с S3. Из минусов — нужно аккуратно управлять временем жизни подписанных ссылок и не забывать чистить незавершённые загрузки.