Группировка по дате и пользовательским событиям

1.80M

Разработка_модуля_загрузки_файлов_для_платформы_Pixlpark

1.

Министерство науки и высшего образования Российской Федерации
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ (НИ ТГУ)
Институт прикладной математики и компьютерных наук
Разработка модуля загрузки файлов
для платформы Pixlpark
Направление подготовки:
09.03.03 Прикладная информатика
Образовательная программа «Разработка программного обеспечения в цифровой
экономике»
Исполнитель: студент группы 932203 Орлов Степан Алексеевич
Руководитель: канд. техн. наук, доцент Шкуркин А.С.

2.

Актуальность работы
Pixlpark – SaaS-платформа класса Web-to-Print, где пользовательские
фотографии и макеты являются основой производственного процесса.
Модуль загрузки файлов напрямую влияет на пользовательский опыт,
конверсию и устойчивость сервиса при работе с большими объёмами контента.
Для современной W2P-платформы критичны скорость загрузки,
безопасность, обработка больших файлов и поддержка разных источников
пользовательского контента.
2

3.

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

4. Постановка задачи

Цель: разработать и реализовать современный, эффективный и безопасный
модуль загрузки файлов, интегрированный в платформу.
Ожидаемый результат – модуль, который поддерживает большие файлы,
прямую загрузку в облако, дедупликацию, асинхронную обработку и покрывает
все пользовательские сценарии.
4

5. Задачи

1.
Проанализировать предметную область и особенности платформы Pixlpark;
2.
Исследовать существующие решения для загрузки файлов в вебприложениях;
3.
Сформулировать функциональные и нефункциональные требования к
модулю;
4.
Спроектировать архитектуру клиентской, серверной и фоновой частей;
5.
Реализовать модуль с учётом безопасности и производительности;
6.
Провести тестирование и оценить эффективность разработанного решения.
5

6.

Анализ существующих решений
Категория
Преимущества
HTML API
Простота, нет внешних
зависимостей
Open Source библиотеки
SaaS-сервисы
Собственный модуль
Недостатки
Нет полноценного UX,
возобновления, внешних
источников
Виджеты, предпросмотр
Сложная интеграция с
внутренней средой
платформы
Готовая инфраструктура для Передача пользовательских
хранения и доставки файлов файлов третьей стороне
неприемлема
Полная интеграция с
Требует проектирования,
платформой
реализации и тестирования
6

7. Требования к модулю

Функциональные:
1. Создание миниатюр
2. Индикация прогресса и отмена
Нефункциональные:
1. Поддержка файлов не менее 512
МБ;
загрузки;
2. HTTPS/TLS и контроль доступа;
3. Дедупликация;
3. Серверная валидация форматов;
4. Удаление персональных
4. Асинхронная обработка
данных пользователей
5. SignalR-уведомления;
ресурсоёмких операций;
5. Адаптация под нересурсоёмкие
устройства.
7

8. Пользовательские сценарии

1. Поиск среди загруженных файлов по названию
2. Группировка фотографий по дате съёмки или пользовательскому событию
3. Фильтрация по категориям: все файлы, новые загрузки, загруженные
сегодня, без альбома
4. Импорт файлов из внешних источников: Яндекс Диск, ВКонтакте,
Одноклассники
5. Загрузка фотографий со смартфона по QR-коду
8

9. Технологический стек и архитектура

Клиентская часть: React, TypeScript, MobX, Web Worker, SignalR client
Серверная часть: C#, ASP.NET, Entity Framework, SignalR
Инфраструктура: MS SQL Server, Redis, Yandex Object Storage, RabbitMQ (RPСочередь)
Архитектура клиентской части: UI-компоненты (FSD[1]), MobX-store, APIservices
Архитектура серверной части: контроллеры, сервисный слой, репозитории
1. Feature-Sliced Design. Обзор [Электронный ресурс]. – URL: https://fsd.how/ru/docs/get-started/overview/ (дата обращения: 09.05.2026).
9

10. Конвейер обработки файлов

1. Клиентская предобработка: MD5, предпросмотр и EXIF обрабатываются в фоновых
потоках.
2. Контентная идентификация: MD5 используется для дедупликации до передачи файла.
3. Адаптивная маршрутизация: выбор между прямой загрузкой в объектное хранилище и
серверным маршрутом.
4. Разделение ответственности: HTTP API отделяется от генерации миниатюр и очистки
метаданных.
5. Событийная синхронизация: статус обработки доставляется клиенту через SignalR.
10

