История о том, как желание добавить загрузку фотографий в PWA‑приложение вылилось в пересмотр архитектуры, борьбу с дублированием трафика и внедрение прямой загрузки в MinIO с модерацией в Telegram‑боте.

Когда в нашем PWA‑приложении возникла задача добавить загрузку изображений, первое, что пришло в голову — классическая схема: клиент → бэкенд → S3. Но стоило копнуть глубже и учесть особенности PWA (офлайн, кэширование), несколько типов файлов с разными правами доступа и требования масштабирования, как наивное решение рассыпалось. В итоге мы пришли к архитектуре с presigned URL, разгрузили бэкенд и получили гибкую систему модерации. Делюсь этим опытом и ключевыми шишками, которые набил.

Задача

В PWA‑приложение требовалось добавить загрузку фотографий. Несколько типов:

  • Изображения для обработки нейросетями;

  • Превью для карточек (могут быть публичными или с ограниченным доступом);

  • Файлы, которые пользователь может удалить после обработки.

С самого начала было понятно, что функционал могут использовать не по назначению, поэтому нужна модерация. Вариант с мультимодальной моделью выглядел логично: очередь, воркер, классификация. Но на старте, в пилотном режиме, мы решили обойтись более простым решением — ботом в Telegram с ручным подтверждением.

Решение «в лоб» и почему от него отказались

Первая реализация была прямолинейной:

  1. Клиент загружает файл на бэкенд.

  2. Бэкенд сохраняет его в S3 (MinIO).

  3. При отображении бэкенд проверяет права и проксирует файл с 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"]
    }
  ]
}

Как выглядит итоговая архитектура

архитектура загрузки изображений с помощью Signed URL
архитектура загрузки изображений с помощью Signed URL

  1. Запрос на загрузку. Клиент просит у бэкенда URL для загрузки. Бэкенд проверяет лимиты (количество непромодерированных файлов, квота) и возвращает presigned PUT URL.

  2. Загрузка напрямую. Клиент отправляет файл в S3 по этому URL. Если в процессе произошла ошибка (сеть отвалилась), то планировщик позже подчищает «осиротевшие» файлы.

  3. Фиксация. После успешной загрузки клиент отправляет бэкенду идентификатор файла и обновляет сущность (например, карточку). Бэкенд ставит файл в очередь на модерацию.

  4. Отображение. При запросе карточки клиент получает список изображений в формате: идентификатор + временная presigned GET URL. Если изображение уже закэшировано в локальном хранилище PWA — отображается кэш, если нет — клиент загружает его по ссылке и сохраняет в кэш для офлайна.

Такой подход не только убирает лишнюю нагрузку с бэкенда, но и естественно ложится на стратегию cache‑first в сервис‑воркерах PWA.

Модерация на коленке для пилота

В пилотном режиме мы не стали сразу подключать мультимодальную модель, а сделали ручную модерацию через Telegram‑бота:

  • Бот получает задачу, загружает thumbnail изображения и отправляет его в специальный чат с кнопками «Да/Нет».

  • Если модератор отклоняет фото, запись в базе помечается статусом «не пройдено».

  • При накоплении определённого лимита отклонённых файлов для пользователя временно блокируется возможность загрузки.

  • В будущем, при автоматической классификации, такая ручная проверка станет эскалационным контуром для спорных случаев.

Выводы

Переход на presigned URL дал нам:

  • Снижение нагрузки на бэкенд в разы — сервер больше не гоняет мегабайты туда‑сюда.

  • Простоту масштабирования — S3 и MinIO отлично справляются с большим числом параллельных соединений.

  • Совместимость с CDN — при необходимости можно легко раздавать публичные файлы через CDN, подписывая ссылки.

  • Естественную поддержку офлайн‑режима PWA — кэширование на клиенте работает без лишних прослоек.

Из неожиданных плюсов: схема с presigned URL оказалась понятной даже фронтенд‑разработчикам, которые раньше не работали напрямую с S3. Из минусов — нужно аккуратно управлять временем жизни подписанных ссылок и не забывать чистить незавершённые загрузки.