Юрий Белк – Full stack Developer (страница 25)

Поля:

– id

– task_id

– author_user_id

– body

– created_at, updated_at

– опционально: edited_at

Смысл:

– комментарии – это история решений. Поэтому удаление комментариев лучше делать мягким (soft delete) или запрещать полностью. В учебном варианте можно разрешить удаление автору/админу, но в аудит всё равно писать.

6.2.7. Label

Label – метка (тег), используемый для фильтрации.

Поля:

– id

– workspace_id

– name

– color (опционально)

– created_at, updated_at

Почему label живёт в workspace, а не в проекте:

– часто метки общие для всех проектов (“bug”, “feature”, “urgent”).

– проще делать единообразные фильтры.

6.3. Ключевые фичи (и что именно подразумеваем)

6.3.1. Регистрация и логин

Минимальный сценарий:

– пользователь регистрируется по email+паролю

– получает токен (например, JWT или opaque token)

– использует токен для запросов

Важно:

– регистрацию надо защищать от спама и брутфорса (rate limiting – обсудим в главе 7)

– ошибки должны быть понятными, но не слишком разговорчивыми (не рассказывать злоумышленнику, существует ли email)

6.3.2. CRUD проектов и задач

CRUD = Create/Read/Update/Delete, но в реальном продукте:

– “Delete” часто заменяется на архивирование или soft delete

– “Update” – частичное (PATCH), чтобы не отправлять каждый раз всю модель

Для учебной системы мы оставим:

– проекты: создать/получить/обновить/архивировать

– задачи: создать/получить/обновить/удалить (или тоже архивировать – на ваш выбор, но важно быть последовательными)

6.3.3. Поиск, фильтры, сортировка

Это то, что отличает “список задач” от “рабочего инструмента”.

Примеры фильтров для задач:

– по статусу

– по исполнителю

– по метке

– по сроку (due_date)

– по проекту

– по тексту (title/description)

Сортировка:

– по created_at

– по updated_at

– по due_date

– по priority

Поиск:

– простейший: q как подстрока по title/description

– продвинутый: отдельный поисковый движок (не обязательно в первой версии)

Сразу договоримся: фильтры должны быть комбинируемыми, а не “или это, или то”. Это влияет на дизайн API.

6.3.4. Прикрепления файлов (опционально)

Мы можем не реализовать полноценное хранение, но должны понимать модель:

Вариант A (практичный): файлы хранятся в объектном хранилище (S3-подобном), а API хранит только метаданные.

Сущность Attachment (пока концептуально):

– id

– task_id

– uploader_user_id

– filename

– content_type

– size

– storage_key или url