11.

Диаграмма пакетов
Рисунок 3 – Диаграмма пакетов модуля загрузки файлов [2]
2. Моисеев А. Н., Литовченко М. И. Основы языка UML : учебное пособие. – Томск : Изд-во Томского гос. ун-та, 2023. – 95 с.
10

12. Клиентская часть модуля

Компонент
UploadManager
UploadManagerStore
UploadStore
MyFilesStore
PerformanceStore
SignalRStore
Назначение
Инициализация модуля и подключение
клиентских хранилищ
Общее состояние модуля и координация
дочерних store
Управление очередью загрузок, статусами
файлов и прогрессом
Работа с библиотекой загруженных файлов:
поиск, категории, выбор
Определение производительности устройства
и выбор режима загрузки
Получение уведомлений о завершении
обработки файлов
12

13. Серверная часть и API

Эндпоинт
Назначение
/api/uploadManager/init
Инициализация конфигурации, локализации,
URL воркеров и токена
Проверка дубликата по MD5 и генерация
подписанного URL
Приём файла, запись метаданных и запуск
обработки в RPC
Получение данных о загруженных файлах по
списку ID
Сохранение клиентских метрик времени
загрузки
/api/uploadManager/checkHash
/api/uploadManager/preparePhoto
/api/uploadManager/getUploaded
/api/uploadManager/logTime
13

14.

Рисунок 4 – программная реализация адаптации под нересурсоёмкие устройства
14

15. Данные и хранение метаданных

Поле
Назначение
UserId
Связь файла с владельцем и контроль доступа
Md5
Идентификация файла и дедупликация
Title, Extension, Size
Основные свойства исходного файла
Pages, Gps, DateTaken
Технические и EXIF-метаданные для
отображения и группировки
Категории, пользовательские группы и
фильтрация
Статус хранения и резервной обработки
Folders, DateCreated
IsYandex, BackupStatus
15

16. Дизайн модуля загрузки файлов

Рисунок 5 – Интерфейс разработанного модуля
16

17. Поиск по загруженным файлам

Рисунок 6 – Поиск файлов по имени
17

18. Группировка по дате и пользовательским событиям

Рисунок 7 – Группировка файлов по дате

19. Загрузка с телефона по QR-коду

Рисунок 8 – Группировка файлов по дате

20. Импорт из внешних источников

Рисунок 9 – Группировка файлов по дате

21. Тестирование модуля

Операция
Типичное время
Вычисление MD5-хеша (веб-воркер, 5 МБ)
100–200 мс
Запрос checkHash (серверная обработка)
50–150 мс
Прямая загрузка на Яндекс Объектное хранилище (10
8–12 с
МБ, 10 Мбит/с)
Создание записи в БД
20–50 мс
Создание миниатюры 2400px (RPC, сервер)
200–600 мс
SignalR-уведомление (с момента завершения RPC)
<1с
21

22. Результаты разработки

Направление
Полученный результат
Производительность
Прямая загрузка в облако снижает нагрузку на
основной сервер
Надёжность
Асинхронная обработка через RPC-очередь
отделяет загрузку от тяжёлой обработки
Удобство
Поиск, категории, группировка и загрузка с
телефона улучшают пользовательский опыт
Безопасность
EXIF очищается, доступ ограничен
владельцем, форматы валидируются на
сервере
Модуль внедрён в промышленную
эксплуатацию
Практический итог
22

23. Заключение

1.
2.
3.
4.
5.
Проанализированы предметная область, архитектура проекта и
существующие решения для загрузки файлов.
Сформулированы
функциональные
и
нефункциональные
требования к модулю, рассмотрены пользовательские сценарии.
Спроектирована двухрежимная архитектура загрузки с прямой
передачей в облако и серверным маршрутом.
Реализованы дедупликация по MD5, асинхронная обработка,
генерация миниатюр, очистка EXIF и SignalR-уведомления.
Разработанный модуль внедрён в промышленную эксплуатацию в
составе платформы.
23

24. Направления развития

1. Расширение модуля до полноценной системы управления
медиаактивами;
2. Интеграция машинного обучения для автоматической оценки
качества изображений;
24