Как мы перестали проксировать картинки через бэкенд и подружили PWA c S3 через presigned URL

История о том, как желание добавить загрузку фотографий в 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"]    }  ]}

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

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. Из минусов — нужно аккуратно управлять временем жизни подписанных ссылок и не забывать чистить незавершённые загрузки.