Реализовать backend на python

Реализовать rest api

1. Авторизация (jwt access refresh tokens) не изобретать велосипед – взять проверенную либу (где можно задавать константы smtp, сколько длится refresh token, сколько длится ссылка для сброса пароля и т.д)
- /login
- /registration (с подтверждением по емейл)
- /recovery password
Все ресты далее фильтруют по залогиненому юзеру:
- если user.is_admin = true тогда не фильтруем по user_id отдаем все данные

2. Backend должен принимать файлы формата zip размером от 1кб до 1гб.
- Не использовать ОЗУ для хранения целиком файла – сохраняем батчами сначала на сервер иначе фиаско т.к. на сервере будет ОЗУ не так много как хотелось бы
- потом льем в сторадж НО без FIFO если 100 файлов в очереди значит все 100 Сразу передаем их в сторадж на хранение (Яндекс диск или любой другой)
Предложите где выгодно дешево хранить файлы – пример  Яндекс Диск и прочие сервисы РФ чтобы не на своем сервере до 3 Тб
сделать абстракцию Стораджа будь то  Яндекс 360 или другой сервис потом подключим

База данных:

- User
id – создает Бек
is_admin – создает Бек
email – String – передаем с фронта POST запросом
password – String – передаем с фронта POST запросом
active – bool – создает Бек – после подтверждении почты
updated_at – создает Бек – после восстановлении пароля
deleted_at – пригодится потом
created_at – создает Бек

- Document
id – создает Бек
hash – создает Бек
user_id – создает Бек
name – String – передаем с фронта POST запросом /task/upload
region – String – передаем с фронта POST запросом /task/upload
district – String – передаем с фронта POST запросом /task/upload
address – String – передаем с фронта POST запросом /task/upload
custom_props – String – передаем с фронта POST запросом /task/upload
valid – int – передаем с фронта POST запросом /task/upload
type – String – передаем с фронта POST запросом /task/upload
date_doc – передаем с фронта POST запросом /task/upload
deleted_at – пригодится потом
created_at – создает Бек

- Attachment
id – int – создает Бек
hash – String – создает Бек
user_id – int – создает Бек
document_id – int – создает Бек ссылка на таблицу Document
url – String – создает Бек
name – String – Имя Файла – создает Бек
size – int – вес файла – создает Бек
extension – String – расширение – создает Бек
deleted_at – пригодится потом
created_at – создает Бек

- Task
id – int – создает Бек
user_id – int – создает Бек
document_id – int – создает Бек ссылка на таблицу Document
status – int – создает Бек 0 – еще не запущена  1 – в процессе  5 – успешно завершена 10 – ошибка
message – String  – создает Бек
updated_at – создает Бек – при смене статусов ставим дату
deleted_at – пригодится потом
created_at – создает Бек

Бизнес Логика (можете свою предложить):
--> TASK
1. /task/upload – загружаем файл (POST Multipart закачка файла с параметрами)
1.1. Создаем записи в БД
- создаем запись в таблице – Document
- создаем запись в таблица – Task
1.2. запускаем Celery или иной Воркер
1.3. После загрузки в Сторадж,
---- Celery обновляет значения в таблице Task
---- Если успешно то создем запись в таблице Attachment заполняя все поля от ответа стораджа
(к примеру поле status – int = 0 – еще не запущена или 1 – в процессе или 5 – успешно завершена или 10 – ошибка)
2. /tasks?doc={document_id} GET – отдаем по связи document_id
3. /tasks GET – Получить все задачи

--> DOCUMENT
/documents GET – Получить все документы
/documents/{id} DELETE – удалить документ – удаляется все связи Attachment и Task и файл в сторадже  (только Админу)

--> ATTACHMENT
/attachments GET – Получить все (только Админу)
/attachments?doc={document_id} – Получить файл
1. идем в таблицу Attachment по document_id
- Если у стораджа ссылки периодически меняются тогда нужна логика
-- отправляется запрос в Yandex для получения url к файлу по имени Attachment.name
-- Если Yandex url не совпадает с БД.Attachment.url, то обновляем ссылку и updated_at

оформляем все в docker заливаем на сервер